本番環境でMongoDBを使い始めるときに知っておくべきこと-10のヒント

MongoDBでは、SQL dbmsの場合と同じように、フィールド（列）を定義する必要はありません。ただし、データの不整合や発生する可能性のあるいくつかの後退を回避するために、フィールドを定義する必要はありませんが、スキーマを定義することは常に良い習慣です。スキーマ設計により、どのタイプのデータが特定のフィールドに送られるかを決定できます。どのフィールドに値を指定する必要があり、通常、入力または更新前のデータ検証を強化して、データの整合性と一貫性を促進します。スキーマ設計では、データを参照するか埋め込むかを指示します。初心者の場合、唯一のモデルは「One-to-N」であり、サブドキュメントの配列エントリを簡単に作成できると思うかもしれませんが、そうではありません。

モデルを作成する前に、ドキュメント間のカーディナリティの関係を理解する必要があります。最適なスキーマを作成するのに役立つルールは次のとおりです。

1. 一部のデータにアクセスする前に実行する必要のあるクエリの数を減らすために、フィールドや配列要素がほとんど含まれていない場合は、サブドキュメントを埋め込むことができます。以下のモデルの例を見てください。

   1. {
       Name: ‘John Doh’,
       Age:20
       Addresses:[
         {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’},
         {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’},
       ]
      }
      

2. 頻繁に更新されるドキュメントの場合は、非正規化を使用します。いずれかのフィールドが頻繁に更新される場合は、更新が必要なすべてのインスタンスを見つけるタスクがあります。これにより、クエリ処理が遅くなり、非正規化に関連するメリットさえも圧倒されます。
3. 集約パイプラインなどの複雑なクエリは、多くのサブドキュメントが含まれ、ドキュメントを個別にフェッチする必要がある場合、実行に時間がかかります。
4. オブジェクトデータの大規模なセットを含む配列要素は、大きくなり、その結果ドキュメントサイズを超える可能性があるため、明らかに埋め込むべきではありません。

スキーマのモデリングは、多くの場合、アプリケーションのアクセスパターンによって決定されます。モデルの設計に役立つその他の手順については、ブログ6「MongoDBスキーマ設計の経験則」

{

   FirstName: ‘John’,

   LastName: ‘Doh’

}