ベクトル検索のストレージ最適化パフォーマンス ティアは、大規模なデータセットのインデックス登録と検索用に設計されています。このティアでは、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 を使用してストレージ最適化インデックスがエンドポイントにデプロイされます。
最小レプリカ数（minReplicaCount）と最大レプリカ数（minReplicaCount）を指定して、デプロイ対象のマシンレプリカの数を制御することもできます。マシンタイプ（machineType）の設定はサポートされていません。