Le metriche di usabilità includono metriche che ti aiutano a comprendere lo stato di
utilizzo dell'indice con metriche come la configurazione dell'indice e il numero di scansioni
dell'indice.
Nome metrica
Tipo di dati
Descrizione
relid
OID
Identificatore univoco della tabella che contiene l'indice vettoriale
indexrelid
OID
Identificatore univoco dell'indice vettoriale
schemaname
NAME
Nome dello schema proprietario dell'indice
relname
NAME
Nome della tabella contenente l'indice
indexrelname
NAME
Nome dell'indice
indextype
NAME
Tipo di indice. Questo valore è sempre impostato su scann
indexconfig
TEXT[]
Configurazione, ad esempio conteggio delle foglie e quantizzatore, definita per l'indice al momento della creazione
indexsize
TEXT
Dimensioni dell'indice
indexscan
BIGINT
Numero di scansioni dell'indice avviate sull'indice
Metriche di ottimizzazione
Le metriche di ottimizzazione forniscono informazioni sull'ottimizzazione corrente dell'indice, consentendoti di applicare i suggerimenti per migliorare le prestazioni delle query.
Nome metrica
Tipo di dati
Descrizione
insertcount
BIGINT
Numero di operazioni di inserimento nell'indice. Questa metrica include anche il numero di righe esistenti prima della creazione dell'indice.
updatecount
BIGINT
Numero di operazioni di aggiornamento sull'indice. Questa metrica non tiene conto di eventuali aggiornamenti HOT.
deletecount
BIGINT
Numero di operazioni di eliminazione sull'indice.
distribution
JSONB
Distribuzioni dei vettori in tutte le partizioni dell'indice.
I seguenti campi mostrano la distribuzione:
maximum (INT8): Numero massimo di vettori in tutte le partizioni.
minimum (INT8): Numero minimo di vettori in tutte le partizioni.
average (FLOAT) : Numero medio di vettori in tutte le partizioni.
outliers (INT8[]): I valori anomali principali in tutte le partizioni. Questo valore mostra i 20 valori anomali principali.
Nota:a causa delle caratteristiche intrinseche dell'algoritmo di clustering K-means, ci sarà sempre un certo grado di varianza nella distribuzione dei vettori tra le partizioni, anche quando l'indice viene creato inizialmente.
distributionpercentile
JSONB
La distribuzione dell'indice vettoriale ti aiuta a comprendere la distribuzione dei vettori tra le partizioni dell'indice ScaNN. Le partizioni vengono create in base al valore num_leaves definito durante la creazione dell'indice.
La distribuzione dell'indice vettoriale contiene bucket per i percentili 10, 25, 50, 75, 90, 95, 99 e 100. Ogni bucket contiene i seguenti valori:
Numero di vettori presenti nella partizione al percentile specificato.
Numero di partizioni che contengono vettori all'interno dell'intervallo definito dai percentili attuale e precedente.
Nota: a causa delle caratteristiche intrinseche dell'algoritmo di clustering K-means, esiste sempre un certo grado di varianza nella distribuzione dei vettori tra le partizioni, anche quando l'indice viene creato inizialmente.
Suggerimento di ottimizzazione basato sulle metriche
Mutazione
Le metriche insertcount, updatecount e deletecount mostrano insieme le modifiche o le mutazioni nel vettore dell'indice.
L'indice viene creato con un numero specifico di vettori e partizioni. Quando vengono eseguite operazioni come inserimento, aggiornamento o eliminazione sull'indice vettoriale, queste influiscono solo sul set iniziale di partizioni in cui risiedono i vettori. Di conseguenza, il numero di vettori in ogni partizione varia nel tempo, il che potrebbe influire sul richiamo, sulle QPS o su entrambi.
Se nel tempo riscontri problemi di lentezza o precisione, ad esempio QPS basso o scarso richiamo, nelle query di ricerca ANN, valuta la possibilità di esaminare queste metriche. Un numero elevato di mutazioni rispetto al numero totale di vettori potrebbe indicare la necessità di reindicizzazione.
Distribuzione
La metrica distribution mostra le distribuzioni dei vettori in tutte le partizioni.
Quando crei un indice, questo viene creato con un numero specifico di vettori e partizioni fisse. Il processo di partizionamento e la successiva distribuzione avvengono in base a questa considerazione. Se vengono aggiunti altri vettori, questi vengono partizionati tra le partizioni esistenti, il che comporta una distribuzione diversa rispetto a quella al momento della creazione dell'indice. Poiché la distribuzione finale non considera tutti i vettori contemporaneamente, il richiamo, le QPS o entrambi potrebbero essere interessati.
Se noti un calo graduale del rendimento delle query di ricerca ANN, ad esempio tempi di risposta più lenti o una riduzione dell'accuratezza dei risultati (misurata in QPS o richiamo), valuta la possibilità di controllare questa metrica e di reindicizzare.
Percentile di distribuzione
La metrica distributionpercentile è una distribuzione dell'indice vettoriale nella visualizzazione pg_stat_ann_indexes che ti aiuta a comprendere la distribuzione dei vettori tra le partizioni dell'indice ScaNN. Le partizioni vengono create in base al valore num_leaves definito durante la creazione dell'indice.
Quando crei un indice alloydb_scann sul set iniziale di righe impostando num_leaves, l'indice può modificare la distribuzione dei vettori tra le partizioni a causa di operazioni sui dati (mutazioni di asimmetria) o il numero di vettori potrebbe aumentare in modo significativo. Queste modifiche possono comportare una riduzione di QPS, richiamo o entrambi. La distribuzione dell'indice vettoriale può fornire indicatori se la mutazione causa una variazione nella distribuzione dell'indice. Queste informazioni possono aiutarti a determinare se è necessaria una reindicizzazione o se una modifica alle configurazioni del tempo di ricerca può contribuire a migliorare il rendimento delle query.
In un indice vettoriale, la distribuzione dei vettori tra le partizioni è raramente perfettamente uniforme. Questo squilibrio è chiamato distribuzione non uniforme. Un certo grado di non uniformità è spesso previsto e non significa che devi reindicizzare. Una distribuzione non uniforme ha le seguenti caratteristiche:
La varianza del numero di vettori è bassa. La varianza può essere calcolata come
Il numero di partizioni con 0 vettori è basso e potrebbe essere inferiore al 30% delle partizioni.
La varianza del numero di partizioni è bassa.
$ variance _{p} = abs(p_{num\_partitions} - num\_leaves * (p_{percentile} - p-1_{percentile})) $ where "p" is a vector index distribution bucket.
Il numero di vettori in qualsiasi percentile è
$< 8 x (\frac{num\_rows\ during\ index\ creation\ time}{ num\_leaves})$
Quando queste condizioni non sono soddisfatte, potrebbe essere necessario REINDEX in base alla quantità di QPS e al richiamo interessati.
I seguenti scenari, sebbene meno comuni della distribuzione non uniforme, possono verificarsi:
Indice uniforme approssimativo:quando la maggior parte delle partizioni ha lo stesso numero di vettori diversi da zero e la varianza del numero di vettori è bassa, si tratta di un indice uniforme approssimativo. REINDEX è obbligatorio se il numero di vettori in ogni partizione è $> 8 * average vector$ a index_creation_time.
Indice sparso:un indice sparso si verifica anche quando più del 50% delle partizioni è vuoto. Ad esempio, l'indice sparso viene creato quando si verificano più eliminazioni in una tabella. Questo scenario fa sì che i vettori si concentrino in un numero ridotto di partizioni, il che aumenta il numero di vettori in ogni partizione. In questo caso, elimina l'indice e ricrealo.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eThe \u003ccode\u003epg_stat_ann_indexes\u003c/code\u003e view provides metrics for vector indexes generated in AlloyDB Omni, accessible after installing the \u003ccode\u003ealloydb_scann\u003c/code\u003e extension.\u003c/p\u003e\n"],["\u003cp\u003eUsability metrics, such as \u003ccode\u003eindexconfig\u003c/code\u003e and \u003ccode\u003eindexscan\u003c/code\u003e, help to understand the current state of index utilization, including index configuration and scan frequency.\u003c/p\u003e\n"],["\u003cp\u003eTuning metrics, including \u003ccode\u003einsertcount\u003c/code\u003e, \u003ccode\u003eupdatecount\u003c/code\u003e, \u003ccode\u003edeletecount\u003c/code\u003e, and \u003ccode\u003edistribution\u003c/code\u003e, offer insights into index optimization and potential performance issues.\u003c/p\u003e\n"],["\u003cp\u003eHigh mutation rates, indicated by \u003ccode\u003einsertcount\u003c/code\u003e, \u003ccode\u003eupdatecount\u003c/code\u003e, and \u003ccode\u003edeletecount\u003c/code\u003e, or significant vector distribution variance, shown by the \u003ccode\u003edistribution\u003c/code\u003e metric, may suggest a need to reindex to improve query performance.\u003c/p\u003e\n"]]],[],null,["# Vector index metrics\n\nSelect a documentation version: 15.7.1keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/reference/vector-index-metrics)\n- [16.8.0](/alloydb/omni/16.8.0/docs/reference/vector-index-metrics)\n- [16.3.0](/alloydb/omni/16.3.0/docs/reference/vector-index-metrics)\n- [15.12.0](/alloydb/omni/15.12.0/docs/reference/vector-index-metrics)\n- [15.7.1](/alloydb/omni/15.7.1/docs/reference/vector-index-metrics)\n- [15.7.0](/alloydb/omni/15.7.0/docs/reference/vector-index-metrics)\n\n\u003cbr /\u003e\n\nThis page lists the metrics related to the vector indexes that you generate in AlloyDB Omni. You can view these metrics using the `pg_stat_ann_indexes` view that is available when you install [the `alloydb_scann` extension](/alloydb/omni/15.7.1/docs/ai/store-index-query-vectors).\n\n\u003cbr /\u003e\n\nFor more information about viewing the metrics, see [View vector index metrics](/alloydb/omni/15.7.1/docs/ai/tune-indexes#vector-index-metrics).\n\nUsability metrics\n-----------------\n\nThe usability metrics include metrics that help you understand the state of\nindex utilization with metrics, such as index configuration and number of index\nscans.\n\nTuning metrics\n--------------\n\nTuning metrics provide insights into your current index optimization, allowing you to apply recommendations for faster query performance.\n\n### Tuning recommendation based on the metrics\n\nMutation\n: The `insertcount`, `updatecount`,\n and `deletecount` metrics together show the changes or mutations in\n the vector for the index.\n: The index is created with a specific number of vectors and partitions. When operations such as insert, update, or delete are performed on the vector index, it only affects the initial set of partitions where the vectors reside. Consequently, the number of vectors in each partition fluctuates over time, potentially impacting recall, QPS, or both.\n: If you encounter slowness or accuracy issues such as low QPS or poor recall, in your ANN search queries over time, then consider reviewing these metrics. A high number of mutations relative to the total number of vectors could indicate the need for reindexing.\n\nDistribution\n: The `distribution` metric shows the vector distributions across all partitions.\n: When you create an index, it is created with a specific number of vectors and fixed partitions. The partitioning process and subsequent distribution occurs based on this consideration. If additional vectors are added, they are partitioned among the existing partitions, resulting in a different distribution compared to the distribution when the index was created. Since the final distribution does not consider all vectors simultaneously, the recall, QPS, or both might be affected.\n: If you observe a gradual decline in the performance of your ANN search queries, such as slower response times or reduced accuracy in the results (measured by QPS or recall), then consider checking this metric and reindexing.\n\nDistribution percentile\n: The `distributionpercentile` metric, is a vector index distribution in the `pg_stat_ann_indexes` view that helps you understand the distribution of vectors between partitions of your ScaNN index. The partitions are created based on `num_leaves` value defined during index creation.\n: When you create an `alloydb_scann` index on the initial set of rows by setting `num_leaves`, the index can change the distribution of vectors across the partitions due to data operations (skew mutations), or the number of vectors might increase significantly. These changes can lead to degradation of QPS, recall, or both. The vector index distribution can give you signals if the mutation causes a change in the index distribution. This information can help you determine if a reindex is required, or if a change in search time configurations can help improve query performance.\n: In a vector index, the distribution of vectors across partitions is rarely perfectly even. Such imbalance is referred to as a *non-uniform distribution* . A certain degree of non-uniformity is often expected and doesn't mean you need to reindex. A non-uniform distribution has the following characteristics: \n\n - The variance of the number of vectors is low. Variance can be calculated as \n $(P100(num\\\\_vectors) - p10(num\\\\_vectors))\\*(\\\\frac{num\\\\_leaves}{total\\\\_num\\\\_row})$\n - The number of partitions with 0 vectors is low, and might be less than 30% of partitions.\n - The variance of the number of partitions is low. \n $ variance _{p} = abs(p_{num\\\\_partitions} - num\\\\_leaves \\* (p_{percentile} - p-1_{percentile})) $ where \"p\" is a vector index distribution bucket.\n - The number of vectors at any percentile is \n $\\\u003c 8 x (\\\\frac{num\\\\_rows\\\\ during\\\\ index\\\\ creation\\\\ time}{ num\\\\_leaves})$\n\n When these conditions aren't satisfied, `REINDEX` might be required based on how much QPS and recall are affected.\n: The following scenarios, while less common than non-uniform distribution, can occur: \n\n - **Approximate Uniform Index:** When most of the partitions have the same number of non-zero vectors and the variance of the number of vectors is low, it is an approximate uniform index. `REINDEX` is required if the number vectors in each partition are $\\\u003e 8 \\* average vector$ at `index_creation_time`.\n - **Sparse Index:** A sparse index also occurs where \\\u003e 50% of the partitions are empty. For example, sparse index is created when multiple deletions occur on a table. This scenario causes the vectors to be concentrated in a small number of partitions, which increases the number of vectors in each partition. When this happens, drop the index and recreate it."]]
