【データ設計】ドキュメントDBの特徴、ユースケース

特徴

• JSONをデータモデルとして格納するデータベース
• キーや値で絞り込むことができる。
• 負荷が増えてきた場合は簡単にスケールアウトすることができるので性能の心配はない。

ドキュメントDBは、KVSの特徴に加えてJSONを扱う機能が豊富です。スキーマレスである特性も相まって開発効率アップが期待できます。

スキーマレスとは？

データ構造を事前に定義する必要がなく、値の型が固定されないこと。RDBでは逆に完全に型を固定する。

突然データ構造の変化があってもJSONをそのまま格納できるのでデータロストのせずに貯めて置ける。

スキーマが変わったとしてもとりあえず貯めておける。必要になったらアプリケーションを修正すれば良い。

これによりスキーマが突然変わってからデータを取得できないというリスクを低減できる。

高速な開発が可能

昨今のビジネス要件として高速にプロトタイプを開発することが望まれている。

ドキュメントDBとスクリプト言語を用いることによりRDBとコンパイル言語を用いる開発に比べて非常に高速に開発ができます。

テーブル定義することもなく、データの挿入ができる。

ORマッパーも使う必要がない。

そのままオブジェクトや配列が入っているので、わざわざオブジェクト（プログラム言語で処理する形）に変える必要がありません。取得したらそのままプログラム内でデータ処理が可能になります。

ユースケース

外部のデータを集めてきて付加価値をつけたいケース（例：TwitterAPIのデータを集める）

TwitterAPIを使うのは誰がも考えつくでしょう。

データ項目が多い。（100個くらいもある。）

単純に定義量が大変です。配列構造になっている箇所は、正規化してテーブルの数も増やさないといけない。

列定義が大変

キーがわかっても、値の型がたくさんありすぎる。英語で書かれたAPI仕様書を読めばまあ分かるが。

必要な情報だけ格納するのはどうか？

RDBだと後から必要な情報が足りてないことに気づいた場合に列を追加するのが大変。

JSONの特性上難しい部分もある。

JSONは１：多の構造が入れ子になって格納される。JSONのデータの型や値の型は同じであるとは限らない。これを表形式に無理やり変換しようとするのは難しい部分がある。

RDBでは大量データ処理に耐えられない。

インターネット上のサービスは秒間で何百件ものデータ処理がなされます。RDBにそんな件数を一度に登録しようとするとすぐにタイムアウトしてしまいます。

業務システムではデータ量の予測を立てやすいが、インターネットのデータは全人類が対象になるのでデータ量の予測が難しい。

変更に弱い

後からAPIの仕様変更があってカラムが一つ減った場合に登録エラーになる。（まあ、昨今のAPIであればパスにバージョンの記載があって、特定バージョンを指定できるようになっているケースもある。）

RDBでALTER TABLEコマンドによりスキーマ変更が行えるが、膨大なデータベースに対してこのコマンドを発行すると非常に時間がかかるし、データベースに莫大な負荷がかかります。（ALTER TABLEを打つたびにシステムを停止させなければならなくなる。）

結論

このケースではドキュメントDBを使う。深い階層を持つデータをRDBにすると結合の多用になり大変だが、JSONであれば一つのJSONの中に階層構造まで格納することができる。

要は、自分の手の内にはない外部のデータスキーマを定義することは簡単ではないのです。

大量のログを集めておき価値ある情報を提供したいケース

注意点

スキーマ管理(ER図の発行、全ての型を定義したドキュメントのメンテナンス)自体はするべき。とりあえずプロトタイプで高速に開発して欲しいという要求があるのであれば、スキーマ管理は不要だが、ちゃんと本番アプリケーションとして運用する実装をする場合はしっかりとスキーマ管理はするべき。