2

序章：

  • システムは現在2つのデバイスで構成されています。
  • 各デバイスには、データを測定する10個のノードがあります。そのデータは5秒ごとにDBに書き込まれます。
  • 今のところ、そのセットアップの最大50：1（読み取り：書き込み）比を見積もっています。これは、新しいデバイス/ノードが導入されたときに変更される可能性が非常に高くなります。
  • 私は現在、すべてを1つのドキュメントに埋め込んでいます（例：http：//pastebin.com/4dATY5NF）
  • 私の3つの主なユースケースは次のとおりです。
    • DBに測定を追加する
    • すべてのノードから最後の測定値を取得します（5つのノードの場合、これは5つの測定値を返します）
    • 特定の日の測定値のリストを取得します（入力日時の基準に一致する測定値の長いリスト）。

問題：

私の主な関心事は、時間の経過とともに大きく成長するドキュメント（埋め込まれた測定値の配列への挿入）と、特定の日付/時刻範囲で測定値を照会するのを困難にする一般的なドキュメント構造についてです。

たとえば、5秒ごとにデータを報告するノードが1つしかない場合でも、組み込みアレイの測定の総数（1日のみ）は24 * 60 * 60/5=17280です。1か月に5つのノードをレポートすると、次のようになります。518400要素を持つ5つの組み込みアレイ（1つのドキュメントに！）。デバイスが動作する時間が長いほど、接続されている各ノードの測定値の埋め込み配列に含まれるエントリが多くなります。

質問：

  • 推定された読み取り/書き込み比率は、埋め込みとリンクの決定にどのように影響しますか？

  • この場合、埋め込みのすべての優れた点を犠牲にして、データを2つのコレクションに分割することは正当化されますか？

    私が考えていたのは、たとえば、デバイス/ノード構成用の1つのコレクション（情報があまりないためここに情報を埋め込む）と、測定用の2番目のコレクション（デバイスとノードを参照）です。これにはDBの呼び出しに数回かかるコストがかかると思いますが、パフォーマンスとメモリ使用量の点では優れています。

4

1 に答える 1

2

順番に ：

  • そうではありません。無限に成長する構造を単一のドキュメントに埋め込むことは拡張性がないため、避ける必要があります。各測定値を単一のドキュメントとして保存することをお勧めします。書き込みのパフォーマンスはより安定しますが、読み取り/書き込みの比率はあまり関係ありません（MongoDBは成長するドキュメントを定期的に移動する必要があるため、書き込みの待ち時間が急増する可能性があります）。
  • 埋め込みについては、実際には多くの「良いこと」はありません。クエリが複雑になり、埋め込み構造のごく一部を取得する方法がありません。そのため、正当化されるだけでなく、2つの別々のコレクションに移動することを強くお勧めします。将来性のあるスキーマを埋め込む場合は、最上位のドキュメントをクエリするときに埋め込み構造全体が常に必要であり、システムが処理する必要のあるユーザーやデータの数に関係なく、その埋め込み構造のサイズが制限されている場合に限ります。
于 2012-10-19T09:45:09.607 に答える