ドキュメントストア
Document Store
キーに対して『ドキュメント』(JSON/XMLなどの構造を持つ塊)を値として格納するNoSQL。ドキュメントの中身でも検索でき、柔軟なスキーマを扱える。MongoDB / DynamoDB など。
キー・バリューとの違い
キー・バリューは『中身は不透明な箱』で、キーでしか出し入れできませんでした。ドキュメントストアは、中身が構造化されていてDBがそれを理解できる点が違います。
{
"id": "user:123",
"name": "田中",
"hobbies": ["釣り", "読書"],
"address": { "city": "東京" }
}
このドキュメントに対して『cityが東京のユーザー』『hobbiesに釣りを含むユーザー』のように、中身のフィールドで検索できます。
図を描画中...
柔軟なスキーマの強み
RDBMSは事前にテーブルの列を全部決める必要があります(スキーマ固定)。ドキュメントストアはドキュメントごとに違う形でもOK。あるユーザーには電話番号があり、別のユーザーにはない、でも問題なし。仕様変更で項目が増えても、テーブル定義を変更(マイグレーション)せずに済むことが多い。
向いているのは『構造がたまに変わる』『ユーザーごとに持つ項目が違う』ようなデータ。
代表的なツール
- MongoDB / CouchDB: SQLライクなクエリが書ける、汎用的なドキュメントDB。
- DynamoDB: AWSのマネージドDB。キー・バリューとドキュメント両方の性質を持つ。
つまずきポイント
- 柔軟なスキーマは諸刃の剣。何でも入れられる分、構造がバラバラになって後で扱いに困ることも。ある程度の規律は必要。
- JOINが弱いので、関連データをどう持つか(埋め込むか、参照にするか)の設計が重要。埋め込めばJOIN不要で速いが、重複して整合性管理が増える。
📊 図解
図解: ネストしたドキュメント構造
1つのドキュメントの中に、配列(hobbies)やネストしたオブジェクト(address)を持てる。DBが構造を理解するので、内部フィールドで検索できる。
図を描画中...