MongoDBスキーマデザイン

Question

私はMongoDBでこのスキーマを実装する予定です。スキーマ設計に関するいくつかの読書を行っていますが、リレーショナルデータベースのようにデータを構造化するときには何か間違っていなければなりません。

私の質問：

• コレクションのサイズが16メガバイト制限よりも大きくなったときに、私は何をすべきか？ サーバが忙しいかどうかによって、server_logコレクションのapp_logが16MBを超える場合があります。

  私は使用できる上限機能を認識していますが、90日間すべてのログを保存する必要があります。

• 私のデザインに潜在する問題はありますか？

• ログサイズの拡大に対応するために、アプリケーションでコレクションのサイズをチェックして、1日あたりの新しいコレクションを作成することをお勧めしますか？コメントの一つは、あなたはそれが最大ドキュメントサイズであることをin the MongoDB manual確認することができ、指摘したよう

おかげ

Answer 1

このデザインが良いかどうかは、クエリによって異なります。一般に、あなたはMongoでの結合の使用を避けたいと考えています（まだ可能ですが、束縛をしている場合は間違って使用していますが、実際にはリレーショナルDBを使用する必要があります:-)

たとえば、ほとんどのクエリがserver_logコレクションにあり、そのコレクション内のフィールドのみを使用すると、うまくいくでしょう。 OTOHの場合、server_logクエリで常にサーバコレクションからデータを引き出す必要がある場合（たとえば、nameフィールドやuserIdフィールドなど）、そのデータを選択的に非正規化する価値があります。これは素晴らしい方法です。名前とuserIdフィールドをserver_logドキュメントにコピーして、クエリがサーバーコレクションとの結合を回避できるようにすることができます。もちろん、非正規化するたびに、アプリケーションに複雑さが増します。これにより、データが複数のコレクションにわたって一貫性があることが保証されなければなりません（たとえば、サーバー名を変更したときにserver_logでも変更する必要があります） 。

実行すると思われるクエリのリストを作成し、現在のスキーマとの最小限の結合で実行できるかどうかを確認することができます。そうでない場合、少しの非正規化が役立つかどうかを見てください。クエリを満足させるために、非正規化データの多数の結合や手動による管理を行う必要がある場合は、スキーマやDBの選択肢を再考する必要があります。

Answer 2

あなたのコレクションのサイズは、16メガバイトに限定されるものではありません。したがって、異なるコレクション間で同じクラスのデータを分離する必要はありません。実際には、あなたのために大きな頭痛になるでしょう:) 1つのuserコレクション、1つはserver、もう1つはserver_logです。次に、idフィールドを使用して、あるコレクションから次のコレクションへの参照を作成できます。