ANNリソース推定ガイド
ANNワークロードは通常、ストレージよりもメモリとCPUによって制約されます。本ガイドでは、起動前にクラスタサイジングを見積もる実践的な方法を提供します。
この方法は、ベクターデータベースで一般的に使用されるパターンと同じです：
- まずインデックスメモリを見積もります。
- 目標クエリパフォーマンスに基づいてCPUコア数を見積もります。
- ベクター以外のカラムと実行オーバーヘッド用のメモリ余裕を確保します。
ANNで明示的なキャパシティプランニングが必要な理由
通常のOLAPインデックスと比較して、ANNには以下の特有のリソース特性があります：
- インデックス構築はCPU集約的です。
- 非常に大きなセグメントはインデックス構築の失敗を引き起こす可能性があります（例：単一インデックス構築中のメモリ不足）。
- 高性能クエリでは通常、インデックスがメモリに常駐している必要があります。
- 高QPSクエリでは、距離計算とマージオーバーヘッドを維持するのに十分なCPUコア数が必要です。
メモリ使用量を削減するため、Dorisはベクター量子化（sq8、sq4、pq）をサポートしています。量子化はメモリを節約しますが、トレードオフをもたらす場合があります：
- インポートの低速化（追加エンコーディング）
- クエリの低速化（追加デコード/再構築）
- 量子化が非可逆であるため、再現率の低下
ステップバイステップの見積もり
以下の入力を準備してください：
- ベクター次元
D - 総行数
N - インデックスタイプ（
hnsw、ivf、またはivf_on_disk） - 量子化器（
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
量子化器ベースの近似：
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
量子化器ベースの近似：
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見積もり
高QPSANN検索の場合、実用的なベースライン比率は：
16コア：64 GBメモリ（約 1コア：4 GB）
量子化を使用する場合、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%以下に保つ - 残りのメモリをクエリ実行、コンパクション、非ベクターデータアクセス用に確保する
シナリオ別のサイジング推奨事項
- 最高性能、メモリが問題でない場合：
HNSW + FLAT - メモリ制約のあるデプロイメント：
HNSW/IVF + PQ（SQ8/SQ4よりも実用的なバランスが良いことが多い） - PQパラメータ化では、
pq_m = D / 2から開始し、リコールと遅延の目標に応じて調整する - クエリ性能要件が中程度の場合は、CPUコア数の削減を優先する。一部のデプロイメントでは、インポート/ビルド時により多くのCPUをプロビジョニングし、その後CPUをスケールダウンできる