Elasticsearch simdvecの構築方法

Elasticsearchにおけるすべてのベクトル検索クエリは、Hierarchical Navigable Small World（HNSW）トラバーサル、転置ファイル（IVF）スキャン、再ランキングパスのいずれであっても、結局は同じ問題に帰着します。すなわち、クエリごとにベクトル間の距離を何百万回も計算しなければならないということです。Elasticsearchは、float32からint8、bfloat16、バイナリ、Better Binary Quantization（BBQ）まで、幅広いデータ型と量子化戦略をサポートしています。それぞれにメモリ、スループット、リコールのトレードオフが異なります。そのすべての背後にあるのは、simdvecという単一のエンジンです。

私たちは、ハードウェアが許す限りすべての距離計算を高速に行うためにsimdvecを構築しました。この記事では、simdvecを構築した理由、その内部構造、そしてどのような場面で最も効果を発揮するのかを説明します。

レースカーのような構造

F1愛好家として（当社チームには以前フェラーリのF1チームで勤務経験があるメンバーもいます）明確な類似点を見いだせます。F1カーは、最高のラップタイムを達成するという唯一の目的のために設計されています。エンジンのパワー、空力性能、シャーシ設計は、その結果に貢献する限りにおいてのみ重要です。ベクトルデータベースについても同様で、インデキシングのスループット、クエリのレイテンシ、リコールが成功を定義します。

最終結果は重要ですが、最高レベルのパフォーマンスを達成するには、各コンポーネントが最高の状態である必要があります。必要十分ではなく、そのカテゴリーで最高でなければなりません。simdvecはその考え方で構築されており、システムの重要な部分であるエンジンに焦点を当てています。これは、専用に構築された、単一命令多重データ（SIMD）最適化カーネルライブラリで、JavaからPanama外部関数インターフェース（FFI）を介して呼び出される、手動で調整されたネイティブC++距離関数を提供します。一括スコアリング、キャッシュラインのプリフェッチ、Elasticsearchで使用されるすべてのベクトルの種類とレイアウトをサポートしています。

それがすべてのクエリの背後にあるエンジンです。

自社開発した理由

当社は2023年にApache LuceneのPanama Vector APIを使用してスタートしました。float32の内積計算にはうまく機能しましたが、すぐにその機能ではElasticsearchのニーズには対応できなくなりました。Elasticsearchは、int8、int4、bfloat16、シングルビット、非対称BBQなど、幅広い量子化されたベクトルタイプをサポートしています。それぞれにSIMD戦略、パッキングレイアウト、アキュムレータの要件が異なります。型カバレッジに加えて、Elasticsearchのスコアリングパスは単一ペアのスループット以上のものを要求します。HNSWは1回のパスで複数のグラフ隣接ノードをスコアリングする必要があり、IVFはプリフェッチを使用して数千の候補を一括スコアリングする必要があり、ディスクベースのスコアリングはコピーせずにmmapされたメモリ上で直接動作する必要があります。入手可能なものを調べてみましたが、すべての条件を満たすものは見つかりませんでした。

そこで、simdvecを構築しました。これは、JavaからFFI経由で呼び出される手作業で調整されたネイティブC++カーネルで、一括スコアリング、プリフェッチ、Elasticsearchが使用するすべてのベクトルタイプをサポートしています。ライブラリを所有することで、私たちはフルスタックを制御できます。BBQのような新しい量子化タイプを追加すると、システム全体にわたって調整されたSIMDカーネルが組み込まれます。上流のライブラリがそれをサポートするのを待つ必要はなく、いかなる型においてもパフォーマンスに妥協することはありません。Elasticsearchにおけるすべてのベクトルクエリ（HNSW、IVF、リランキング、ハイブリッドなど）は、実際に使用する操作とタイプに基づいて構築されたこのエンジン上で実行されます。

simdvecには、x86とARMそれぞれに対応したネイティブライブラリが用意されており、起動時に複数の命令セットアーキテクチャ（ISA）階層を選択できます。FFIを介したJavaからの呼び出しオーバーヘッドは非常に低く、1桁ナノ秒です。

ランドスケープ

SIMD最適化されたベクトル距離カーネルを構築しているのは私たちだけではありません。このエコシステムは豊かで、私たちはsimdvecがどのように動作するのかを理解したいと考えました。プロジェクトの優劣を決めるのではなく、背景情報を提供し、Elasticsearchエンジンの位置づけを説明することが目的です。私たちは異なるアプローチを表す3つのプロジェクトを基準点として選びました。

• jvector：ベクトル化された距離計算にPanama Vector APIを使用するJava近似最近傍探索（ANN）ライブラリ。x86上ではオプションでネイティブCアクセラレーションが可能。

• FAISS：手作業で調整されたAVX2/AVX-512カーネルを備えた、広く展開されているオープンソースのベクトル検索フレームワーク。

• NumKong （旧称 SimSIMD）：距離関数、行列演算、地理空間計算など、2,000種類以上の手作業で調整されたSIMDカーネルを網羅した包括的なスイート。

各プロジェクトは異なる目的を持ち、異なるトレードオフをもたらします。Elasticsearchが必要とする特定の操作におけるsimdvecのパフォーマンスのコンテキストを提供するために、それらからの参照番号を含めています。

測定方法

simdvecとjvectorのベンチマークは、FFIオーバーヘッドを含めた標準JVMマイクロベンチマークハーネスであるJMHを使用してJavaで記述されています。NumKongベンチマークとFAISSベンチマークについては、標準的なC++マイクロベンチマークフレームワークであるGoogle Benchmarkを使って小さなC/C++ハーネスを作成しました。どちらのフレームワークも、ウォームアップと反復キャリブレーションを含めた1操作あたりのナノ秒数の精度を報告しています。ハードウェアパフォーマンスカウンターを介して、すべてのライブラリが両方のプラットフォームでSIMDを使用していることを確認しました。ベンチマークコードはすべて、リンク先のGitHubリポジトリ（およびsimdvecの場合はelasticsearchリポジトリ）で公開されています。

ソフトウェア： JDK 25.0.2、JMH 1.37、GCC 14、Google Benchmark（最新版）。

一度に1つのベクトル

ベクトル検索における最も基本的な操作は、2つのベクトル間の距離を計算することです。すべてのHNSW近隣評価、すべてのIVF候補スコア、すべての再ランク比較は、この内側のループに還元されます。

両プラットフォームで1024次元における単一ペアのスループットを測定しました。まず、ベースラインとなる型であり、エコシステムの競争が最も激しいfloat32から評価を開始しました。simdvecをFAISSおよびjvectorと比較しました。NumKongはfloat32にfloat64アキュムレータを使用するため、スループットよりも数値精度を優先し、処理速度が3.2倍から5.3倍遅くなる（プラットフォームによって異なる）ため、比較対象から除外しました。比較を同じように保つために、代わりにint8でNumKongのベンチマークを行います。ここでは、simdvecと同じアキュムレータ戦略を使用しています。

x86アーキテクチャーでは、FAISS AVX-512が23ナノ秒と最速のシングルペアカーネルです。simdvec AVX-512は28ナノ秒で続きますが、この差はFFI呼び出しのオーバーヘッドを反映したものです。どちらもマルチアキュムレータアンローリングを備えた512ビットFMAを使用しています。AVX2レベルでは、両者の性能差ははるかに小さく、それぞれ36ナノ秒と39ナノ秒で、どちらも256ビットのレジスタとメモリのロード幅によって制約されています。jvectorはJava Panama Vector APIを使用して44ナノ秒で到達します。Panamaは優れたSIMDコードを生成しますが、手作業で調整されたC++ intrinsicsが優位を保っています。

ARMでは、simdvecは70ナノ秒でリードしており、110ナノ秒のjvectorと156ナノ秒のFAISSをはるかに上回っています。simdvecはaarch64向けにNEONカーネルを独自にチューニングしました。JvectorにはネイティブのARMコードがなく、Panamaに依存しています。FAISSは明示的なNEON組み込み関数ではなく、コンパイラの自動ベクトル化に依存しているため、差が大きくなっています。これは、カーネルライブラリを所有することによる実用的な利点を反映しています。ElasticsearchがGravitonに拡張された際、専用に構築されたNEONカーネルを追加しました。jvectorもFAISSも、ARMネイティブコードを同程度に優先しているわけではありません。

しかし、Elasticsearchはfloat32だけを評価するわけではありません。Int8の量子化はメモリ使用量を4分の1に削減し、bfloat16は2分の1に、BBQは32分の1に削減します。それぞれのタイプには独自のSIMD戦略が必要であり、simdvecはすべてのタイプ向けに手動チューニングされたネイティブカーネルを提供しています。

比較したライブラリの中で、int8用の同等のカーネルを備えているものはNumKongのみでした。int8ドット積、二乗ユークリッド、余弦を1024次元で測定しました。

Int8シングルペアスコアリング（1024次元、ns/vec 演算 - 数値が小さいほど良い）

どちらのアーキテクチャでも、NumKongは小～中次元では同等かより高速です。その差は主に呼び出しのオーバーヘッドが少ないことに起因します（Cの直接呼び出しとJavaのFFI）。より大きな次元では、simdvecが追いつき、より効率的なカーネル実装（カスケードアンローリングを使用する）が呼び出しコストを償却します。次元が増えるにつれて、このギャップは閉じ、最終的には逆転します。クロスオーバーのサイズは、機能や構造によって768から1536の間となります。

Java FFIのオーバーヘッドが若干高いにもかかわらず、simdvecは高度に最適化されたC/C++ライブラリと同等の性能を発揮します。float32とint8の両方に対応した最適化されたカーネルを備えた唯一のライブラリであるだけでなく、ARMアーキテクチャではトップクラスの性能を誇り、x86アーキテクチャではFAISSにわずかに劣る程度（float32の場合）、そして両アーキテクチャにおいてNumKongに非常に近い性能（int8の場合）を実現しています。また、bfloat16、int4、binary、BBQについては、代替手段は存在するものの、simdvecは各型のデータレイアウトに合わせて手作業で調整されたSIMDによって差別化を図っています。

しかし、実際の検索エンジンは一度に1つのベクトルを評価するのではなく、クエリごとに数千のベクトルを評価します。次の質問は、そのスケールで何が起こるかということです。

一度に数千件

シングルペアのパフォーマンスは全体の一部に過ぎません。実際には、システムが負荷時にどのように動作するかが重要です。単一のHNSWクエリは数百のグラフ近傍をスコアリングすることがあります。IVFスキャンは、数千件の投稿リストエントリーをスコアリングすることがあります。リランクパスは数万の候補をスコアリングすることがあります。シングルペアのスループットは重要ですが、より重要なのは、多くのベクトルをどれだけ速くスコアリングできるか、そして作業セットがCPUキャッシュから溢れ出すにつれてパフォーマンスがどれだけスムーズに低下するかです。

simdvecは、あらゆるデータタイプに対して一括スコアリング機能を提供します。これらは単なる単一ペアカーネル上のループではなく、クエリベクトルを1次元ストライドごとに1回ロードし、複数のドキュメントベクトル間で共有するマルチアキュムレータ内部ループを使用します。次のバッチに対しては、明示的なキャッシュラインプリフェッチが行われます。jvectorもFAISSも同等の機能を提供していません（執筆時点では）。Jvectorには一括処理APIがないため、呼び出し元はループ内で一度に1組ずつスコアを計算します。FAISSはfvec_inner_products_nyを公開していますが、執筆時点では、クエリ償却やプリフェッチを行わずに、シングルペア距離関数のループとして実装されています。

Float32。カーネルレベルでのインパクトを測定するために、HNSWのような散在グラフの近傍検索をシミュレートするランダムアクセスパターンを用いて、1024次元float32ドキュメントベクトルの数を増やしながら単一のクエリのスコアを計算しました。3つのデータセットサイズ（32、625、32,500ベクトル）は、それぞれL1、L2、L3キャッシュを超えるように選択されています。

データがキャッシュに収まる場合、simdvecはどちらのプラットフォームでも最速ですが、カーネル演算が支配的であるため、マージンは控えめです。実際の分離は、ワーキングセットがL3を超えるにつれて現れます。x86では、simdvecのスコアは1ベクトルあたり95ナノ秒ですが、FAISSは165ナノ秒、jvectorは412ナノ秒です。ARM上でも同様の傾向が見られ、simdvecは162ナノ秒で安定しているのに対し、FAISSは347ナノ秒、jvectorは476ナノ秒に上昇します。simdvecのプリフェッチとクエリの償却により、シングルペアカーネル上の単純なループでは対応できない方法でメモリの待ち時間が隠され、メインメモリの奥深くで実際の検索ワークロードが動作する場所でその利点が広がります。

Int8。同じパターンは量子化された型にも当てはまります。int8ドット積の一括スコアリングを1024次元で測定し、データセットのサイズが同じL1、L2、L3キャッシュ境界を超えるように選択して、simdvecのバルクスコアリングをループ内のNumKongシングルペアスコアリングと比較しました。

x86では、simdvecは1.2倍～1.9倍高速で、これは明示的なプリフェッチとバッチ処理の組み合わせによってもたらされます。ARM環境では、すべてのデータセットサイズにおいて、simdvecが再び優位に立ちました（1.7倍から1.9倍高速）。その利点は、4つのベクトルを一度にバッチ処理することで、インターリーブアクセスパターンを介してメモリレベルの並列処理を実現することにあります。いずれの場合も、最も顕著な結果は最大のデータセットサイズで何が起こるかであり、それが最も重要な場所です。

結果は、二乗距離とコサインで同様のパターンを示し、ARMでは1.4倍から1.8倍、x86では1.3倍から3.0倍の速度向上が見られました（詳細はこちら）。

メモリが重要となる場合

本番環境のベクトルインデックスは通常、CPUキャッシュに収まりません。1024次元の10Mベクトルint8インデックスは10GBです。候補のスコアリングとは、DRAMからデータをストリーミングすることを意味し、そこでバルクスコアリングアーキテクチャが大きな違いを生むのです。

バルクスコアリング中のCPU内部で何が起こるかを測定するためにハードウェアパフォーマンスカウンターを使用し、メモリーレイテンシを隠すためには、アーキテクチャごとに根本的に異なる2つの戦略が必要であることを発見しました。

x86アーキテクチャでは、明示的なプリフェッチによってキャッシュミスが解消されます。バルクカーネルはベクトルを逐次的に処理し、次のベクトルを処理する前に1つのベクトルを完全に計算しながら、次のバッチのためのプリフェッチ命令を発行します。将来のデータはCPUが必要とする前にL1に取り込まれます。

ARMアーキテクチャでは、プリフェッチを使用しても、同じ逐次的なアプローチではパフォーマンスが低下しました。代わりに、バルクカーネルが4つのベクターからすべてのストライド位置でロードをインターリーブし、アウトオブオーダーエンジンに4つの独立したメモリストリームを提供します。CPUのデータの取得速度が速くなったわけではなく、メモリ要求の処理中に常に別の計算処理を行うことで、待ち時間を短縮しているのです。詳細な分析についてはこちらのGitHubイシューをご覧ください。

数字は2つの異なる物語を語っています。

1. x86アーキテクチャでは、プリフェッチによって139,000回のキャッシュミスが19,000回に減り、1サイクルあたりの命令実行数（IPC）が2倍以上になります。データセットのサイズが大きくなるにつれてプリフェッチによってコストのかかるDRAM往復処理が徐々に隠蔽されるため、データ量の増加によるメリットは大きくなり、L2レベルでは1.2倍、L3レベルを超えると2.8倍になります。

2. ARMではキャッシュミスはほとんど変わりません。変化するのは利用率です。インターリーブアクセスパターンによってパイプラインへの供給が維持されるため、バックエンドの停止時間が40%減少します。この利点は、データセットのサイズに関係なく一貫して1.8倍です。これは、データがキャッシュまたはDRAMから来ているかに関係なく、メモリレベルの並列処理が適用されるためです。

2つのアーキテクチャ、2つの戦略、結果は1つ：本番環境規模では、simdvecはベクトルがメインメモリ全体に分散している場合でも、CPUパイプラインを常にフル稼働させます。

Elasticsearchユーザーへの影響

これらのカーネルレベルの能力は相乗効果を発揮します。単一のベクトル検索クエリでは、HNSWグラフの走査、候補のスコアリング、再ランキングなど、数百万もの距離演算が計算される場合があります。数千回の同時クエリにおいて、1回の操作でナノ秒単位がクエリ遅延やクラスタスループットに直接変換されます。float32、int8、bfloat16、BBQのいずれを使用する場合でも、インデックスがメモリ上にあるかディスク上にあるかに関わらず、simdvecが基盤となるエンジンであり、これらのすべての操作は同じエンジンを通して実行され、ナノ秒単位まで最適化されています。

重要なポイントは、本番規模では、ベクトル検索のパフォーマンスは主に生のSIMDスループットによって決まるわけではないということです。システムのパフォーマンスは、数百万もの小さな演算処理において計算能力を維持しながら、メモリの遅延をいかに効率的に隠蔽できるかに大きく左右されます。

simdvecカーネルは、ほぼすべてのElasticsearchリリースで改善されています。新しい量子化タイプやハードウェアプラットフォームが登場すると、初日からチューニング済みのカーネルが提供されます。また、既に出荷されている実装を改良していくにつれて、既存の型もますます高速化していきます。

これが重要である理由

ほとんどの典型的な分析ワークフローは最終的にデータのグループ化に集約されます。ホストあたりの平均バイト数の計算、ユーザーごとのイベントのカウント、または次元全体でのメトリクスの集計など、コアとなる操作は同じです。キーをグループにマップし、実行中の集計を更新します。

小規模であれば、ほぼすべての適切なハッシュテーブルで問題なく動作します。大規模になると（数億のドキュメントと数百万の個別のグループなど）、詳細が重要になってきます。負荷係数、プローブ戦略、メモリレイアウト、キャッシュの動作によって、線形パフォーマンスとキャッシュミスの連続との間に違いが生じる可能性があります。

Elasticsearchは長年にわたってこれらのワークロードをサポートしてきましたが、コアアルゴリズムを最新化する機会を常に探しています。そのため、スイステーブルからヒントを得た新しいアプローチを評価し、それをES|QLが統計を計算する方法に適用しました。

スイステーブルとは？

スイステーブルは、GoogleのSwissTableによって普及し、後にAbseilやその他のライブラリに採用された最新のハッシュテーブルファミリーです。

従来のハッシュテーブルでは、ポインターの追跡やキーのロードに多くの時間を費やし、結局一致しないことが判明します。スイステーブルの特徴は、キーと値とは別に保存される制御バイトと呼ばれる小さなキャッシュ常駐配列構造を使用してほとんどのプローブを拒否し、メモリトラフィックを大幅に削減できることです。

各制御バイトは単一のスロットを表し、この場合、スロットが空かどうかと、ハッシュから導出された短いフィンガープリントの2つの項目をエンコードします。これらの制御バイトはメモリ上に連続的に配置され、通常16個のグループで構成されており、単一命令多重データ（SIMD）処理に理想的です。

スイステーブルは、一度に1つのスロットをプローブする代わりに、ベクトル命令を使用して制御バイトブロック全体をスキャンします。1回の操作で、CPUは入力キーのフィンガープリントを16個のスロットと比較し、空のエントリーを除外します。この高速パスを通過する少数の候補のみが、実際のキーのロードとの比較を必要とします。

この設計では、少量の追加メタデータと引き換えに、はるかに優れたキャッシュローカリティと大幅に少ないランダムロードを実現しています。テーブルが拡大し、プローブチェーンが長くなるにつれて、それらのプロパティはますます価値が高くなります。

中央にSIMDがあります

ここでの真の主役はSIMDです。

制御バイトは単にコンパクトであるだけでなく、ベクトル命令で処理されるように明示的に設計されています。1 回のSIMD比較で16個のフィンガープリントを一度にチェックできるため、通常はループとなる処理が複数の広範な操作に変わります。例：

実際には、これは次のことを意味します。

• ブランチ数の低減。

• プローブチェーンの短縮。

• キーメモリや値メモリからのロードの減少。

• CPU実行ユニットの利用率が大幅に向上。

ほとんどの検索は制御バイトのスキャンを通過することはありません。そうすれば、残りの作業は焦点が絞られ、予測可能になります。これはまさに、最新のCPUが得意とする種類のワークロードです。

SIMDの仕組み

仕組みを知りたい読者のために、テーブルに新しいキーを挿入すると何が起こるかを説明します。128ビットベクトルのPanama Vector APIを使用し、16の制御バイトを並列で処理します。

次のスニペットは、Intel Rocket LakeとAVX-512で生成されたコードを示しています。手順はその環境を反映していますが、設計はAVX-512に依存しません。同じ高レベルのベクトル操作が、同等の命令（AVX2、SSE、NEONなど）を使用して他のプラットフォームでも実行されます。

各命令は挿入プロセスにおいて明確な役割を果たします。

• vmovdqu：128ビットの xmm0レジスタに16個の連続制御バイトを読み込みます。

• vpbroadcastb：新しいキーの7ビットのフィンガープリントをxmm1レジスタのすべてのレーンにわたって複製します。

• vpcmpeqb: 各制御バイトをブロードキャストされたフィンガープリントと比較し、一致する可能性のあるマスクを生成します。

• kmovq + test：マスクを汎用レジスタに移動し、一致が存在するかどうかをすばやく確認します。

最終的に、ベンチマークにより、レジスタの幅を広げて32バイトまたは64バイトに拡張しても測定可能なパフォーマンス上の利点が得られないことが示されたため、一度に16個の制御バイトのグループをプローブすることに決定しました。

ES|QLにおける統合

Elasticsearchでのスイススタイルのハッシュの採用は、単なる置き換えではありませんでした。ES|QLには、メモリアカウンティング、安全性、コンピューティングエンジンの他の部分との統合に関して厳しい要件があります。

新しいハッシュテーブルを、ページリサイクラーやサーキットブレーカーアカウンティングなどのElasticsearchのメモリ管理と緊密に統合し、割り当てが常に可視かつ制限された状態になるようにしました。Elasticsearchのアグリゲーションは密に格納され、グループIDでインデックス化されるため、メモリレイアウトはコンパクトで高速に保たれ、反復処理も高速になります。また、ランダムアクセスを許可することで特定のパフォーマンスを最適化できます。

可変長バイトキーの場合、グループIDと一緒に完全なハッシュをキャッシュします。これにより、プローブ中に高価なハッシュコードを再計算する必要がなくなり、関連するメタデータを近くに保持することでキャッシュの局所性が向上します。再ハッシュ中は、値自体を検査せずにキャッシュされたハッシュと制御バイトに依存できるため、サイズ変更のコストが低く抑えられます。

実装における重要な簡素化の一つは、エントリーが決して削除されないことです。これにより、トゥームストーン（以前占有されていたスロットを識別するためのマーカー）の必要性がなくなり、空のスロットは実際に空のままになるので、プローブの動作がさらに改善され、制御バイトスキャンが効率的に維持されます。

その結果、スイステーブルの魅力となるパフォーマンス特性を維持しながら、Elasticsearchの実行モデルに自然に適合する設計が実現しました。

パフォーマンス

カーディナリティが小さい場合、スイステーブルのパフォーマンスは既存の実装とほぼ同等になります。これは予想どおりです。テーブルが小さい場合、キャッシュの影響は少なくなり、最適化するための調査もほとんど行われません。

カーディナリティが増加するにつれて、状況は急速に変化します。

上記のヒートマップは、異なるキーサイズ（8、32、64、128バイト）に対する時間改善係数を、1,000から10,000,000グループまでの基数にわたってプロットしています。カーディナリティが増加するにつれて、改善係数は着実に増加し、均一分布の場合は2～3倍に達します。

この傾向はまさに設計が予測していることです。カーディナリティが高くなると、従来のハッシュテーブルではプローブチェーンが長くなりますが、スイススタイルのプローブでは、SIMD対応の制御バイトブロック内でほとんどの検索が引き続き解決されます。

キャッシュの挙動が物語るもの

速度の向上をよりよく理解するために、同じJMH benchmarks をLinuxperf で実行し、キャッシュとTLBの統計を取得しました。

元の実装と比較すると、スイスバージョンでは全体的にキャッシュ参照が約60%少なくなります。最終レベルのキャッシュのロードは4倍以上減少し、LLCロードミスは6倍以上減少します。LLCのミスはメインメモリアクセスに直接変換されることが多いので、この減少だけでエンドツーエンドの改善の大部分を説明できます。

CPUに近いほどL1データキャッシュミスが少なくなり、データTLBミスが約6倍少なくなります。これは、空間的局所性が高く、メモリアクセスパターンがより予測可能であることを示しています。

これがSIMD対応の制御バイトの実用的なメリットです。散在したメモリ位置からキーと値を繰り返しロードする代わりに、ほとんどのプローブは、コンパクトなキャッシュ常駐構造をスキャンすることによって解決されます。アクセスされるメモリが少なければミスも減り、ミスが少なければクエリも速くなります。

まとめ

スイススタイルのハッシュテーブル設計を採用し、SIMDフレンドリーなプロービングを積極的に活用することで、高カーディナリティのES|QL統計ワークロードで2〜3倍の速度向上を達成し、より安定的で予測可能なパフォーマンスを実現しました。

この研究は、現代のCPUに対応したデータ構造が、ハッシュテーブルのような十分に確立された問題においても、大きな性能向上を実現できることを示しています。ここでは、追加のプリミティブ型の特殊化や、結合などの他の高カーディナリティパスでの使用など、さらに検討する余地がありますが、これらはすべて、Elasticsearchの内部を継続的に近代化するための広範かつ継続的な取り組みの一部に過ぎません。

詳細に興味がある方や作業をフォローしたい方は、GitHubのプルリクエストとメタイシューの進捗追跡をチェックしてみてください。

ハッシュを活用しましょう！

要約

まず、現状をお伝えしましょう。Elasticsearchは、強力なベクトルデータベースとして確立され、大規模な類似性検索に対して豊富な特徴と強力なパフォーマンスを提供しています。スカラー量子化、Better Binary Quantization（BBQ）、SIMDベクトル演算、DiskBBQのようなよりディスク効率の高いアルゴリズムなどの機能により、すでにベクトルワークロードの管理に効率的かつ柔軟な選択肢を提供しています。

NVIDIA cuVSをベクトル検索タスク用の呼び出し可能なモジュールとして統合することで、ベクトルインデキシングのパフォーマンスと効率を大幅に向上させ、大規模なベクトルワークロードをより良くサポートすることを目指しています。

課題

高性能ベクトルデータベースを構築する上で最も困難な課題の一つは、ベクトルインデックス（HNSWグラフ）を構築することです。インデックス構築は、すべてのベクトルが他の多数のベクトルと比較されるため、すぐに数百万、あるいは数十億の算術演算によって支配されるようになります。さらに、インデックスのライフサイクル操作、例えば圧縮やマージなどは、インデキシングの全体的な計算オーバーヘッドをさらに増加させる可能性があります。データ量と関連するベクトル埋め込みが指数関数的に増加するにつれ、大規模な並列処理と高スループットの数学演算用に構築された高速コンピューティングGPUは、これらのワークロードを処理するのに理想的な位置にあります。

Elasticsearch-GPUプラグインの登場

NVIDIA cuVSは、GPUによるベクトル検索とデータクラスタリングのためのオープンソースCUDA-Xライブラリであり、AIおよび推奨ワークロード向けの高速インデックス構築と埋め込み検索を可能にします。

ElasticsearchはcuVSをcuvs-javaを通じて使用しています。cuvs-javaはコミュニティが開発し、NVIDIAが保守するオープンソースライブラリです。cuvs-javaライブラリは軽量で、cuVS C APIをベースにPanama Foreign Functionを使用して、cuVSの特徴をJavaらしい方法で公開しつつ、モダンな高性能を維持しています。

cuvs-javaライブラリは新しいElasticsearchプラグインに統合されています。そのため、GPU上でのインデキシングを同じElasticsearchノードとプロセスで実行でき、外部のコードやハードウェアを提供する必要はありません。CUVsライブラリがインストールされていて、GPUが存在して構成されている場合、インデキシング中にElasticsearchはGPUを使用してベクターインデキシング処理を高速化します。ベクトルはGPUに提供され、GPUはCAGRAグラフを構築します。その後、このグラフはHNSW形式に変換され、CPU上でのベクトル検索にすぐに利用可能になります。構築されたグラフの最終的な形式は、CPU上に構築されるものと同じです。これによりElasticsearchは、基盤となるハードウェアがサポートしている場合、GPUを活用して高スループットのベクトルインデックスを作成し、CPUのパワーを他のタスク（同時検索やデータ処理など）に解放することができます。

インデックス構築の加速

ElasticsearchにGPUアクセラレーションを統合する一環として、cuvs-javaにいくつかの機能強化が行われ、効率的なデータのインプット/出力と関数呼び出しに焦点が当てられました。主要な機能強化は、cuVSMatrixを使用して、Javaヒープ、オフヒープ、またはGPUメモリに存在するベクトルを透過的にモデル化することです。これにより、データをメモリとGPU間で効率的に移動でき、潜在的に数十億のベクトルの不要なコピーを回避できます。

この基礎となるゼロコピー抽象化のおかげで、GPUメモリへの転送とグラフの取得の両方が直接実行できます。インデキシング中、ベクトルは最初にJavaヒープ上のメモリにバッファリングされ、その後GPUに送られてCagraグラフを構築します。その後、グラフはGPUから取得され、HNSW形式に変換され、ディスクに保存されます。

マージ時には、ベクトルはすでにディスクに格納されており、Javaヒープを完全にバイパスします。インデックスファイルはメモリマップされ、データは直接GPUメモリに転送されます。この設計は、float32やint8などのさまざまなビット幅にも簡単に対応し、他の量子化スキームにも自然に拡張できます。

実際のパフォーマンス

数字を見てみる前に、少し背景を説明しておきましょう。Elasticsearchのセグメントマージは通常、インデキシング中にバックグラウンドで自動的に実行されるため、分離してベンチマークをとることが難しくなります。再現可能な結果を得るために、制御された実験でforce-mergeを使用してセグメントのマージを明示的にトリガーしました。force-mergeはバックグラウンドマージと同じ基礎となるマージ操作を実行するので、実際のインデキシングワークロードでは正確な効果が異なる場合でも、そのパフォーマンスは期待される改善を示す有用な指標となります。

さて、数字を見てみましょう。

最初のベンチマーク結果は非常に有望です。ベンチマークは、ローカルに接続されたNVMeストレージを持つAWS g6.4xlargeインスタンスで実行しました。Elasticsearchのシングルノードは、デフォルトの最適なインデキシングスレッド数（各物理コアに1つずつの計8つ）を使用し、マージスロットリング（高速NVMeディスクではあまり適用されません）を無効にするように設定しました。

データセットにはOpenAI Rallyベクトルトラックから取得した1,536次元のベクトル260万個をbase64文字列としてエンコードし、float32 hnswとしてインデックスして使用しました。すべてのシナリオにおいて、構築されたグラフは最大95%のリコールレベルを達成します。結果は以下となりました。

• インデキシングのスループット：メモリ内バッファのフラッシュ中にグラフ構築を GPU に移動することで、スループットが約 12 倍向上します。

• 強制マージ：インデキシングが完了した後、GPUはセグメントのマージを加速し続け、強制マージフェーズを約7倍高速化します。

• CPU使用率：グラフ構築をGPUにオフロードすると、平均およびピーク時のCPU使用率が大幅に削減されます。以下のグラフは、インデキシングとマージ中のCPU使用率を示しており、これらの操作をGPUで実行すると使用率がどれだけ低くなるかを強調しています。GPUインデキシング中のCPU使用率が低下すると、CPUサイクルが解放され、検索パフォーマンスの向上に向けることができます。

• リコール：CPU実行とGPU実行の精度は実質的に同じですが、GPUで構築されたグラフのリコールはわずかに高くなります。

別の次元での比較：価格

先ほどの比較では、意図的に同一のハードウェアが使用されており、唯一の違いはインデキシング中にGPUが使用されたかどうかでした。この設定は、生のコンピューティング効果を分離するのに役立ちますが、コストの観点から比較することもできます。

GPUアクセラレーション構成とほぼ同じ時間単価で、同等のCPUおよびメモリリソースの約2倍（32個のvCPU（AMD EPYC）と64GBのRAM）を備えたCPUのみのセットアップをプロビジョニングでき、インデキシングスレッドの数を2倍の16に増やすことができます。

比較を公平かつ一貫性のあるものにするために、このCPUのみの実験をAWS g6.8xlargeインスタンスで実行しました。GPUは明示的に無効になっています。これにより、GPUアクセラレーションとCPUのみのインデキシングのコストパフォーマンスのトレードオフを評価する際、他のすべてのハードウェア特性を一定に保つことができました。

予想どおり、より強力なCPUインスタンスでは、上記のセクションのベンチマークと比較してパフォーマンスが向上しています。しかし、このより強力なCPUインスタンスを元のGPUアクセラレーション結果と比較すると、GPUは、リコールレベル最大95%に達するグラフを構築しながら最大5倍のインデキシングスループット向上、最大6倍のフォースマージと、依然として大幅なパフォーマンス向上を提供します。

結論

エンドツーエンドのシナリオでは、NVIDIA cuVSによるGPUアクセラレーションにより、インデキシングのスループットが約12倍向上し、force-mergeのレイテンシが7倍減少し、CPU使用率が大幅に低下します。これは、ベクトルインデキシングとマージワークロードがGPUアクセラレーションから大きな恩恵を受けることを示しています。コスト調整後の比較では、GPUアクセラレーションは引き続き大幅なパフォーマンス向上をもたらし、インデキシングのスループットは約5倍、force-merge操作は6倍高速化されます。

GPUアクセラレーションによるベクトルインデキシングは、現在Elasticsearch 9.3の技術プレビューで計画されており、2026年初頭にリリース予定です。

続報をお楽しみに。

効率を一切犠牲にしないという当社の使命の一環として、NVIDIA GPU という興味深いコンピューター チップを使った高速化の可能性を模索しています。このチップについて聞いたことがあるかもしれません (本当に聞いたことありませんか?)。

パフォーマンスを重視する場合、指数関数的に多くのデータをインデックスする方法、そこから洞察を取得する方法、ML モデルが関係する場合にそれを実行する方法など、検討すべき問題領域がいくつかあります。GPU があれば、利用可能なメリットをすべて引き出すことができるはずです。

この記事では、Elasticsearch での GPU アクセラレーションによるベクトル検索について探りながら、NVIDIA ベクトル検索チームとのコラボレーションについて詳しく説明します。この作業により、開発者が実際の Elasticsearch 搭載アプリで GPU と CPU を組み合わせて使用できるユースケースが実現します。楽しい時間です！

Elasticsearch GPU

Elasticsearch エンジニアリング チームが、ベクトル検索アルゴリズムのバインディングを公開する、開発者向けのオープンソース cuVS Java API エクスペリエンスの構築に協力していることをお知らせします。この作業は、パナマFFIでのこれまでの経験を活用しています。Elasticsearch と Apache Lucene は、インデックス作成中にグラフを構築するために NVIDIA cuVS API を使用します。さて、話が先に進んでしまいましたが、少し戻ってみましょう。

このコラボレーションの中心となるのは、オープンソースの C++ ライブラリであるNVIDIA cuVSです。より高いスループット、より低いレイテンシ、より速いインデックス構築時間を実現することで、ベクター検索に GPU アクセラレーションをもたらすことを目指しています。しかし、Elasticsearch と Apache Lucene は Java で書かれています。これはどのように動作するのでしょうか?

lucene-cuvsと Elastic-NVIDIA-SearchScale のコラボレーションを導入して、これを Lucene エコシステムに導入し、Elasticsearch での GPU アクセラレーションによるベクトル検索を探索します。最近の NVIDIA cuVS 25.02 リリースでは、cuVS 用の Java API が追加されました。新しい API は実験段階であり、今後も進化していきますが、現在は使用可能です。「Java からネイティブ関数の呼び出しは遅いのではないだろうか?」という疑問が生じるかもしれません。もうない！バインディングには新しいPanama FFI (Foreign Function Interface) を使用しており、Java からネイティブ ダウンコールへのオーバーヘッドが最小限に抑えられています。

私たちはしばらくの間、Elasticsearch と Lucene で Panama FFIを使用してきました。すごいですね！でも…いつも「でも」ってあるじゃないですか。FFI には、Java バージョン間での可用性に関する課題があります。私たちは、cuVS API を Java 21 にコンパイルし、その実装を Java 22 をターゲットとしたマルチリリース jar 内にカプセル化することで、この問題を解決しました。これにより、cuVS Java を Lucene および Elasticsearch で直接使用できるようになります。

さて、cuVS Java API が手に入ったので、他に何が必要でしょうか?

CPUの2つのアルゴリズムの物語

Elasticsearch は、スケーラブルな近似 KNN 検索のためのHNSW アルゴリズムをサポートしています。ただし、GPU を最大限に活用するために、GPU が提供する高度な並列処理向けに特別に設計された別のアルゴリズム、 CAGRA [ C UDA A NN GRA ph ]を使用します。

CAGRA のサポートを追加する方法に入る前に、Elasticsearch と Lucene が「コーデック形式」を通じてインデックス データにアクセスする方法を見てみましょう。これは、

1. ディスク上の表現、

2. データの読み書きのためのインターフェース

3. Lucene のセグメントベースのアーキテクチャを処理するための仕組み。

私たちは、cuVS Java API を内部的に使用して GPU 上でインデックス作成と検索を行う新しい KNN (k 近傍法)ベクトル形式を実装しています。ここから、Elasticsearch のマッピングを通じてこのコーデック タイプをインデックス内のフィールド タイプに「plumb」します。その結果、バックアップ インデックスが CAGRA グラフを使用しているか、HNSW グラフを使用しているかに関係なく、既存の KNN クエリは引き続き機能します。もちろん、ここでは多くの詳細について触れていませんが、それについては今後のブログで取り上げる予定です。以下は、GPU アクセラレーション Elasticsearch の高レベルアーキテクチャです。

この新しいコーデック形式のデフォルトは CAGRA です。ただし、CPU 上での検索のために CAGRA グラフを HNSW グラフに変換することもサポートされています。

GPUでのインデックス作成と検索：いくつかの「コア」な決定を下す

Elasticsearch Serverless のステートレスアーキテクチャではインデックス作成と検索が分離されており、責任の区分が明確になっています。私たちは、これらの独立した責任をそれぞれ果たすために最適なハードウェア プロファイルを選択します。

ユーザーは主に次の 2 つの展開戦略を検討すると予想されます。

1. GPU でのインデックス作成と検索: インデックス作成中に CAGRA グラフを構築し、検索中に使用します。これは、非常に低遅延の検索が必要な場合に最適です。

2. GPU でインデックスを作成し、CPU で検索する: インデックス作成中に、CAGRA グラフを構築し、それを HNSW グラフに変換します。HNSW グラフはインデックスに保存され、後で CPU で検索に使用できます。

この柔軟性により、さまざまな展開モデルが提供され、コストとパフォーマンスのトレードオフが可能になります。たとえば、インデックス作成サービスでは、検索には低電力の CPU を使用しながら、GPU を使用してグラフをタイムリーに効率的に構築およびマージできます。

ElasticsearchにおけるGPUアクセラレーションによるベクトル検索の計画は以下のとおりです。

私たちは、コストとパフォーマンスのバランスをとるためのさまざまなノブを提供し、パフォーマンスの向上と展開戦略の柔軟性をユーザーに提供することを楽しみにしています。この作業が詳しく発表されたNVIDIA GTC 2025 セッションはこちらです。

素晴らしいコラボレーションを実現してくれた NVIDIA と SearchScale のエンジニアリング チームに感謝します。今後のブログでは、実装の詳細とパフォーマンス分析をさらに詳しく検討します。好奇心の帽子をしっかり握ってください🎩!

Luceneとコミュニティ

プロジェクトの強さは、それをサポートするコミュニティの強さによって決まります。20 年以上の開発期間を経ても、Lucene プロジェクトは、熱心で活動的な貢献者のおかげで、活気に満ち、成長し続けています。

2024 年、Lucene プロジェクトでは 98 人の貢献者から 2,000 件を超えるコミットと、約 800 件のプル リクエストが行われました。新しいコミッターや PMC メンバーがプロジェクトに参加し、プロジェクトの成功に貢献しているため、貢献者の数は増え続けています。

ルーシーン10

2024 年には、ほぼ 3 年ぶりのメジャー リリースである Lucene 10 がリリースされ、185 人の貢献者から 2,000 件を超えるコミットが行われました。Lucene が採用している開発モデルでは、マイナー リリースで多くの改善や機能を提供できますが、メジャー リリースではより大きな機能や最新化を導入する機会が与えられます。たとえば、Lucene 10 には少なくとも Java 21 が必要です。最小 Java バージョンを上げると、Lucene は最新の Java が提供する改善点を引き続き活用できるようになります。

Lucene 10 の主な焦点は、それが実行されるハードウェアをより有効に活用することです。主なハイライトのいくつかを簡単に見てみましょう。

• 検索の並列化の強化- 検索実行は既にセグメント間で並列化されていますが、セグメント内での並列化がさらに進みました。これにより、ディスク上の表現と実行パフォーマンスが分離され、単一のセグメントでも最新システムのコア数のメリットを享受できるようになります。

• より優れた I/O 並列処理- Lucene が使用する単純な同期 I/O モデルが、プリフェッチ ステージによって強化されました。これにより、呼び出しスレッドをブロックせずに、インデックス ファイルの領域が近い将来必要になることを OS に通知します。

• スパース インデックスによる CPU とストレージの効率向上- Lucene 10 では、スパース インデックス (他のデータ ストアでは主キー インデックスまたはゾーン インデックスと呼ばれることもあります) のサポートが導入されています。

Lucene 10 の詳細については、Lucene 10 に関する専用記事をご覧ください。

ルーシーンの研究と革新

2024 年、Lucene では、特に機械学習の統合、ベクトル検索、大規模データセットの最適化の分野で研究とイノベーションが急増し、10 件の個別の研究論文と出版物が参照されています。主要な研究分野と開発には次のようなものがあります。

• ベクター検索と埋め込みのサポート- Lucene は、ベクターベースの検索のための強力でスケーラブルなソリューションを提供し、大規模なセマンティック検索を可能にします。Lucene の堅牢なインデックス作成および検索インフラストラクチャを活用することで、ユーザーは従来のテキスト検索の長所と最新のベクター検索の高度な機能を組み合わせることができ、Lucene は幅広い検索および情報取得タスクに対応する包括的なソリューションになります。

• ハイブリッド検索モデル- 研究では、従来のキーワードベースの検索と最新のベクターベースの検索を組み合わせた、ハイブリッド検索技術についても詳しく調べられています。Lucene は、用語ベースのインデックスと高密度のベクトル表現を統合することで、従来の検索エンジンの精度とセマンティック検索の柔軟性の間のギャップを埋め、より正確で文脈的に関連性の高い検索結果を提供できます。

2024 年に進行中の研究活動は、特に AI、セマンティック検索、ビッグデータ アプリケーションの分野における、最新の検索テクノロジーの進化するニーズに対する Lucene の適応性を実証しています。このプロジェクトは、従来の検索ユースケースと最先端の検索ユースケースの両方に対応する強力で柔軟性が高く効率的なプラットフォームとして成長を続けています。

2024年のLuceneリリース

正確な反映ではありませんが、リリースの膨大な量は、コミュニティの継続的な献身とエネルギーを浮き彫りにしています。これらのアップデートには、ベクトル検索のパフォーマンスと効率の大幅な強化、madvise のサポート、ポスティング リストのデコードの最適化、SIMD によるさらなる速度向上などが含まれています。

リリースの全リストは次のとおりです。

• 10.1.0（2024年12月20日）

• 9.12.1 (2024年12月13日)

• 10.0.0 (2024年10月14日)

• 9.12.0 (2024年9月28日)

• 8.11.4 (2024年9月24日)

• 9.11.1 (2024-06-27)

• 9.11.0 (2024-06-06)

• 9.10.0（2024年2月20日）

• 8.11.3 (2024年2月8日)

• 9.9.2 (2024年1月29日)

詳細情報とリリース ノートについては、 Lucene Coreページをご覧ください。さらに、同等のPyLuceneリリースもあります。

まとめ

Lucene は成熟するにつれ、熱心で活気のあるコミュニティのおかげで繁栄し続けています。これまで見てきたように、2024 年は信じられないほど生産性の高い年であり、私たちは 2025 年にもたらされる刺激的な発展に期待を寄せています。