【ITニュース解説】DocumentDB 0.117: scalar $group index pushdown

今回のニュースは、データベースの性能を向上させる「scalar $group index pushdown」という新しい最適化機能が、DocumentDB 0.117というバージョンで導入されたことについて解説している。これはシステムエンジニアを目指す上で非常に重要な、データベースの効率的な使い方に関する話だ。

まず、DocumentDBとは何かを理解しておこう。DocumentDBは、PostgreSQLという安定したリレーショナルデータベースに、MongoDBというドキュメント指向データベースの便利な機能を加えるための拡張機能である。つまり、MongoDBのように柔軟なデータ形式（JSONに似たドキュメント形式）を使いながら、PostgreSQLの持つ高い信頼性や強力なデータ管理機能を活用できるというものだ。Microsoftがこの開発を主導しており、多くの企業からのフィードバックを受けて改善が続けられている。

今回導入された「scalar $group index pushdown」とは、データベースで行われる「集計クエリ」の処理速度を大幅に向上させる技術である。集計クエリとは、例えば「全ての商品の合計価格を出す」とか「ある期間の売上総額を計算する」といった、大量のデータから特定の値を計算する処理のことだ。特に「scalar $group」は、「_id: null」のようにグループ化する基準がなく、データ全体の合計値などを計算するようなシンプルな集計を指す。

通常、このような集計クエリを実行する場合、データベースは集計に必要なデータだけでなく、そのデータが格納されているドキュメント全体を読み込む必要があった。例えば、商品の合計金額を計算する際に、商品の説明文や画像データなど、集計には不要な情報まで読み込んでしまうと、無駄な処理が増え、データ量が多いほど実行に時間がかかってしまう。この非効率な状態を改善するのが、今回の最適化の目的だ。

この最適化の核心は「インデックス」の活用にある。インデックスは、データベースの「索引」のようなもので、特定のデータ（例えば商品名や価格など）を素早く見つけ出すための仕組みである。これまでのシステムでは、集計クエリにおいて、このインデックスを十分に活用できていなかった。しかし、新しい「scalar $group index pushdown」機能が導入されたことで、集計に必要な値がインデックス内に含まれている場合、データベースはデータ本体（ペイロードと呼ばれる、集計に不要な大きなデータ部分）を読み込まずに、インデックスの情報だけで集計処理を完結させられるようになったのだ。これにより、読み込むデータ量が劇的に減り、クエリの実行速度が向上する。

今回のニュース記事では、この効果を検証するために、50,000件のテストデータを用意している。このデータには「a」という数値と、200バイトの大きな「payload」が含まれており、「a」にインデックスが作成されている。そして、「a」の合計値を計算する集計クエリ（{$group: {_id: null, total: {$sum: "$a"}}}）が実行された。

このクエリの実行結果を、異なるデータベースやバージョンで比較すると、最適化の効果がはっきりとわかる。 まず、従来のMongoDB 8.0でこのクエリを実行した場合、特別な指示（ヒント）がないと、データベースは50,000件全てのドキュメントを読み込む「COLLSCAN（コレクションスキャン）」という方法で処理を行った。これは、不要なペイロードデータまで読み込むため、非効率的である。MongoDBで高速化するには、開発者が「{ hint: { a: 1 } }」のように、どのインデックスを使うべきかを明示的に指定する必要があった。これにより、MongoDBはインデックスのみを読み込む「IXSCAN（インデックススキャン）」に切り替え、データ本体の読み込みを回避できる。

次に、最適化前のDocumentDB 0.116で同じクエリを実行した場合も、MongoDBと同様に、全件スキャンやデータ本体へのアクセスが発生し、50,000件のドキュメントと関連するデータブロックを読み込んでいた。この時、データベースがメモリから直接データを読み込めた回数を示す「shared-buffer hits」は2,101回と多かった。

しかし、DocumentDB 0.117で新機能「scalar $group index pushdown」を有効にして同じクエリを実行すると、結果は大きく変わった。DocumentDBは、インデックスだけを読み込む「IXSCAN」を実行し、さらに「isIndexOnlyScan: true」と示されているように、データ本体には全くアクセスしない「Index Only Scan（インデックスオンリースキャン）」という非常に効率的な方法を採用したのだ。これにより、50,000件のインデックスエントリのみを読み込み、データ本体の読み込みはゼロになった。メモリからの読み込み回数（shared-buffer hits）もわずか24回に激減し、大幅なパフォーマンス改善が見られた。

この改善の背景には、PostgreSQLが持つ優れた「コストベースのクエリプランナー」の存在がある。クエリプランナーは、クエリを実行する際に、どのインデックスを使い、どのような順序で処理するのが最も効率的かを自動的に判断する「頭脳」のようなものだ。今回の最適化は、このプランナーが、インデックスだけで集計できる「Index Only Scan」という選択肢を認識し、そのコストが最も低いと判断できるようにしたものだ。開発者がMongoDBのように「ヒント」で手動で指示しなくても、PostgreSQLのプランナーが最適な方法を自動で選び出してくれる。これは、開発者の手間を省き、常にデータベースの性能を最大限に引き出せるという点で、DocumentDBの大きな強みとなる。クエリプランナーが最適な判断をするためには、データベースの統計情報を最新に保つ「VACUUM (ANALYZE)」というメンテナンス作業が重要だが、これは通常PostgreSQLの自動機能によって行われる。

この「scalar $group index pushdown」という機能は、単に新しい実行計画の名前が増えただけでなく、データベースが実際にデータを読み込む量を減らし、処理速度を向上させるという、具体的な性能改善をもたらした。DocumentDB 0.117は、MongoDBの操作のしやすさと、PostgreSQLの賢いクエリ最適化能力を組み合わせることで、開発者にとってさらに魅力的な選択肢となったと言えるだろう。これは、大量のデータを扱うシステムを開発・運用する上で、非常に有益な進化である。