アプローチ1（A）： すべてに対して単一のデータベースを作成します。 （単一のコレクションを使用）
長所：
- メンテナンスの削減：バックアップ、データベースユーザーの作成、復元など
短所：
- データベースレベルのロック 大規模なデータベースにインデックスを作成するための
- 特定のセンサーデータに対して操作を実行するには、センサー固有のコレクションのみをフェッチするようにインデックスを追加する必要があります
- createnotにバインドされています64を超えるインデックス 単一のコレクションで。悪いインデックス戦略に聞こえますが。
アプローチ1（B）： すべてに対して単一のデータベースを作成します。 （センサーごとに1つのコレクションを使用）
長所：
- メンテナンスの削減：バックアップ、データベースユーザーの作成、復元など
- モノリシックコレクション全体からセンサー固有のデータを識別するためのインデックスを作成する必要性を最小限に抑えます
- すべてのセンサー固有のクエリは、特定のコレクションのみを対象としています。単一の大きなコレクションと比較して、大きなワーキングセットをメモリに取り込む必要はありません。
- 比較的小さなコレクションでインデックスを作成する方が、単一のDBで大きなコレクションを作成するよりも実行可能です
短所：
- 作成するインデックスが多すぎる可能性があります。 （すべてのコレクションのインデックスの総数の合計）。
- 多数のインデックスには、より多くのメンテナンスが必要です。
- WiredTigerは、コレクション用に1つのファイルを作成し、インデックス用に1つのファイルを内部的に作成します。多数のセンサーでユースケースが拡大する場合。最終的に64Kのオープンファイル制限を使用する可能性があります。
パフォーマンスに関して、データをセンサーごとに分割するか、指標ごとに分割するかは重要ですか？
- これは、分析アプリに期待されるアクセスパターンによって異なります。
パフォーマンスに関しては、センサー情報専用のコレクションを作成してからデータ用のコレクションを作成する必要がありますか、それとも同じコレクションに2つをマージする必要がありますか？
-
センサーメタデータとセンサーデータのコレクションを作成する必要がある場合があります。収集されたすべてのセンサーデータでのセンサーメタデータの重複を最小限に抑えます。
-
ウィリアムズのブログ投稿 このパターンのデザインについてはこちらをご覧ください。
いつものように、サンプルスキーマを設計し、テスト環境内でクエリをテストすることをお勧めします。