As métricas de usabilidade incluem métricas que ajudam a entender o estado da utilização do índice com métricas, como configuração do índice e número de verificações do índice.
Nome da métrica
Tipo de dado
Descrição
relid
OID
Identificador exclusivo da tabela que contém o índice vetorial.
indexrelid
OID
Identificador exclusivo do índice vetorial
schemaname
NAME
Nome do esquema proprietário do índice
relname
NAME
Nome da tabela que contém o índice
indexrelname
NAME
Nome do índice
indextype
NAME
Tipo do índice. Esse valor é sempre definido como scann
indexconfig
TEXT[]
Configuração, como contagem de folhas e quantizador, definida para o índice quando ele foi criado
indexsize
TEXT
Tamanho do índice
indexscan
BIGINT
Número de verificações de índice iniciadas no índice
partitioncount
BIGINT
Número de partições (nós folha) na árvore.
Métricas de ajuste
As métricas de ajuste oferecem insights sobre a otimização atual do índice, permitindo que você aplique recomendações para melhorar a performance das consultas.
Nome da métrica
Tipo de dado
Descrição
insertcount
BIGINT
Número de operações de inserção no índice. Essa métrica também inclui o número de linhas que existiam antes da criação do índice.
updatecount
BIGINT
Número de operações de atualização no índice. Essa métrica não considera atualizações HOT.
deletecount
BIGINT
Número de operações de exclusão no índice.
distribution
JSONB
Distribuições de vetores em todas as partições do índice.
Os seguintes campos mostram a distribuição:
maximum (INT8): número máximo de vetores em todas as partições.
minimum (INT8): número mínimo de vetores em todas as partições.
average (FLOAT) : número médio de vetores em todas as partições.
outliers (INT8[]): outliers principais em todas as partições. Esse valor mostra os 20 outliers principais.
Observação:devido às características inerentes do algoritmo de clusterização K-means, sempre haverá algum grau de variância na distribuição de vetores entre as partições, mesmo quando o índice é criado inicialmente.
distributionpercentile
JSONB
A distribuição do índice vetorial ajuda a entender a distribuição de vetores entre as partições do índice do ScaNN. As partições são criadas com base no valor num_leaves definido durante a criação do índice.
A distribuição do índice de vetor contém buckets para os percentis 10, 25, 50, 75, 90, 95, 99 e 100. Cada bucket contém os seguintes valores:
Número de vetores presentes na partição no percentil especificado.
Número de partições que têm vetores dentro do intervalo definido pelos percentis atual e anterior.
Observação:devido às características inerentes do algoritmo de clusterização K-means, sempre há algum grau de variância na distribuição de vetores entre as partições, mesmo quando o índice é criado inicialmente.
Recomendação de ajuste com base nas métricas
Mutação
As métricas insertcount, updatecount e deletecount mostram juntas as mudanças ou mutações no vetor do índice.
O índice é criado com um número específico de vetores e partições. Quando operações como inserção, atualização ou exclusão são realizadas no índice de vetor, elas afetam apenas o conjunto inicial de partições em que os vetores residem. Como resultado, o número de vetores em cada partição varia com o tempo, o que pode afetar o recall, o QPS ou ambos.
Se você encontrar problemas de lentidão ou precisão, como QPS baixo ou recall ruim, nas suas consultas de pesquisa de ANN ao longo do tempo, revise essas métricas. Um número alto de mutações em relação ao número total de vetores pode indicar a necessidade de reindexação.
Distribuição
A métrica distribution mostra as distribuições de vetores em todas as partições.
Quando você cria um índice, ele é criado com um número específico de vetores e partições fixas. O processo de particionamento e a distribuição subsequente ocorrem com base nessa consideração. Se outros vetores forem adicionados, eles serão particionados entre as partições atuais, resultando em uma distribuição diferente em comparação com a distribuição quando o índice foi criado. Como a distribuição final não considera todos os vetores simultaneamente, o recall, o QPS ou ambos podem ser afetados.
Se você notar um declínio gradual na performance das suas consultas de pesquisa de rede neural artificial, como tempos de resposta mais lentos ou redução na acurácia dos resultados (medida por QPS ou recall), verifique essa métrica e faça a reindexação.
Percentil de distribuição
A métrica distributionpercentile é uma distribuição de índice vetorial na visualização pg_stat_ann_indexes que ajuda a entender a distribuição de vetores entre partições do seu índice ScaNN. As partições são criadas com base no valor num_leaves definido durante a criação do índice.
Quando você cria um índice alloydb_scann no conjunto inicial de linhas definindo num_leaves, o índice pode mudar a distribuição de vetores nas partições devido a operações de dados (mutações de distorção) ou o número de vetores pode aumentar significativamente. Essas mudanças podem levar à degradação do QPS, do recall ou de ambos. A distribuição do índice de vetor pode fornecer indicadores se a mutação causar uma mudança na distribuição do índice. Essas informações podem ajudar você a determinar se um reindex é necessário ou se uma mudança nas configurações de tempo de pesquisa pode melhorar a performance da consulta.
Em um índice vetorial, a distribuição de vetores entre partições raramente é perfeitamente uniforme. Esse desequilíbrio é chamado de distribuição não uniforme. Um certo grau de não uniformidade é esperado e não significa que você precisa reindexar. Uma distribuição não uniforme tem as seguintes características:
A variância do número de vetores é baixa. A variância pode ser calculada como
O número de partições com 0 vetores é baixo e pode ser inferior a 30% das partições.
A variância do número de partições é baixa.
$ variance _{p} = abs(p_{num\_partitions} - num\_leaves * (p_{percentile} - p-1_{percentile})) $ em que "p" é um bucket de distribuição de índice de vetor.
O número de vetores em qualquer percentil é
$< 8 x (\frac{num\_rows\ during\ index\ creation\ time}{ num\_leaves})$
Quando essas condições não são atendidas, REINDEX pode ser necessário com base no quanto o QPS e o recall são afetados.
Os cenários a seguir, embora menos comuns do que a distribuição não uniforme, podem ocorrer:
Índice uniforme aproximado:quando a maioria das partições tem o mesmo número de vetores diferentes de zero e a variância do número de vetores é baixa, é um índice uniforme aproximado. REINDEX é obrigatório se os vetores numéricos em cada partição forem> 8 * vetor médio em index_creation_time.
Índice esparso:também ocorre quando mais de 50% das partições estão vazias. Por exemplo, um índice esparso é criado quando várias exclusões ocorrem em uma tabela. Nesse cenário, os vetores se concentram em um pequeno número de partições, o que aumenta a quantidade de vetores em cada uma delas. Quando isso acontecer, solte e recrie o índice.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eThis page describes metrics for vector indexes in AlloyDB Omni, accessible through the \u003ccode\u003epg_stat_ann_indexes\u003c/code\u003e view after installing the \u003ccode\u003ealloydb_scann\u003c/code\u003e extension.\u003c/p\u003e\n"],["\u003cp\u003eUsability metrics provide insight into index utilization, including configuration details, index size, and the number of index scans.\u003c/p\u003e\n"],["\u003cp\u003eTuning metrics, such as \u003ccode\u003einsertcount\u003c/code\u003e, \u003ccode\u003eupdatecount\u003c/code\u003e, \u003ccode\u003edeletecount\u003c/code\u003e, and \u003ccode\u003edistribution\u003c/code\u003e, help evaluate index optimization and identify the potential for performance improvements.\u003c/p\u003e\n"],["\u003cp\u003eHigh mutation counts (\u003ccode\u003einsertcount\u003c/code\u003e, \u003ccode\u003eupdatecount\u003c/code\u003e, \u003ccode\u003edeletecount\u003c/code\u003e) relative to the total number of vectors can indicate a need for reindexing to avoid performance issues like slow queries or poor recall.\u003c/p\u003e\n"],["\u003cp\u003eChanges in vector distribution across partitions, as shown by the \u003ccode\u003edistribution\u003c/code\u003e metric, can impact query performance and may also signal the need for reindexing.\u003c/p\u003e\n"]]],[],null,["# Vector index metrics\n\nSelect a documentation version: 16.3.0keyboard_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/16.3.0/docs/store-index-query-vectors).\n\n\u003cbr /\u003e\n\nFor more information about viewing the metrics, see [View vector index metrics](/alloydb/omni/16.3.0/docs/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."]]