Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Surveillance de la capacité de l'indice vectoriel
Pour surveiller la consommation de capacité pour les opérations d'index vectoriel, définissez le ReturnConsumedCapacity paramètre sur INDEXES ou TOTAL dans vos SearchVectors requêtes, ou INDEXES dans vos requêtes d'API d'écriture.
Les opérations d'index vectoriel sont mesurées en deux unités, distinctes des unités de capacité de lecture et d'écriture utilisées par la table de base :
-
Recherche vectorielle (VS) : unité qui mesure les
SearchVectorsopérations. La consommation de VS est rapportéeVectorSearchRequestByteset évolue en fonction de la taille des données vectorielles examinées et renvoyées par la recherche. -
Écriture vectorielle (VWR) : unité qui mesure les écritures répliquées dans un index vectoriel. La consommation VWR est déclarée
VectorWriteRequestByteset évolue en fonction de la taille des données répliquées dans l'indice.
L'exemple suivant montre le résultat ConsumedCapacity renvoyé par une SearchVectors requête.
{ "ConsumedCapacity": { "VectorSearchRequestBytes": 41714.0 } }
Pour les opérations d'écriture (PutItemUpdateItem,DeleteItem,BatchWriteItem,TransactWriteItems), la réponse inclut une VectorIndexes carte dansConsumedCapacity, saisie par nom d'index. Chaque entrée indique VectorWriteRequestBytes la capacité consommée lors de la réplication des modifications apportées à chaque indice vectoriel.
{ "ConsumedCapacity": { "TableName": "Products", "CapacityUnits": 5.0, "Table": { "CapacityUnits": 5.0 }, "VectorIndexes": { "ProductEmbeddingIndex": { "VectorWriteRequestBytes": 4125.0 } } } }
La capacité d'index vectoriel est mesurée en octets traités, déclarés séparément de la capacité de lecture et d'écriture de la table de base. Utilisez ces champs pour comprendre ce qui détermine le coût de votre indice vectoriel :
-
Le coût de recherche (
VectorSearchRequestBytes) varie principalement en fonction de la taille des vecteurs que la recherche doit examiner, qui augmente en fonction du nombre de dimensions de l'index et de la quantité de données renvoyées. Limiter la recherche à une seule valeur de clé de partition réduit la quantité de données examinées. Le renvoi de l'attribut vectoriel dans les résultats augmente encore les coûts car la réponse inclut les données vectorielles complètes. Le coût de recherche n'augmente pas proportionnellement au nombre d'éléments de l'index. Si le nombre de dimensions, laTopKvaleur et la projection restent les mêmes, les données examinées par une recherche augmentent de façon logarithmique à mesure que vous ajoutez des éléments. Cela se produit parce qu'une recherche approximative du voisin le plus proche parcourt un petit sous-ensemble de l'index au lieu de lire chaque vecteur. Le fait de doubler le nombre d'éléments d'un index ajoute une petite quantité constante aux données examinées par chaque recherche. -
Le coût d'écriture (
VectorWriteRequestBytes) est encouru chaque fois que vous écrivez, mettez à jour ou supprimez un élément qui modifie un attribut indexé par vecteur et évolue en fonction de la taille des données répliquées dans l'index. Les écritures qui ne modifient pas un attribut indexé n'entraînent pas de capacité d'écriture vectorielle.
Higher-dimensional les intégrations augmentent à la fois les coûts de recherche et d'écriture car chaque vecteur contient plus de données. Pour connaître les tarifs actuels, consultez la tarification d'Amazon DynamoDB
DynamoDB publie également la capacité de l'indice vectoriel en CloudWatch tant que VectorWriteRequestBytes métrique VectorSearchRequestBytes et, dimensionnée par et. TableName VectorIndexName Utilisez ces mesures pour créer un graphique et émettre une alarme sur l'utilisation de l'indice vectoriel au fil du temps. Pour les définitions des métriques, reportez-vous VectorSearchRequestBytes aux sections etVectorWriteRequestBytes.
Per-request minimum de comptage
DynamoDB mesure la capacité de l'index vectoriel à un minimum de 1 Ko par demande et facture par octet au-dessus de ce minimum. Cela s'applique aux deux types de demandes. Une SearchVectors demande qui examine moins de 1 Ko de données vectorielles est mesurée à 1 Ko. Une demande d'écriture qui réplique moins de 1 Ko dans les index vectoriels d'une table est également mesurée à 1 Ko.
Le minimum s'applique par demande et non par index. Une écriture qui met à jour des vecteurs dans plusieurs index vectoriels d'une table n'entraîne pas un minimum de 1 Ko distinct pour chacun d'eux, même si les ConsumedCapacity rapports sont publiés VectorWriteRequestBytes par index.
Par conséquent, les vecteurs de faible dimension n'ont pas un compteur proportionnellement inférieur. Un vecteur comportant un petit nombre de dimensions ne contient que quelques octets de données à virgule flottante 32 bits et est toujours mesuré au minimum de 1 Ko.
Au-delà du minimum, VectorSearchRequestBytes reflète les données vectorielles examinées par la recherche dans l'index, et non la taille du vecteur de requête que vous fournissez. Par conséquent, VectorSearchRequestBytes il est plus grand que le vecteur de requête seul.
Le coût de recherche augmente de façon logarithmique, comme expliqué précédemment, mais cette relation ne constitue pas une formule pour estimer votre facture. VectorSearchRequestBytesinclut également les données renvoyées par la recherche. Ces données évoluent avec TopK et avec les attributs que vous projetez. La métrique est également fixée au minimum de 1 Ko par demande. À un niveau élevé TopK avec une projection complète, les données renvoyées peuvent dépasser les données examinées.
N'estimez pas le coût de l'indice vectoriel à partir du nombre de dimensions. Utilisez les VectorWriteRequestBytes valeurs VectorSearchRequestBytes et renvoyées par votre propre charge de travail ou les CloudWatch mesures correspondantes. Validez par rapport à un ensemble de données représentatif avant de dimensionner une charge de travail.