Why It Fits
選ぶ理由
- スキーマ柔軟で開発が速い
- JSON / ドキュメント志向
- シャーディングで水平スケール
Product Profile
MongoDB Inc. / 2009年登場
JSON ライクなドキュメントを格納する NoSQL。スキーマが柔軟で開発が速く、シャーディングで水平にスケールしやすい。
Specifications
Introducing
Decision Guide
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
Why It Fits
Trade-offs
Deep Dive
MongoDB は、2009 年に登場した代表的なドキュメント指向の NoSQL データベースです。開発元は MongoDB Inc.(旧 10gen)で、現在のライセンスは SSPL(Server Side Public License)です。
行と列の表ではなく、JSON ライクなドキュメントの集まりとしてデータを格納する点が、RDB との一番の違いになります。「結局なに?」を一言でいえば、JSON をそのまま保存・検索できる柔軟なデータベースです。
データは「ドキュメント」を単位として扱い、それを束ねた「コレクション」に保存します。ドキュメントは内部的には BSON(バイナリ化された JSON)として保持され、入れ子の構造や配列もそのまま表現できます。
得意なのは、構造が一定でない、あるいは時間とともに項目が増えていくようなデータの取り扱いです。1 ドキュメントに関連情報をまとめて持てるため、単一の読み書きは高速になりやすいです。
一方で、複数コレクションをまたぐ結合(JOIN)や厳密な強整合性は RDB ほど得意ではありません。アクセスパターンを考えずにモデルを設計すると、かえって非効率になりやすい点にも注意が必要です。
項目が固定で、複雑な結合やトランザクション整合性が中心になるなら RDB が向きます。逆に、仕様変更でデータ構造が変わりやすいアプリや、JSON をそのまま扱いたい場面では MongoDB が選択肢になります。
実務では「スキーマが固まりきらない初期開発」「ユーザーごとに項目が異なるデータ」などで採用されることが多い DB です。
Implementation View
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
スキーマが変わるアプリ
種別: ドキュメント / クエリ: 独自(MQL / 集約パイプライン) / ライセンス: SSPL(ソース公開・商用)
JSON / ドキュメント志向
結合(JOIN)や強整合は弱め
Best Fit