ANNリソース推定ガイド
ANNワークロードは通常、生のストレージではなくメモリとCPUによって制約されます。このガイドでは、起動前にクラスタサイジングを見積もる実用的な方法を提供します。
この方法は、ベクターデータベースで一般的に使用されるのと同じパターンに従います：
- まずインデックスメモリを見積もります。
- 目標クエリパフォーマンスに基づいてCPUコア数を見積もります。
- 非ベクターカラムと実行オーバーヘッド用にメモリヘッドルームを確保します。
ANNが明示的なキャパシティプランニングを必要とする理由
通常のOLAPインデックスと比較して、ANNにはいくつかの特定のリソース特性があります：
- インデックス構築はCPU集約的です。
- 非常に大きなセグメントはインデックス構築の失敗を引き起こす可能性があります（例：単一インデックス構築中のメモリ不足）。
- 高性能クエリでは通常、インデックスがメモリに常駐している必要があります。
- 高QPSクエリでは、距離計算とマージオーバーヘッドを維持するために十分なCPUコアが必要です。
メモリ使用量を削減するために、DorisはベクトルQuantization（sq8、sq4、pq）をサポートしています。Quantizationはメモリを節約しますが、トレードオフをもたらす場合があります：
- より遅いインポート（追加エンコーディング）
- 時折遅いクエリ（追加デコード/再構築）
- quantizationは非可逆的であるためリコールが低下
ステップバイステップ見積もり
以下の入力を準備してください：
- ベクトル次元
D - 総行数
N - インデックスタイプ（
hnsw、ivf、またはivf_on_disk） - Quantizer（
flat、sq8、sq4、pq） - HNSWパラメータ
max_degree（HNSWを使用する場合） - 目標QPSと遅延目標
その後、この順序で見積もります：
- インデックスメモリ
- CPUコア数
- 安全ヘッドルーム
HNSWメモリ見積もり
デフォルトのmax_degree=32のHNSWの場合、実用的なメモリは：
HNSW_FLAT_Bytes ~= 1.3 * D * 4 * N
ここで：
D * 4 * Nは生のfloat32ベクトルメモリ1.3はHNSWグラフオーバーヘッドを含む
max_degreeが増加した場合、グラフオーバーヘッドを比例的にスケールします：
HNSW_factor ~= 1 + 0.3 * (max_degree / 32)
HNSW_FLAT_Bytes ~= HNSW_factor * D * 4 * N
Quantizerベースの近似：
sq8：flatの約1/4sq4：flatの約1/8pq：通常メモリではsq4に近い（例：pq_m=D/2, pq_nbits=8）
クイックリファレンス（D=768、max_degree=32）
| 行数 | FLAT | SQ8 | SQ4 | PQ（m=384, nbits=8） |
|---|---|---|---|---|
| 1M | 4 GB | 1 GB | 0.5 GB | 0.5 GB |
| 10M | 40 GB | 10 GB | 5 GB | 5 GB |
| 100M | 400 GB | 100 GB | 50 GB | 50 GB |
| 1B | 4000 GB | 1000 GB | 500 GB | 500 GB |
| 10B | 40000 GB | 10000 GB | 5000 GB | 5000 GB |
IVFメモリ見積もり
IVFはHNSWよりも構造的オーバーヘッドが低くなります。実用的な近似は：
IVF_FLAT_Bytes ~= D * 4 * N
Quantizerベースの近似：
sq8：flatの約1/4sq4：flatの約1/8pq：通常sq4に近い
ivf_on_diskは同じIVFトレーニングモデル（nlist / ivf_nprobe）を使用しますが、IVFリストペイロードをディスクに保存し、キャッシュを通じて提供します。プランニングでは、完全なインメモリ常駐の上限として上記のIVF見積もりを使用し、ホットリストデータ用に確保したいメモリ予算に基づいてann_index_ivf_list_cache_limitをサイジングできます。
クイックリファレンス（D=768）
| 行数 | FLAT | SQ8 | SQ4 | PQ（m=384, nbits=8） |
|---|---|---|---|---|
| 1M | 3 GB | 0.75 GB | 0.35 GB | 0.35 GB |
| 10M | 30 GB | 7.5 GB | 3.5 GB | 3.5 GB |
| 100M | 300 GB | 75 GB | 35 GB | 35 GB |
| 1B | 3000 GB | 750 GB | 350 GB | 350 GB |
| 10B | 30000 GB | 7500 GB | 3500 GB | 3500 GB |
CPU見積もり
高QPS ANN検索の場合、実用的なベースライン比率は：
16コア : 64 GBメモリ（約1コア : 4 GB）
quantizationを使用する場合、CPU需要は必ずしもインデックスメモリに比例して縮小するとは限りません。実際には、FLAT-メモリ相当ワークロードからCPUを見積もり、ベンチマーク検証後にのみ調整することをお勧めします。
実クエリヘッドルーム（100%にサイジングしない）
上記の式はANNインデックスメモリのみを見積もります。実際のSQLはしばしば追加カラムを返します。例えば：
SELECT id, text, l2_distance_approximate(embedding, [...]) AS dist
FROM tbl
ORDER BY dist
LIMIT N;
TopN遅延実体化を使用しても、実行には他の演算子と列のためのメモリが依然として必要です。本番環境でのリスクを軽減するために：
- ANNインデックスメモリをマシンメモリの約
70%未満に保つ - 残りのメモリをクエリ実行、compaction、非ベクターデータアクセス用に確保する
シナリオ別サイジング推奨事項
- 最高のパフォーマンス、メモリが問題でない場合：
HNSW + FLAT - メモリ制約のあるデプロイメント：
HNSW/IVF + PQ（SQ8/SQ4よりも実用的なバランスが優れていることが多い） - PQパラメータ化については、
pq_m = D / 2から開始し、recallとレイテンシの目標に応じて調整する - クエリパフォーマンス要件が中程度の場合は、CPUコア数の削減を優先する。一部のデプロイメントでは、インポート/ビルド時により高いCPUをプロビジョニングし、その後CPUをスケールダウンできる