【ITニュース解説】DocumentDB 0.116: $group distinct scan

DocumentDBは、人気の高いオープンソースのリレーショナルデータベースであるPostgreSQLの拡張機能として、MongoDBのAPIを提供している。これにより、MongoDB用に開発されたアプリケーションを、PostgreSQLの安定性や柔軟性を活かしつつ、そのまま実行できるのが大きな特徴だ。Microsoftが主な貢献者として開発を推進しており、Azure DocumentDBでの顧客フィードバックを基に機能改善が続けられている。

今回発表されたDocumentDB 0.116では、特にデータベースの性能を大きく左右する重要な最適化が導入された。それは「$group distinct scan」という機能で、特定の集計クエリの処理速度を劇的に向上させるものだ。データベースにおいて、データの中から重複を除いてユニークな値だけを取り出す処理は非常によく使われる。例えば、ある製品の購入履歴から「購入された製品の種類」だけを知りたい場合などがこれに該当する。このような用途では、$groupという操作が使われる。

これまでのDocumentDBでは、大量のデータの中からユニークな値を抽出する際、インデックスが利用可能であっても、まずそのインデックスに存在する全てのデータ（今回の例では50,000件）を読み込み、その後で重複するデータをデータベース側で排除するという手順を踏んでいた。これは、必要な情報がわずか（例えば100種類）であっても、不要な多くのデータを一度読み込む必要があるため、特にデータ量が増えるにつれて処理時間が長くなるという課題があった。

DocumentDB 0.116で導入された「$group distinct scan」は、この非効率な部分を根本的に改善する。この新しい最適化が有効になると、データベースはインデックスを「ジャンプ」して、ユニークな値だけを効率的に探し出すことができるようになる。つまり、50,000件のインデックスエントリ全てを読み込むのではなく、最初から目的の100種類のユニークな値に直接アクセスし、それらだけを読み込むことが可能になる。これにより、データベースが処理する必要があるデータの量が大幅に減り、クエリの実行速度が向上するのだ。

この記事では、この最適化の効果を具体的な例で示している。まず、50,000件のドキュメント（データ）を用意し、その中にaというフィールドを設けて、そこに100種類の異なる値をランダムに割り当てる。そして、aフィールドに対してインデックス（a_1）を作成した。このデータに対して、{$group: {_id: "$a"}}, {$sort: {_id: 1}} という集計クエリを実行し、aフィールドのユニークな値を抽出し、並べ替えるというパイプラインを実行する。

このクエリを、最適化の基準となるMongoDB 8.0.28、旧バージョンのDocumentDB 0.114-0、そして新バージョンのDocumentDB 0.116-0（新機能を有効にした状態）のそれぞれで実行し、その性能を比較した。

MongoDB 8.0.28のリファレンス環境では、このクエリに対して理想的な実行計画が採用された。それは「DISTINCT_SCAN」と呼ばれる効率的な方法で、インデックスから直接100個のユニークなキーだけを読み込み、ドキュメント本体へのアクセスは一切行わない。これにより、非常に高速に100グループの結果を返している。

一方、最適化前のDocumentDB 0.114-0では、MongoDB API経由で同じクエリを実行すると、「IXSCAN」というステージで50,000件全てのインデックスエントリを読み込んでいた。その後、「GROUP」ステージでこれらのエントリから重複を排除し、最終的に100グループに集約していた。PostgreSQLのネイティブな実行計画を見ても、Index Only Scanが50,000行を読み込んでいることが確認できる。これは、目的の結果が100行しかないにもかかわらず、その500倍ものデータをまず読み込むという非効率性を示している。

しかし、DocumentDB 0.116-0でdocumentdb.enableGroupByDistinctScanという設定を有効にすると、状況は一変する。このバージョンでは、クエリの実行計画に「DISTINCT_SCAN」が組み込まれるようになり、MongoDBのリファレンス環境と同様に、インデックスから直接100個のユニークなキーだけを効率的に読み取るようになった。具体的には、totalKeysExamined（検査されたキーの総数）が50,000から100に激減し、totalDocsExamined（検査されたドキュメントの総数）も0のまま維持されている。これは、PostgreSQL内部でもDocumentDBApiDistinctQueryScanという新しいオペレーターが導入され、Index Only Scanが実際に読み込む行数が100行に削減されたことを意味する。これにより、不要な49,900件ものインデックスエントリを処理する必要がなくなったのだ。

この結果は、DocumentDB 0.116-0が、この種の集計クエリにおいてMongoDB 8.0.28と全く同じレベルの物理的な効率性を達成したことを明確に示している。つまり、両者ともに、グループごとに1つのインデックスエントリを読み込むだけで、ドキュメント本体へのアクセスなしに結果を生成できるようになった。旧バージョンのDocumentDB 0.114-0と比較すると、集計処理に流し込まれるインデックスエントリの数が50,000件から100件へと500分の1に削減されたことになる。

この「$group distinct scan」の最適化は、単にDocumentDBがMongoDBのAPIに互換性を持つだけでなく、そのクエリを内部的にPostgreSQLの最も効率的なアクセス戦略に変換できるというDocumentDBの強みを改めて示している。システムエンジニアにとって、これはMongoDBアプリケーションをDocumentDB上で実行する際に、同じクエリでも遥かに高いパフォーマンスを期待できることを意味し、データベース選択の重要な判断材料となるだろう。大規模なデータに対して、ユニークな値を集計するような処理が多いアプリケーションにとっては、この最適化がもたらす性能向上は計り知れない価値がある。