Docs Menu
Docs Home
/
MongoDBマニュアル

データモデリング

項目一覧

  • ユースケース
  • スキーマ設計: リレーショナル データベースとドキュメント データベースの違い
  • スキーマの計画
  • リンク関連データ
  • 埋め込みデータ
  • 参考文献
  • データ モデリングに関するその他の考慮事項
  • データの重複と整合性
  • インデックスの作成
  • ハードウェアの制約
  • 単一ドキュメントのアトミック性
  • 詳細

データ モデリングとは、データベース内のデータの組織と、関連するエンティティ間のリンクを指します。MongoDB のデータは柔軟なスキーマモデルであり、次のことを意味します。

  • 単一のコレクション内のドキュメントでは、同じフィールド セットが必須ではありません。

  • フィールドのデータ型は、コレクション内のドキュメント間で異なる場合があります。

一般に、コレクション内のドキュメントは同様の構造を共有します。データモデルの整合性を確保するために、スキーマ検証ルールを作成できます。

柔軟なデータモデルにより、アプリケーションのニーズに合わせてデータを整理できます。MongoDB はドキュメント データベースであるため、オブジェクト フィールドや配列フィールドに関連データを埋め込むことができます。

柔軟なスキーマは、次のシナリオで役立ちます。

  • お客様の会社で、各従業員がどの部門で働いているかを追跡しているとします。部門情報を employee コレクションに埋め込むと、1 回のクエリで関連情報を返すことができます。

  • eコマース アプリケーションでは、製品を表示するときに最新の 5 件のレビューが表示されます。最近のレビューを製品データと同じコレクションにストアし、古いレビューは頻繁にアクセスされないため、別のコレクションに保存できます。

  • お客様の衣料品店では、製品カタログ用に単一ページのアプリケーションを作成する必要があるとします。製品によって属性が異なるため、使用するドキュメント フィールドも異なります。ただし、すべての製品を同じコレクションに保存できます。

MongoDB のようなドキュメント データベースのスキーマを設計する場合、関係データベースとは異なる、考慮すべき重要な違いがいくつかあります。

関係データベースの動作
ドキュメント データベースの動作

データを挿入する前に、テーブルのスキーマを決定する必要があります。

アプリケーションのニーズが変化すると、スキーマも時間の経過とともに変化する可能性があります。

アプリケーションに必要なデータを返すには、多くの場合、複数の異なるテーブルのデータを結合する必要があります。

柔軟なデータモデルにより、アプリケーションがデータを返す方法に合わせてデータをストアし、結合を回避できます。複数のコレクションにまたがる結合を避けることで、パフォーマンスが向上し、配置のワークロードが軽減されます。

データモデルが論理的な構造を持ち、最適なパフォーマンスを実現できるようにするには、データベースを本番環境の規模で使用する前にスキーマを計画してください。データモデルを決定するには、次のスキーマ設計プロセスを使用します。

  1. アプリケーションのワークロードを特定します。

  2. コレクション内のオブジェクト間の関係をマッピングします。

  3. 設計パターンを適用します。

MongoDB でデータモデルを設計するときは、ドキュメントの構造と、アプリケーションが関連エンティティのデータを使う方法を考慮しましょう。

関連データをリンクするには、次のいずれかを行います。

  • 単一のドキュメント内に関連データを埋め込みます。

  • 関連データを別のコレクションにストアし、参照を使用してアクセスします。

埋め込みドキュメントは、関連するデータを単一のドキュメント構造にストアします。ドキュメントには、関連データを持つ配列とサブドキュメントを含めることができます。これらの非正規化されたデータモデルにより、アプリケーションは 1 回のデータベース操作で関連データを検索できます。

関連するすべての情報を含む埋め込みフィールドを持つデータモデル。

MongoDB の多くのユースケースでは、非正規化データモデルが最適です。

ドキュメントを埋め込むことの長所と短所については、「埋め込みデータモデル」を参照してください。

参照とは、あるドキュメントから別のドキュメントへのリンク(参照と呼ばれます)を含めることで、データ間の関係をストアするものです。たとえば、orders コレクションの customerId フィールドは、customers コレクション内のドキュメントへの参照を示します。

アプリケーションはこれらの参照を解決して関連データにアクセスできます。大まかに言えば、これらは正規化されたデータモデルです。

参照を使用してドキュメントをリンクするデータモデル。``contact`` ドキュメントと ``access`` ドキュメントの両方に ``user`` ドキュメントへの参照が含まれています。

参照を使用することの長所と短所については、「参照」をお読みください。

次の要因は、データモデルの計画方法に影響を与える可能性があります。

単一のドキュメントに関連データを埋め込む場合、2 つのコレクション間でデータを複製できます。データを重複させることにより、アプリケーションは、モデル内のエンティティを論理的に分離しながら、1 つのクエリで複数のエンティティについての関連情報をクエリできます。

たとえば、products コレクションに、製品ドキュメントの最新の 5 件のレビューがストアされるとします。これらのレビューは、すべての製品レビューを含む reviews コレクションにもストアされます。新しいレビューが書き込まれると、次の書き込みが行われます。

  • レビューは reviews コレクションに挿入されます。

  • products コレクション内の最近のレビューの配列が $pop$push で更新されます。

重複したデータが頻繁にアップデートされない場合は、2 つのコレクションの整合性を保つために必要な追加作業は最小限に抑えられます。ただし、重複したデータが頻繁にアップデートされる場合は、参照を使用して関連データをリンクする方がよい場合があります。

データを複製する前に、以下の要素を考慮してください。

  • 重複したデータをどのくらいの頻度でアップデートする必要があるか。

  • データが重複している場合の読み取りのパフォーマンス上の利点。

詳細については、「重複データの処理」を参照してください。

アプリケーションが頻繁に実行するクエリのパフォーマンスを向上させるには、よくクエリされるフィールドにインデックスを作成します。アプリケーションの規模が大きくなるにつれて、配置のインデックスの使用状況を監視して、インデックスが、関連するクエリを引き続きサポートしていることを確認してください。

スキーマを設計するときは、配置のハードウェア、特に使用可能な RAM の量を考慮してください。ドキュメントのサイズが大きくなると、RAM の使用量が増えるため、アプリケーションがディスクから読み取ることになり、パフォーマンスが低下する可能性があります。可能であれば、関連するフィールドのみがクエリによって返されるようにスキーマを設計します。この方法により、アプリケーションのワーキングセットが不必要に大きくならないようにすることができます。

MongoDB では、書き込み操作は、単一のドキュメント内の複数の埋め込みドキュメントを変更する場合でも、単一のドキュメント レベルでアトミックです。つまり、アップデート操作が複数のサブドキュメントに影響する場合、それらのサブドキュメントがすべてアップデートされるか、操作が完全に失敗してアップデートが行われないかのどちらかになります。

データが埋め込まれた非正規化データモデルは、複数のドキュメントやコレクションにわたって正規化するのではなく、関連するすべてのデータを 1 つのドキュメントに組み合わせます。このデータモデルでは、操作が複数のドキュメントに影響する正規化されたモデルとは対照的に、アトミック操作が可能です。

詳細については、「アトミック性」を参照してください。

  • MongoDB University のデータモデリングコースで、ドキュメントを構造化し、スキーマを定義する方法を学びましょう。

  • MongoDB を使用したデータ モデリングの詳細については、 「MongoDB アプリケーション モダナイゼーション ガイド」をダウンロードしてください。

    ダウンロードには、次のリソースが含まれています。

    • MongoDB を使用したデータ モデリングの方法論に関するプレゼンテーション

    • RDBMS データモデルから MongoDB に移行するためのベストプラクティスと考慮事項を説明したホワイトペーパー

    • MongoDB のスキーマを RDBMS の同等のスキーマで参照

    • アプリケーション モダナイゼーション スコアカード

戻る

シャーディングされたクラスター