Bucket パターンと Computed パターン

MongoDBの熟練エンジニアは、直感だけでスキーマを設計しません。繰り返し発生する課題を解決する、実績のあるパターンのライブラリを活用します。これらのパターンには、MongoDBのストレージエンジン、インデックス構造、集計パイプラインがさまざまなドキュメント形状とどのように作用するかについて、経験から得られた知見がまとめられています。Bucket PatternとComputed Patternは、パフォーマンスが重視されるアプリケーションで特に効果の大きい2つのパターンです。

各センサーの測定値を個別のドキュメントとして保存するIoTシステムを考えてみましょう。1秒に1回測定するセンサーは、1日に86,400個のドキュメントを生成します。つまり、センサー1台につき1日あたり86,400個のインデックスエントリが必要となり、インデックスサイズが非常に大きくなり、1日分のデータを検索する際の操作数も膨大になります。24時間分のデータを読み取るには、数万個の小さなドキュメントを取得しなければならず、非常に非効率です。

Bucket Patternでは、関連する小さなドキュメントを1つの大きなドキュメント（「バケット」）にまとめます。測定値ごとに1つのドキュメントを作成する代わりに、1時間分の測定値を1つのドキュメントに格納します。これにより、ドキュメント数を3,600個から1個に、インデックスエントリ数を3,600個から1個に削減できます。バケットドキュメントには、測定値の配列と、書き込み時に計算したサマリー統計が含まれます。これにより、インデックスサイズが大幅に縮小し、範囲クエリのパフォーマンスが向上します。

新しい測定値が届いたら、センサーと時刻に対応する現在のバケットドキュメントを検索し、$push で measurements 配列に追加し、$inc で count をインクリメントして、アトミックに更新します。upsert: true を使用すると、現在の時刻のバケットがまだ存在しない場合に MongoDB が新しいバケットドキュメントを作成します。

あるセンサーの指定した時間範囲におけるすべての測定値を取得するには、sensorId と date の範囲でバケットドキュメントをクエリします。その後、集計結果には事前計算済みのサマリーを使用するか、測定値を1件ずつ取得するには measurements 配列に対して $unwind を使用します。24時間分のデータをクエリする場合、現在は個別のドキュメント86,400件ではなく、バケットドキュメント24件を読み取るため、取得するドキュメント数を3,600分の1に削減できます。

Computed パターンは、コストの高い集計を write 時に事前計算し、その結果をドキュメントに直接保存します。読み取り時にすべてのレビューを合計して商品の平均評価を計算する代わりに、新しいレビューが追加されるたびに計算し、商品ドキュメントの reviewCount と並べて avgRating に保存します。読み取りのコストはほぼゼロになり、事前計算済みのフィールドを返すだけで済みます。

新しいレビューが届いたら、最初から再計算するのではなく、同じ操作の中で Computed フィールドをアトミックに更新します。$inc で reviewCount と ratingSum をインクリメントし、その後 avgRating を再計算します。MongoDB では、更新後の count と sum から平均を設定するために $divide を使用するパイプライン形式の更新（MongoDB 4.2 以降）でこれを実行できます。

Computed パターンは、write よりも read が圧倒的に多く、読み取り時の計算コストが高い場合に最も効果を発揮します。商品の平均評価、リーダーボードのスコア、記事の閲覧数、収益の合計などは、いずれも適した候補です。その代わり、write 処理がやや複雑になり、元データが変更されたときに Computed 値の整合性を維持する必要があります。read と write の両方が頻繁な場合は、同期的に更新するのではなく、定期的に再計算するバックグラウンドジョブを検討してください。

Bucket パターンと Computed パターンは、組み合わせて使われることがよくあります。センサーデータシステムでは、測定値を1時間ごとのバケットドキュメントにまとめ（Bucket パターン）、その日の全体について min/max/avg を保存した事前計算済みの日次サマリードキュメントを維持できます（Computed パターン）。この階層化されたアプローチにより、日ごとの傾向を表示するダッシュボードは単一のドキュメントを読み取るだけで済み、詳細表示のクエリも24個の時間単位のバケットドキュメントだけをスキャンすれば済みます。

バケットドキュメントは無制限に大きくならないようにする必要があります。MongoDB のドキュメントサイズには16 MBの上限があるためです。データレートの高いセンサーでは、時間で区切ったバケット（例: 1時間ごと、または1日ごと）を使用してください。更新フィルターの count: { $lt: 3600 } ガードにより、バケットが大きくなりすぎるのを防げます。バケットが容量に達すると、upsert によって新しいバケットが自動的に作成されます。本番環境でバケットの充填率を監視し、データレートに合わせてバケットサイズを調整してください。

バケットコレクションの主なインデックスは、クエリパターンをカバーする必要があります。{ sensorId: 1, date: 1 } のような複合インデックスを作成します。この複合インデックスにより、センサーと時間範囲でフィルタリングするクエリはインデックスを直接利用できます。86,400件の個別ドキュメントの timestamp フィールドにインデックスを作成する場合と比べ、バケットコレクションのインデックスは1センサー・1日あたり24個のエントリしか保持しません。インデックスサイズを3,600分の1に削減できるため、ワーキングセットを RAM に収めやすくなり、パフォーマンスが大幅に向上します。

このレッスンでは、Bucket パターンによって多数の小さなドキュメントを少数の大きなドキュメントにまとめ、インデックスサイズを大幅に削減して範囲クエリのパフォーマンスを向上させること、Computed パターンによってコストの高い集計を write 時に事前計算し、読み取り時には保存済みの値を即座に返せるようにすること、そしてこの2つのパターンを効果的に組み合わせられることを学びました。次は Extended Reference パターンと Subset パターンについて学びます。