これは科学というより芸術です。スキーマに関するMongoのドキュメントは良いリファレンスですが、考慮すべき点がいくつかあります。
-
できるだけ入れてください
ドキュメントデータベースの利点は、多くの結合を排除できることです。最初の本能は、できるだけ多くを1つのドキュメントに配置することです。 MongoDBドキュメントには構造があり、その構造内で効率的にクエリを実行できるため（つまり、必要なドキュメントの一部を取得できるため、ドキュメントのサイズはそれほど気になりません）、次のようなデータをすぐに正規化する必要はありません。 SQLで行います。特に、親ドキュメント以外で役に立たないデータは、同じドキュメントの一部である必要があります。
-
複数の場所から参照できるデータを個別のコレクションに分けます。
これは「データの一貫性」の問題であるため、「ストレージスペース」の問題ではありません。多くのレコードが同じデータを参照する場合、単一のレコードを更新して他の場所でそのデータへの参照を保持する方が効率的でエラーが発生しにくくなります。
-
ドキュメントサイズに関する考慮事項
MongoDBは、1つのドキュメントに4MB（1.8では16MB）のサイズ制限を課します。 GBのデータの世界では、これは小さいように聞こえますが、3万件のツイート、250件の典型的なStack Overflowの回答、または20枚のちらつき写真でもあります。一方、これは、一般的なWebページで一度に表示したい情報よりもはるかに多くの情報です。まず、クエリを簡単にするものを検討します。多くの場合、ドキュメントサイズに関する懸念は時期尚早の最適化になります。
-
複雑なデータ構造：
MongoDBは、任意の深いネストされたデータ構造を格納できますが、それらを効率的に検索することはできません。データがツリー、フォレスト、またはグラフを形成する場合は、各ノードとそのエッジを個別のドキュメントに効果的に保存する必要があります。 （このタイプのデータ用に特別に設計されたデータストアも考慮する必要があることに注意してください）
また、ドキュメント内の要素のサブセットを返すことは不可能であるということも指摘されています。各ドキュメントの数ビットを選択する必要がある場合は、それらを分離する方が簡単です。
-
データの一貫性
MongoDBは、効率と一貫性の間でトレードオフを行います。ルールは、単一のドキュメントへの変更は常にであるということです。 アトミックですが、複数のドキュメントへの更新はアトミックであると想定してはなりません。サーバー上のレコードを「ロック」する方法もありません（たとえば、「ロック」フィールドを使用して、これをクライアントのロジックに組み込むことができます）。スキーマを設計するときは、データの一貫性を維持する方法を検討してください。一般的に、ドキュメントに保存する量が多いほど良いです。
あなたが説明していることのために、私はコメントを埋め込み、各コメントにObjectIDを持つidフィールドを与えます。 ObjectIDにはタイムスタンプが埋め込まれているため、必要に応じて作成する代わりにタイムスタンプを使用できます。