【MongoDB】MongoDBとは？ドキュメント指向NoSQLを初心者向けに解説

MongoDB
2023.12.14

こんにちは、かつコーチです。

ここまでSQL基礎編・MySQL・PostgreSQLと、RDBMS（リレーショナルデータベース管理システム）を中心に学んできました。
テーブルと行、外部キーによる正規化など、SQLの世界観にはもう慣れてきた頃だと思います。

今回からは少し毛色の違うMongoDBを扱います。
「テーブルがない」「JOINがない」と聞くと戸惑うかもしれませんが、考え方さえ押さえれば決して難しくありません。
この記事では、MongoDBが何者なのか、SQLとどう違うのかを、初心者向けに丁寧に整理します。

MongoDBとは？

ドキュメント指向NoSQLというデータベースの分類

MongoDBは、ドキュメント指向という形式でデータを保存するNoSQLデータベースです。

NoSQLとは「Not Only SQL」の略で、SQLを使わない（あるいはSQLだけに縛られない）データベースの総称です。
MongoDBのほかにも、キーバリュー型のRedis、カラム指向のCassandraなどがNoSQLに含まれますが、その中でもMongoDBは「JSONに近い形式でデータをそのまま保存できる」ドキュメント指向型の代表格です。

具体的には、MongoDBは1件のデータをドキュメントという単位で保存します。
ドキュメントは、SQLでいう「1行のレコード」に近い存在ですが、中身はJSONによく似た構造（実際にはBSONというバイナリ形式）で表現されます。

// MongoDBのドキュメントの例（1人のユーザー情報）
{
  _id: ObjectId("64f1a2b3c4d5e6f7a8b9c0d1"),
  name: "田中太郎",
  email: "tanaka@example.com",
  age: 28,
  hobbies: ["読書", "登山"]
}

なぜテーブルではなくドキュメントなのか

RDBMSでは、データを保存する前にスキーマ（テーブルの列構成やデータ型のルール）を厳密に定義する必要があります。
「usersテーブルにはname、email、ageというカラムがあり、それぞれVARCHAR、VARCHAR、INTである」といった具合です。

一方MongoDBでは、コレクション（後述しますがテーブルに近い概念です）に対してスキーマを事前に固定する必要がありません。
これをスキーマレス（正確には「柔軟なスキーマ」）と呼びます。

この違いが生まれた背景には、Webサービスの成長スピードへの対応があります。
サービスが成長する過程で「ユーザーにタグ機能を追加したい」「商品ごとに項目数が違う」といった要件変更は日常茶飯事です。
RDBMSではその都度ALTER TABLEでテーブル構造を変更する必要がありますが、MongoDBならドキュメントごとに柔軟な形で項目を追加・省略できます。

SQLとMongoDBの用語対応・違い

テーブルとコレクション、行とドキュメントの対応関係

SQLに慣れている人がまず戸惑うのが用語の違いです。
下の対応表を頭に入れておくと、以降の記事がぐっと読みやすくなります。

SQL（RDBMS）MongoDB説明
データベースデータベース概念はほぼ同じ
テーブルコレクションドキュメントの集まり
行（レコード）ドキュメント1件分のデータ
カラムフィールドデータの項目
主キー（PRIMARY KEY）_id一意な識別子。MongoDBは自動採番
JOIN$lookup（集約パイプライン）別コレクションとの結合。SQLほど多用しない

特に重要なのは、SQLの主キーが通常id INT AUTO_INCREMENTのような連番であるのに対し、MongoDBの_idはObjectIdという12バイトの値が自動生成される点です。
生成時刻や生成元マシンの情報を含んでおり、分散環境でも重複しにくい設計になっています。

正規化とデータの持たせ方の違い

SQL基礎編で学んだ正規化（データの重複を排除し、テーブルを分割して整合性を保つ設計）は、RDBMSの根幹をなす考え方でした。
例えば「注文」と「注文商品」を別テーブルに分け、外部キーで結びつけるのが定石でしたね。

MongoDBでは、この考え方が一部逆転します。
関連するデータを1つのドキュメントに埋め込み（Embedding）でまとめて持たせることが推奨される場面が多いのです。

// SQLなら「注文テーブル」「注文商品テーブル」に分けるところを
// MongoDBでは1つのドキュメントにまとめられる
{
  _id: ObjectId("64f1a2b3c4d5e6f7a8b9c0d2"),
  orderDate: "2026-09-01",
  customerName: "佐藤花子",
  items: [
    { productName: "キーボード", price: 8000, quantity: 1 },
    { productName: "マウス", price: 3000, quantity: 2 }
  ],
  totalPrice: 14000
}

これにより、注文情報を取得するときに複数テーブルをJOINする必要がなく、1回の問い合わせで完結します。
ただし「埋め込み」と「参照」の使い分けには判断基準があり、これはMG08で詳しく扱います。

MongoDBが向いている場面・向いていない場面

MongoDBが得意な用途

私自身、以前担当した案件でログ収集用のシステムをMongoDBで組んだことがあります。
アクセスログはイベントの種類によって記録したい項目がバラバラで、RDBMSで設計しようとすると「NULLだらけのカラム」か「巨大な多対多構造」になりがちでした。
MongoDBに切り替えたところ、イベントごとに異なる項目をそのままドキュメントとして放り込めるため、設計の悩みがほぼ解消したのを覚えています。

このように、MongoDBは次のような場面で強みを発揮します。

  • ログデータ・イベントデータなど、項目の形が揺れやすいデータ
  • 商品カタログのように、カテゴリごとに持たせたい項目数が違うデータ
  • 開発初期でスキーマが頻繁に変わるプロトタイプ開発

RDBMS（SQL）が向いている場面

逆に、送金処理や在庫管理のように強い整合性（複数のデータ更新が必ず一貫した状態になること）が求められる処理は、依然としてRDBMSに分があります。
MongoDBもトランザクション機能を備えていますが、RDBMSほど複雑なJOINを前提とした設計には向きません。

「MongoDBがRDBMSの上位互換」というわけではなく、データの性質に応じて使い分ける道具だと理解しておくのが正確です。

まとめ

この記事のポイント

  • MongoDBはドキュメント指向のNoSQLデータベースで、JSONに近い構造のドキュメント単位でデータを保存する
  • テーブル→コレクション、行→ドキュメント、カラム→フィールドという用語対応を押さえておく
  • RDBMSの正規化に対し、MongoDBは関連データを1つのドキュメントに埋め込みでまとめる設計が多い
  • ログデータや項目が揺れやすいデータはMongoDB向き、強い整合性が必要な処理はRDBMS向き

次に読むべき記事

実際に手を動かしてMongoDBに触れてみたい方は、次回のインストール手順の記事に進んでください。
「MongoDBのインストールとmongoshの基本操作」で、環境構築から最初のコマンド実行までを解説します。

タグ: MongoDB 初心者向け 入門

タイトルとURLをコピーしました