ベクトル検索のストレージ最適化パフォーマンス ティアは、大規模なデータセットのインデックス登録と検索用に設計されています。この階層では、RAM ではなくディスクベースのアーキテクチャが実装されているため、運用コストが大幅に削減されます。クエリ レイテンシを最小限に抑えることよりも、大規模な費用対効果を重視する場合は、ストレージ最適化ティアが最適です。
ストレージ最適化インデックスを使用する場合
次のいずれかに該当する場合は、ストレージ最適化インデックスを検討してください。
非常に大きなデータセット: 非常に多くのベクトルをインデックス登録する必要があり、パフォーマンスが最適化された多数のシャードをホストするコストが非常に高くなります。
QPS の低いワークロード: クエリ量の少ないアプリケーションでは、シャード数を減らすことで大幅なコスト削減を実現できます。
柔軟なレイテンシ要件: アプリケーションで、検索結果を取得するのにかかる時間であるクエリ レイテンシのわずかな増加を許容できます。
パフォーマンスのトレードオフ
デフォルトのパフォーマンス最適化インデックスと比較して、ストレージ最適化インデックスには次の特性があります。
- クエリのレイテンシの増加: 特定の再現率レベルでクエリのレイテンシが若干高くなります。
ストレージ最適化インデックスを構成する方法
ストレージ最適化されたインデックスを作成するには、インデックス構成で shardSize パラメータを SHARD_SIZE_SO_DYNAMIC に設定します。
例: ストレージ最適化インデックスを作成する
次の例は、新しいストレージ最適化ストリーミング インデックスの作成に必要な JSON を示しています。
{
"displayName": "my-storage-optimized-index",
"description": "An index configured to prioritize storage over performance.",
"metadata": {
"contentsDeltaUri": "gs://your-bucket/source-data/",
"config": {
"dimensions": 100,
"approximateNeighborsCount": 150,
"distanceMeasureType": "DOT_PRODUCT_DISTANCE",
"shardSize": "SHARD_SIZE_SO_DYNAMIC"
}
},
"indexUpdateMethod": "STREAM_UPDATE"
}
この例では、shardSize が SHARD_SIZE_SO_DYNAMIC に設定されています。これにより、ベクトル検索はより密度の高いインデックスを構築します。これにより、各シャードで保持できるデータポイントの数が大幅に増え、データセットに必要なシャードの総数が削減されます。dimensions や distanceMeasureType などの他のフィールドは、必要に応じて構成します。
エンドポイント
ストレージ最適化デプロイは、既存のエンドポイントで使用できます。
インデックスのデプロイ
次の例は、作成したエンドポイントにストレージ最適化インデックスをデプロイするために必要な JSON を示しています。
{
"deployedIndex": {
"id": "PROJECT_UNIQUE_ID_NAME",
"index": "projects/PROJECT_ID/locations/LOCATION/indexes/INDEX_ID",
"displayName": "INDEX_DISPLAY_NAME",
"deploymentTier": "STORAGE"
}
}
deploymentTier を STORAGE に設定すると、指定された displayName を使用してストレージ最適化インデックスがエンドポイントにデプロイされます。ベクトル検索では、最適なパフォーマンスを得るために適切なマシンタイプが動的に選択されます。