製品プロフィール

MongoDB

MongoDB Inc. / 2009年登場

JSON ライクなドキュメントを格納する NoSQL。スキーマが柔軟で開発が速く、シャーディングで水平にスケールしやすい。

3つの要点
TL;DR
  1. JSON ライクなドキュメントを格納する NoSQL。
  2. スキーマが柔軟で開発が速く水平スケールも容易。
  3. 構造が変わるデータ向け。強整合や結合なら RDB。

基本情報

仕様と立ち位置

MongoDB のロゴ
製品・技術の概要MongoDBJSON ライクなドキュメントを格納する NoSQL。スキーマが柔軟で開発が速く、シャーディングで水平にスケールしやすい。
種別
ドキュメント
クエリ
独自MQL / 集約パイプライン)
ライセンス
SSPLソース公開商用)
登場
2009年
最大の強み
スキーマ柔軟で開発が速いJSON / ドキュメント志向
代表的な用途
スキーマが変わるアプリカタログ / コンテンツ管理 / 高速プロトタイプ

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. スキーマ柔軟で開発が速い
  2. JSON / ドキュメント志向
  3. シャーディングで水平スケール

事前に確認する条件

考慮すべき点

  1. 結合(JOIN)や強整合は弱め
  2. トランザクションは後発
  3. 設計を誤ると非効率

詳しい解説

もっと詳しく

どんな DB か

MongoDB は、2009 年に登場した代表的なドキュメント指向の NoSQL データベースです。開発元は MongoDB Inc.(旧 10gen)で、現在のライセンスは SSPL(Server Side Public License)です。

行と列の表ではなく、JSON ライクなドキュメントの集まりとしてデータを格納する点が、RDB との一番の違いになります。「結局なに?」を一言でいえば、JSON をそのまま保存・検索できる柔軟なデータベースです。

横にスクロール

MongoDBのクライアントが主ノードへBSON文書を書き、journalとoplogへ記録して複製ノードが適用しwriteConcern分の確認後に応答する流れと、mongosがshard keyで対象shardへ経路制御する流れ
レプリカセットではPrimaryが書込み順序を決めてjournalとoplogへ記録し、Secondariesが同じ操作を適用します。writeConcern、readConcern、readPreferenceで耐久性・鮮度・遅延を選び、未majority書込みは選挙後にrollbackされ得ます。シャーディングではmongosがshard keyで対象を絞るため、分散均等性と主要クエリの両方からキーを設計します。

データモデル・仕組み

データは「ドキュメント」を単位として扱い、それを束ねた「コレクション」に保存します。ドキュメントは内部的には BSON(バイナリ化された JSON)として保持され、入れ子の構造や配列もそのまま表現できます。

  • ドキュメントごとにフィールドが違っても保存でき、スキーマが柔軟です。
  • 事前に厳密なテーブル定義を作らなくても書き始められるため、開発が速いです。
  • データを複数サーバーに分割するシャーディングにより、水平にスケールできます。

得意・不得意

得意なのは、構造が一定でない、あるいは時間とともに項目が増えていくようなデータの取り扱いです。1 ドキュメントに関連情報をまとめて持てるため、単一の読み書きは高速になりやすいです。

一方で、複数コレクションをまたぐ結合(JOIN)や厳密な強整合性は RDB ほど得意ではありません。アクセスパターンを考えずにモデルを設計すると、かえって非効率になりやすい点にも注意が必要です。

いつ選ぶか(RDB との違い)

項目が固定で、複雑な結合やトランザクション整合性が中心になるなら RDB が向きます。逆に、仕様変更でデータ構造が変わりやすいアプリや、JSON をそのまま扱いたい場面では MongoDB が選択肢になります。

実務では「スキーマが固まりきらない初期開発」「ユーザーごとに項目が異なるデータ」などで採用されることが多い DB です。

実装・運用の視点

MongoDBを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

スキーマが変わるアプリ

比較で見る軸

種別: ドキュメント / クエリ: 独自(MQL / 集約パイプライン) / ライセンス: SSPL(ソース公開・商用)

導入後に効く点

JSON / ドキュメント志向

先に潰すリスク

結合(JOIN)や強整合は弱め

数字・仕様の読み方
種別
ドキュメント
クエリ
独自(MQL / 集約パイプライン)
ライセンス
SSPL(ソース公開・商用)
登場
2009年

判断チェックリスト

  • 自社の用途が「スキーマが変わるアプリ / カタログ / コンテンツ管理」に近いか確認する。
  • 強みである「スキーマ柔軟で開発が速い」が本当に評価軸になるか確認する。
  • 注意点の「結合(JOIN)や強整合は弱め」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

スキーマが変わるアプリカタログ / コンテンツ管理高速プロトタイプ

向いている用途

こんな用途に向く

スキーマが変わるアプリカタログ / コンテンツ管理高速プロトタイプ
公式サイト