Le niveau de performances optimisé pour le stockage de Vector Search est conçu pour indexer et rechercher des ensembles de données volumineux. Ce niveau implémente une architecture basée sur le disque au lieu d'utiliser la RAM, ce qui réduit considérablement vos coûts opérationnels. Si votre priorité est la rentabilité à grande échelle plutôt que la latence de requête la plus faible possible, le niveau optimisé pour le stockage est le meilleur choix.
Quand utiliser un index optimisé pour le stockage ?
Envisagez d'utiliser des index optimisés pour le stockage si vous vous trouvez dans l'une des situations suivantes :
Ensemble de données très volumineux : vous devez indexer un très grand nombre de vecteurs, et le coût d'hébergement d'un grand nombre de shards optimisés pour les performances est prohibitif.
Charge de RPS à faible QPS : dans les applications à faible volume de requêtes, les économies réalisées en utilisant moins de shards peuvent être importantes.
Exigences de latence flexibles : votre application peut tolérer une légère augmentation de la latence des requêtes, c'est-à-dire le temps nécessaire pour obtenir un résultat de recherche.
Compromis en termes de performances
Par rapport à l'index par défaut optimisé pour les performances, un index optimisé pour le stockage présente les caractéristiques suivantes :
- Latence de requête accrue : les requêtes ont une latence légèrement plus élevée à un niveau de rappel donné.
Configurer un index optimisé pour le stockage
Pour créer un index optimisé pour le stockage, définissez le paramètre shardSize sur SHARD_SIZE_SO_DYNAMIC dans la configuration de votre index.
Exemple : Créer un index optimisé pour le stockage
L'exemple suivant montre le code JSON requis pour créer un index de flux optimisé pour le stockage.
{
"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"
}
Dans l'exemple, shardSize est défini sur SHARD_SIZE_SO_DYNAMIC, ce qui indique à Vector Search de créer un index plus dense. Cela permet à chaque partition de contenir beaucoup plus de points de données, ce qui réduit le nombre total de partitions nécessaires pour votre ensemble de données. Les autres champs, tels que dimensions et distanceMeasureType, sont configurés en fonction de vos besoins.
Points de terminaison
Les déploiements optimisés pour le stockage peuvent être utilisés avec n'importe quel point de terminaison existant.
Déployer un index
L'exemple suivant montre le code JSON requis pour déployer un index optimisé pour le stockage sur un point de terminaison que vous avez créé.
{
"deployedIndex": {
"id": "PROJECT_UNIQUE_ID_NAME",
"index": "projects/PROJECT_ID/locations/LOCATION/indexes/INDEX_ID",
"displayName": "INDEX_DISPLAY_NAME",
"deploymentTier": "STORAGE"
}
}
Définir deploymentTier sur STORAGE déploie l'index optimisé pour le stockage avec le displayName spécifié sur un point de terminaison.
Vous pouvez également spécifier le nombre minimal (minReplicaCount) et le nombre maximal (minReplicaCount) de réplicas pour contrôler le nombre de réplicas de machine à déployer. La définition du type de machine (machineType) n'est pas prise en charge.