0

MongoDB ストレージを使用したモニタリング/ロギング アプリケーションのデータ モデルを定義しています。私は MongoDB を初めて使用するので、アドバイスをいただければ幸いです。

アプリケーションの書き込み:

私が持っているロガーごとに、10,000個のロガーがあります。

  • 時間の経過とともに変化しない静的データ (ロガーあたり数キロバイト)
  • 各ロガーから数秒ごとに継続的に取得される、ログに記録する必要があるデータ

データの量は次のとおりです。

  • ロガーあたり 1 日 1 MB または 9000 メッセージ

排除パターン:

  • データは、作成から 30 日後にシステムによって自動的に削除される必要があります
  • データの 60% は 30 日前に他のシステムによって取得され、取得時に削除されます

アプリケーションの読み取り：

  • データが読み取られると、一度にすべてのメッセージがシステムから削除されます
  • データは作成後、最短で 1 時間、最新で 30 日後に読み取られます。平均は14日。

平均:

  • データ保存の平均時間は 14 日間であり、40,000 メッセージまたはロガーあたり 13MB になると計算しました
  • データベースに保存されるデータの総量は平均で 130 GB です。

私の質問:

  • どのデータモデルを使用しますか?
  • 何個のシャードを使用しますか?

次のデータ モデルを検討しました。

  • 埋め込み: メッセージの配列を含むロガーごとのドキュメント。ドキュメントが大きくなったときのディスクの再配置が原因で不良
  • ロガーごとに制限されたコレクション。ディスクの使用量が多く、データが上書きされるまでの時間が不正確なため、悪い
  • 静的データ用のロガーのコレクションと、TTL 機能を使用するメッセージ用のロガーごとのコレクション。10,000のコレクションは大丈夫ですか？
  • 静的データ用のロガーのコレクションと、TTL を使用するすべてのメッセージ用の単一のコレクション、および vehicle と messageId を含む複合インデックス。そのコレクションは本当に大きくないですか？
  • 静的データ用のロガーのコレクションには、id 参照を持つ事前に割り当てられた配列と、インデックス付きの id を持つすべてのメッセージのコレクションが含まれます。複雑すぎる？

他のデータモデルを提案することは自由です

4

1 に答える 1

1

4 番目のオプションが最適です。コレクションがどれだけ大きくても心配する必要はありません。適切なシャード キーが選択されていることを確認する必要があります。

この場合、適切なシャードを選択するための鍵は、メッセージが実際にどのように見つかるかによって異なります。メッセージ ID と、それらを読み取り、ID を照会するだけの外部アプリケーションがありますか? または、メッセージの全文検索を行っていますか? 外部アプリは、メッセージが作成されたロガーと日時を認識していますか?

考慮事項:

  • ロガーをシャード キーにすると、大きすぎて分割できないチャンクになってしまいます。
  • datetime をシャード キーにすると、共有キーが原因で配布が不十分になります。
  • 外部アプリケーションがメッセージ ID で検索する場合は、ハッシュされたメッセージ ID をシャード キーにします。これにより、適切な配布と移動可能なチャンクが保証されます

静的データ用に別のコレクションを用意する必要はありません。

前述したように、これを設計するための鍵は、ログ メッセージが外部システムによって正確にどのように検出されるかを明確にすることです。

于 2013-08-15T02:22:39.777 に答える