MongoDBスキーマ計画のヒント

MongoDBの最も宣伝されている機能の1つは、「スキーマレス」であるという機能です。これは、MongoDBがコレクション内に保存されているドキュメントにスキーマを課さないことを意味します。通常、MongoDBはドキュメントをJSON形式で保存するため、各ドキュメントはさまざまな種類のスキーマ/構造を保存できます。これは開発の初期段階では有益ですが、後の段階では、パフォーマンスとスケーラビリティを向上させるために、新しいドキュメントを挿入しながらスキーマ検証を実施することをお勧めします。つまり、「スキーマレス」とは、スキーマを設計する必要がないという意味ではありません。この記事では、MongoDBスキーマを計画するための一般的なヒントについて説明します。

アプリケーションに適した最適なスキーマ設計を見つけるのは、面倒な場合があります。スキーマを設計する際に考慮できるいくつかのポイントを次に示します。

ドキュメントの増加を避ける

スキーマでサイズが継続的に大きくなるドキュメントの作成が許可されている場合は、DBおよびディスクIOのパフォーマンスが低下する可能性があるため、これを回避するための手順を実行する必要があります。デフォルトでは、MongoDBはドキュメントごとに16MBのサイズを許可します。ドキュメントのサイズが一定期間で16MBを超えて増加する場合は、スキーマ設計が不適切であることを示しています。クエリが失敗する場合があります。この状況を回避するために、ドキュメントバケットまたはドキュメントの事前割り当て手法を使用できます。アプリケーションが16MBを超えるサイズのドキュメントを保存する必要がある場合は、MongoDBGridFSAPIの使用を検討できます。

ドキュメント全体の更新を避ける

ドキュメント全体を更新しようとすると、MongoDBはドキュメント全体をメモリ内の別の場所に書き換えます。これにより、データベースの書き込みパフォーマンスが大幅に低下する可能性があります。ドキュメント全体を更新する代わりに、フィールド修飾子を使用して、ドキュメント内の特定のフィールドのみを更新できます。これにより、メモリ内のインプレース更新がトリガーされるため、パフォーマンスが向上します。

アプリケーションレベルの結合を回避するようにしてください

ご存知のとおり、MongoDBはサーバーレベルの参加をサポートしていません。したがって、DBからすべてのデータを取得してから、アプリケーションレベルで結合を実行する必要があります。複数のコレクションからデータを取得して大量のデータを結合する場合は、DBを数回呼び出して、必要なすべてのデータを取得する必要があります。これにはネットワークが関係するため、明らかに時間がかかります。このシナリオの解決策として、アプリケーションが結合に大きく依存している場合は、スキーマの非正規化の方が理にかなっています。埋め込まれたドキュメントを使用して、1回のクエリ呼び出しで必要なすべてのデータを取得できます。

適切なインデックスを使用する

検索や集計を行う際に、データを並べ替えることがよくあります。パイプラインの最終段階で並べ替えを申請する場合でも、並べ替えをカバーするためのインデックスが必要です。並べ替えフィールドのインデックスが使用できない場合、MongoDBはインデックスなしで並べ替えを強制されます。ソート操作に関係するすべてのドキュメントの合計サイズの32MBのメモリ制限があります。 MongoDBがその制限に達すると、エラーが発生するか、空のセットが返される可能性があります。

インデックスの追加について説明しましたが、不要なインデックスを追加しないことも重要です。データベースに追加する各インデックスは、コレクション内のドキュメントを更新するときに、これらすべてのインデックスを更新する必要があります。これにより、データベースのパフォーマンスが低下する可能性があります。また、各インデックスはある程度のスペースとメモリを占有するため、インデックスの数がストレージ関連の問題につながる可能性があります。

インデックスの使用を最適化するもう1つの方法は、デフォルトの_idフィールドをオーバーライドすることです。このフィールドの唯一の目的は、ドキュメントごとに1つの一意のフィールドを保持することです。データにタイムスタンプまたは任意のidフィールドが含まれている場合は、_idフィールドをオーバーライドして、追加のインデックスを1つ保存できます。

読み取りv/s書き込み比率

アプリケーションのスキーマの設計は、アプリケーションの読み取りが多いか書き込みが多いかによって大きく異なります。たとえば、時系列データを表示するダッシュボードを構築している場合は、書き込みスループットが最大になるようにスキーマを設計する必要があります。アプリケーションがEコマースベースの場合、ほとんどのユーザーがすべての製品を調べ、さまざまなカタログを閲覧するため、ほとんどの操作は読み取り操作になります。このような場合は、非正規化スキーマを使用して、関連データを取得するためのDBへの呼び出し回数を減らす必要があります。

BSONデータ型

スキーマを設計するときは、すべてのフィールドにBSONデータ型を正しく定義してください。フィールドのデータ型を変更すると、MongoDBはドキュメント全体を新しいメモリスペースに再書き込みするためです。たとえば、（float）0.0フィールドの代わりに（int）0を格納しようとすると、BSONデータ型が変更されたため、MongoDBはドキュメント全体を新しいアドレスに書き換えます。

結論

一言で言えば、Mongoデータベースのスキーマを設計することは賢明です。それは、アプリケーションのパフォーマンスを向上させるだけだからです。バージョン3.2から、MongoDBは、新しいドキュメントを挿入するために必要なフィールドを定義できるドキュメント検証のサポートを開始しました。バージョン3.6から、MongoDBは、JSONスキーマ検証を使用してスキーマ検証を実施するより洗練された方法を導入しました。この検証方法を使用すると、必須のフィールドチェックとともにデータ型チェックを実施できます。上記のアプローチを使用して、すべてのドキュメントが同じタイプのスキーマを使用しているかどうかを確認できます。