ある製造企業が、工場の 5,000 台の機器から 1 秒ごとにセンサーデータ（機器 ID、センサー値、タイムスタンプ）を Azure Cosmos DB for NoSQL に書き込んでいる。6 ヶ月後、「特定の機器 ID の過去 24 時間のデータを取得するクエリ」が 10〜15 秒かかるようになった。パーティションキーを `sensor_type`（温度・圧力・振動の 3 種類）に設定していることが判明した。この問題の根本原因と最適な解決策はどれか。
- A. データが 6 ヶ月分蓄積されたため Cosmos DB の容量上限を超えている — データを Azure Blob Storage にアーカイブする
- B. Cosmos DB のインデックス設定が不足している — タイムスタンプフィールドにカスタムインデックスポリシーを追加する
- C. パーティションキーの選択が不適切でホットパーティション＆クロスパーティションクエリが発生している — 機器 ID をパーティションキーに再設計する
- D. Cosmos DB のスループット（RU/s）が不足している — Request Units を 10 倍に増加させる
解答と解説を見る
正解: C
根本原因は 2 つある。第一に、パーティションキーが `sensor_type`（3 種類のみ）のため、5,000 台 × 1 秒 = 毎秒 5,000 回の書き込みが 3 つのパーティションに極端に集中するホットパーティション問題が生じる。第二に、「特定の機器 ID の 24 時間データ」を取得するクエリは機器 ID と sensor_type が一致しないため、全パーティションを横断するクロスパーティションクエリになり、データ量に比例して遅くなる。解決策は機器 ID をパーティションキーにすることで、書き込みが 5,000 パーティションに均等分散し、特定機器のクエリが単一パーティション内で完結する。選択肢 D の RU 増加は一時的に改善するかもしれないが、設計上のホットパーティションとクロスパーティション問題の根本を解決しない。選択肢 A は誤りで、Cosmos DB はストレージを無制限に自動スケールするため容量上限の問題ではない。選択肢 B のカスタムインデックスはクエリによっては有効だが、クロスパーティションスキャンの根本問題を解決しない。