0

私のプロジェクトでは、Web サイトに ping 要求を送信し、応答時間を測定して毎分保存するサーバーがあります。

Mongodb を使用する予定で、最適なデータ モデルを探しています。どのデータモデルが優れていますか?

1- 各 Web サイトと各リクエストのコレクションをドキュメントとして持つ。(1000コレクション)

また

2- すべての Web サイトと各 Web サイトのコレクションをドキュメントとして、各リクエストをサブドキュメントとして持つ。

4

2 に答える 2

1

どちらのソリューションも、mongodb の 1 つの特定の制限に直面する必要があります。最初のものでは、各 Web サイトをコレクションと言いましたが、制限はコレクションの数にありますが、それぞれに名前空間エントリがあり、名前空間のサイズは 16 MB であるため、約 16.000 のエントリが収まります。 (名前空間のサイズ増やすことができます）私の意見では、これははるかに優れたソリューションですが、1000個のコレクションが予想され、処理できると言われています。(インデックスには独自の名前空間エントリがあり、16.000 でカウントされると見なす必要があります)。この場合、エントリをドキュメントとして保存できます。通常、埋め込み配列よりもはるかに簡単に処理できます。

埋め込み配列の制限。2 番目のケースでのこの制限は難しいものです。ドキュメントが 16MB を超えて大きくなることはありません。これは BSON サイズであり、ドキュメント内に非常に多くのものを保存できますが、サイズが変化する巨大なドキュメントを使用し、時間の経過とともにサイズを変更すると、ストレージが断片化されます。その理由は、このウェビナーを見れば明らかです。基本的に、これはストレージの使用に関してできることの価値です。

さらに分析するために集約フレームワークを使用する可能性が高い場合、埋め込み配列の概念を使用することも難しくなります。

于 2013-06-24T08:50:39.930 に答える
1

どちらでもかまいませんが、どちらの場合もデータベースの定期的な増加を考慮に入れる必要があると思います。データファイルの拡張中は、データベースが遅くなるか、応答しなくなります。（これはバックグラウンドで発生するように設定されている可能性があります-忘れました）。

関連する質問 -データ構造の増大に伴う MongoDB のパフォーマンス、特に「パディング ファクター」

最初のアプローチでは、コレクションの最大数によって課される、保存できる Web サイトの数に上限があります。http://docs.mongodb.org/manual/reference/limits/に基づいて計算を行うことができます。

2 番目のアプローチでは、コレクションの数はそれほど重要ではありませんが、データベースの増大は考慮する必要があります。

1 つの方法は、空のデータで初期化することです。そのため、展開するまでに時間がかかります。

例えば。

{
  website: name,
  responses: [{
     time: Jan 1, 2013, 0:1, ...
  },
  {
     time: Jan 1, 2013, 0:2, ...
  }
  ... and so for each minute/interval you expect. 

]
}

欠点は、初期化に時間がかかることですが、後で心配する必要があります。

いずれにせよ、それはあなたが支払わなければならないコストです。唯一の問題はいつですか？今？または後で？

特にユースケースを読むことを検討してください - http://docs.mongodb.org/manual/use-cases/hierarchical-aggregation/

于 2013-06-23T16:12:49.060 に答える