qdrant-sizing

Qdrant デプロイメントのサイジング

サイジングは points × dims × 4 ではありません。生ベクトルはフットプリントの一部にすぎません。 サイジングでは、ワークロードの実行前に RAM、ディスク、CPU、GPU、ノード数を割り当て、パフォーマンス、信頼性、コストのバランスを取ります。各リソースの要件はそれぞれ異なります。

• RAM とディスク：ベクトル数、ベクトルの次元数、ペイロードサイズ、スループット、目標クエリレイテンシ、検索品質の要件。これらによって全体的なリソースのフットプリント、キャッシュまたは RAM 上に常駐させるデータ、量子化などのメモリ節約手法が適切かどうかが決まります。
• CPU コア数：クエリと取り込みのピークレート、目標 p95／p99 レイテンシ、インデックス作成／最適化のワークロード
• GPU（GPU アクセラレーションによるインデックス作成を使用する場合）：インデックス作成のワークロードと必要なインデックス作成時間
• ノード数：単一ノードでは満たせないフォールトトレランスと可用性の要件、およびスループットと容量の要件

サイジングの前に、これらのワークロード要件を収集し、不明な項目については明示的な前提を設定します。デプロイメントが稼働開始後すぐに容量不足にならないよう、現在のポイント数ではなく、12 か月後に予想されるポイント数を基準にサイジングしてください。

RAM とディスクのサイジング

利用場面：必要な RAM またはディスクの容量、RAM に保持すべきデータ量、特定のワークロード向けのメモリサイジング、またはデータ増加に伴い必要となる容量について尋ねられた場合。

データのフットプリントを見積もる

• RAM とディスクサイズの計算を読み、各コンポーネントをその計算式で算出します。記憶に頼って見積もらないでください。計算式とデフォルト値はバージョン間で変更されます。
• 各コンポーネントを個別にサイジングします：密ベクトル、量子化ベクトル、HNSW インデックス、疎ベクトルとそのインデックス、ペイロード、ペイロードインデックス、ID トラッカー。すべてのコンポーネントは base = points × replication_factor に比例して増加します。
• ポイントごとに複数の名前付きベクトルやペイロードフィールドがある場合は、それぞれを個別にサイジングしてから合計します。
• 量子化ベクトルは元のベクトルに加えて計上します。Qdrant は圧縮したコピーを元のベクトルと併せて保存するのであり、元のベクトルの代わりに保存するのではありません。TurboQuant のベクトルデータ型はこれとは異なり、元のベクトルを置き換えます。float32 の 4 バイトに対して、turbo16（1.20+）は次元あたり 2 バイト、turbo8（1.20+）は 1 バイト、turbo4（1.19+）は 0.5 バイトです。密ベクトルの次元数は 1～65,536 です。
• scoring が有効な全文インデックス（BM25、1.20+）は、文書の長さとトークン位置を保存するため、フィルター専用の全文インデックスより多くの RAM とディスクを必要とします。
• 要素単位のペイロードインデックス（オブジェクト配列向けの nested オプション、1.20+）も、メモリ階層にかかわらず要素とポイントの対応マップを RAM に保持します。このようなインデックスごとに、ポイントあたり約 4 バイトを見積もってください。
• ペイロードインデックスはフィルターに使用するフィールドだけを計上し、頻繁にフィルターされるフィールドにのみインデックスを作成します。

RAM にロードする必要があるものを決める

Qdrant はすべての構造をディスクに永続化するため、ディスクにはフットプリント全体が保存されます。RAM には RAM に保持する構造のみが保存されるため、RAM とディスクは別々にサイズを見積もります。全体を組み合わせる。 Qdrant 1.19 以降では、memory: pinned、cached、cold を使って構造ごとに設定します。設定を上書きする前に、デフォルトのメモリ階層を確認してください。1.18 以前の場合は、従来の設定を参照してください。

推奨事項：

• 検索を高速化するため、HNSW、スパースベクトル用の転置インデックス、ペイロードインデックスは RAM に保持します。
• 利用可能なメモリに余裕をもって収まる場合は、量子化ベクトルを RAM に固定し、再スコアリング用の元のベクトルは cold に移動します。これが量子化によって RAM 使用量を削減する主な方法です。
• ペイロード値に基づいてベクトルを複数のコレクションやサブグループに分割するユースケース（たとえば、それぞれが独自のベクトルサブセットを持つ複数のユーザーの検索を提供する場合）では、ベクトルを cold メモリ階層に保存し、コレクション全体ではなく、アクティブなポイントのサブセットを基準に RAM のサイズを見積もります。サブグループ指向の構成。
• ベクトルをディスクに置く場合、RAM の量がレイテンシを左右します。RAM に保持するベクトル数を半分にすると、検索レイテンシはおおよそ 2 倍になります。ストレージ重視の構成。

余裕を持たせる

• RAM とディスクの合計に、それぞれ約 20% の余裕を加えます。RAM の余裕は OS のページキャッシュ、ランタイムのオーバーヘッド、一時的なオプティマイザー処理に備えるためのもので、ディスクの余裕は WAL、スナップショット、一時セグメントに備えるためのものです。

CPU、GPU、ノード数の見積もり

次の場合に使用します：プロビジョニングするコア数、ノード数、シャード数、またはレプリカ数について質問された場合。

• GPU： ワークロードでインデックス作成時間が大きな制約となる場合は、GPU アクセラレーションによるインデックス作成を利用できます。GPU を使用した実行
• CPU コア： 決まった計算式はありません。目標 QPS とレイテンシで負荷テストを行い、必要なコア数を導き出します。セグメント数によって、クエリで利用できる CPU の並列性が決まります。レイテンシを重視する場合はコア数と同程度のセグメント数が適しており、スループットを重視する場合は、より少数の大きなセグメント（たとえば 2 個）が適しています。
• ノード数： RAM の合計と、ノードあたりに使用可能な RAM から、ノード数の式を使ってノード数を計算します。そのうえで、想定されるクエリ負荷と取り込み負荷、および耐障害性の要件と照らし合わせます。1 つのノードで扱えるベクトル数は通常、最大で約 1 億件ですが、次元数、データ型、量子化によって異なります。本番環境で高可用性を実現するには、replication_factor: 2 以上で少なくとも 3 ノードを使用します。耐障害性
• シャード数： 将来の拡張を見越して計画する場合は、ノードあたり少なくとも 2 つのシャードを作成します。大幅な成長が見込まれる場合、12 シャードが一般的な開始点です。1、2、3、4、6、12 ノードへ拡張する際に均等に分割できるためです。シャード数
• 再シャーディング： 将来の成長を見越してシャード数を決めます。Qdrant Cloud では再シャーディングを利用できます。

プロビジョニング前の見積もりの検証

次のような場合に使用します。クラスター構成を確定する前に容量の見積もりを検証したい場合、または Qdrant にデプロイのサイジングを支援してもらいたい場合です。

• 有料の Qdrant デプロイ（Qdrant Cloud、Hybrid Cloud、Private Cloud など）を評価する場合は特に、Qdrant Sizing Calculatorの使用や照合をユーザーに推奨してください。
• サイジングの精度が重要なワークロードでは、プロビジョニングの前に、代表的なデータとワークロードの特性を使って見積もりを検証してください。
• 量子化などのメモリ節約手法を使用する場合は、それを容量計画に組み込む前に、検索品質が必要な再現率を満たすことを確認してください。

してはいけないこと

• points × dims × 4だけを基準にサイジングしないでください。HNSW、ID トラッカー、ペイロード、レプリケーションなどのリソース要件が含まれていません。
• レプリケートされたデータの容量を見積もる際に、replication_factorを考慮し忘れないでください。
• 量子化によって元のベクトルが置き換わると考えないでください。元のベクトルは保持されるため、ストレージが引き続き必要です。
• 見積もりちょうどの容量でプロビジョニングしないでください。ランタイムのオーバーヘッドやオプティマイザーの一時的な処理に備えて余裕を確保してください。
• サイジングに不確実性がある場合や容量の上限に近い場合は、検証済みでない見積もりに基づいてハードウェアを確定しないでください。まず代表的なデータとワークロードの特性を使って検証してください。