2

現在、データスキーマをモデル化していますが、私の思考プロセスが理にかなっているのかどうかはわかりません。そこで、ここで経験豊富な MongoDB の担当者に聞いてみようと思いました。

私のアプリケーションが1 日に最大 10.000 個のイベント ドキュメントを生成するとします。時間ベースでアクセスしたい。のように: 「私にその 3 日間のすべてのイベントをください!」.

私が大学で集めた RDBMS の知識は、最初に次のように教えてくれました。

しかし、その後、毎日のコレクションを行うというアイデアに出くわしました!. 次に、対応するコレクションを呼び出すだけで 1 日のすべてのイベントを取得するだけで、これらのイベントに非常に高速にアクセスできます。

これは理にかなっていますか？速度/パフォーマンスを犠牲にすることなく、数百/数千のコレクションを持つことはできますか?

アドバイスありがとうございます:-)

4

1 に答える 1

6

1 日あたり 10.000 のドキュメントは、それほど多くはありません。1 年間で 365 万のドキュメントになります。それは確かに非常に小さなコレクションではありませんが、それらを分割することにはあまり意味がありません.

この特定のケースの欠点は次のとおりです。

  • 後でクエリ パターンを変更するのは困難です。突然時間単位の精度が必要になった場合、問題が発生します。一部のフィールド x が y に設定されている昨年のすべてのイベントを検索する場合は、365 または 366 コレクションをクエリする必要があります。
  • さまざまなコレクション名を処理する必要があるため、クエリ パターンはより複雑になります。また、データベースへのラウンドトリップが数回必要です。
  • 「日」は世界中で明確に定義された時点ではないため、国際化は非常に複雑です。一方、UTC DateTime フィールドを使用すると、必要に応じて異なるタイム ゾーンでクエリを実行できます。
  • 多数のコレクションを管理するのは面倒な場合があり、シェルを操作するのは非常に面倒です。
  • シャーディングは通常、コレクションごとに実行されます。小さいコレクションが多数ある場合、自動シャーディングは実行できません。

ただし、理解する必要がある制限はありますが、より多くのコレクションを操作することは可能です。ドキュメントで説明されているように、デフォルト設定でそれぞれ 1 つのインデックスを持つ 12,000 個のコレクションを作成できます。詳しくはそちらをご覧ください。

Server Density は彼らのアプローチについてブログに書いています。彼らも多くのコレクションを使用していますが、6 億 5000 万のドキュメントをかみ砕いており、パフォーマンスに関しては大きな違いはないと主張しています。

于 2012-06-06T09:29:51.220 に答える