사용성 측정항목에는 색인 구성, 색인 스캔 수와 같은 측정항목을 사용하여 색인 활용 상태를 파악하는 데 도움이 되는 측정항목이 포함됩니다.
측정항목 이름
데이터 유형
설명
relid
OID
벡터 색인이 포함된 테이블의 고유 식별자
indexrelid
OID
벡터 색인의 고유 식별자
schemaname
NAME
색인을 소유한 스키마의 이름
relname
NAME
색인이 포함된 테이블의 이름
indexrelname
NAME
색인의 이름
indextype
NAME
색인 유형. 이 값은 항상 scann으로 설정됩니다.
indexconfig
TEXT[]
색인이 생성될 때 정의된 리프 수, 양자화기 등의 구성
indexsize
TEXT
색인 크기
indexscan
BIGINT
색인에서 시작된 색인 스캔 수
partitioncount
BIGINT
트리의 파티션(리프 노드) 수
조정 측정항목
조정 측정항목은 현재 색인 최적화에 대한 통계를 제공하므로 더 빠른 쿼리 성능을 위해 추천을 적용할 수 있습니다.
측정항목 이름
데이터 유형
설명
insertcount
BIGINT
색인에 대한 삽입 작업 수입니다. 이 측정항목에는 색인이 생성되기 전에 존재했던 행 수도 포함됩니다.
updatecount
BIGINT
색인에 대한 업데이트 작업 수입니다. 이 측정항목은 HOT 업데이트를 고려하지 않습니다.
deletecount
BIGINT
색인에 대한 삭제 작업 수입니다.
distribution
JSONB
색인의 모든 파티션에 걸친 벡터 분포입니다.
다음 필드에 분포가 표시됩니다.
maximum (INT8): 모든 파티션의 최대 벡터 수입니다.
minimum (INT8): 모든 파티션의 최소 벡터 수입니다.
average (FLOAT): 모든 파티션의 평균 벡터 수입니다.
outliers (INT8[]): 모든 파티션의 상위 이상점입니다. 이 값은 상위 20개의 이상점을 보여줍니다.
참고: K-평균 클러스터링 알고리즘의 고유한 특성으로 인해 색인이 처음 생성될 때도 파티션 간 벡터 분포에 어느 정도 분산이 항상 존재합니다.
distributionpercentile
JSONB
벡터 색인 분포를 사용하면 ScaNN 색인의 파티션 간 벡터 분포를 파악할 수 있습니다. 파티션은 색인 생성 중에 정의된 num_leaves 값을 기반으로 생성됩니다.
벡터 색인 분포에는 10, 25, 50, 75, 90, 95, 99, 100번째 백분위수의 버킷이 포함됩니다. 각 버킷에는 다음 값이 포함됩니다.
지정된 백분위수의 파티션에 있는 벡터 수입니다.
현재 백분위수와 이전 백분위수로 정의된 범위 내에 벡터가 있는 파티션 수입니다.
참고: K-평균 클러스터링 알고리즘의 고유한 특성으로 인해 색인이 처음 생성될 때도 파티션 간 벡터 분포에 어느 정도 분산이 항상 있습니다.
측정항목을 기반으로 한 조정 추천
변형
insertcount, updatecount, deletecount 측정항목은 색인의 벡터에 있는 변경사항이나 변형을 함께 보여줍니다.
색인은 특정 수의 벡터와 파티션으로 생성됩니다. 벡터 색인에서 삽입, 업데이트, 삭제와 같은 작업을 실행하면 벡터가 있는 초기 파티션 세트에만 영향을 미칩니다. 따라서 각 파티션의 벡터 수가 시간에 따라 변동되어 재현율, QPS 또는 둘 다에 영향을 미칠 수 있습니다.
시간이 지남에 따라 ANN 검색 쿼리에서 QPS가 낮거나 재현율이 좋지 않은 등 속도 또는 정확도 문제가 발생하는 경우 이러한 측정항목을 검토해 보세요. 전체 벡터 수에 비해 변형 수가 많으면 색인 생성이 필요할 수 있습니다.
배포
distribution 측정항목은 모든 파티션의 벡터 분포를 보여줍니다.
색인을 만들면 특정 수의 벡터와 고정 파티션으로 생성됩니다. 파티셔닝 프로세스와 그 이후의 분포는 이 고려사항을 기반으로 이루어집니다. 벡터가 추가되면 기존 파티션 간에 파티션이 지정되므로 색인이 생성될 때의 분포와 다른 분포가 됩니다. 최종 분포에서는 모든 벡터를 동시에 고려하지 않으므로 재현율, QPS 또는 둘 다 영향을 받을 수 있습니다.
ANN 검색 쿼리의 성능이 점진적으로 저하되는 경우(예: 응답 시간이 느려지거나 결과의 정확도가 감소함(QPS 또는 재현율로 측정)) 이 측정항목을 확인하고 색인을 다시 생성하는 것이 좋습니다.
분포 백분위수
distributionpercentile 측정항목은 pg_stat_ann_indexes 뷰의 벡터 색인 분포로, ScaNN 색인의 파티션 간 벡터 분포를 이해하는 데 도움이 됩니다. 파티션은 색인 생성 중에 정의된 num_leaves 값을 기반으로 생성됩니다.
num_leaves를 설정하여 초기 행 집합에 alloydb_scann 색인을 만들면 데이터 작업(편향 변형)으로 인해 파티션 간 벡터 분포가 변경되거나 벡터 수가 크게 증가할 수 있습니다. 이러한 변경사항으로 인해 QPS 또는 재현율이 저하되거나 둘 다 저하될 수 있습니다. 벡터 색인 분포는 변형으로 인해 색인 분포가 변경되는 경우 신호를 제공할 수 있습니다. 이 정보를 통해 재색인이 필요한지 또는 검색 시간 구성을 변경하면 쿼리 성능을 개선할 수 있는지 확인할 수 있습니다.
벡터 색인에서 파티션 간 벡터 분포는 완벽하게 균등한 경우가 거의 없습니다. 이러한 불균형을 균일하지 않은 분포라고 합니다. 어느 정도의 불균일성은 일반적으로 발생되는 현상이며, 이로 인해 색인을 다시 생성해야 하는 것은 아닙니다. 균일하지 않은 분포에는 다음과 같은 특징이 있습니다.
파티션 수의 분산이 낮습니다.
$ variance _{p} = abs(p_{num\_partitions} - num\_leaves * (p_{percentile} - p-1_{percentile})) $ 여기서 'p'는 벡터 색인 분산 버킷입니다.
특정 백분위수의 벡터 수는 다음과 같습니다.
$< 8 x (\frac{num\_rows\ during\ index\ creation\ time}{ num\_leaves})$
이러한 조건이 충족되지 않으면 QPS와 재현율이 얼마나 영향을 받는지에 따라 REINDEX가 필요할 수 있습니다.
다음 시나리오는 불균일 분포보다 덜 일반적이지만, 발생할 수 있습니다.
대략적인 균일 색인: 대부분의 파티션에 0이 아닌 벡터 수가 동일하고 벡터 수의 분산이 낮은 경우 대략적인 균일 색인입니다. 각 파티션의 숫자 벡터가 index_creation_time에 $평균 벡터의 8배$ 보다 큰 경우 REINDEX가 필요합니다.
희소 색인: 파티션의 50% 이상이 비어 있는 경우에도 희소 색인이 발생합니다. 예를 들어 테이블에서 삭제가 여러 번 발생하면 희소 색인이 생성됩니다. 이 시나리오에서는 벡터가 소수의 파티션에 집중되어 각 파티션의 벡터 수가 증가합니다. 이 경우 색인을 삭제하고 다시 만듭니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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."]]
