벡터 색인 옵션의 최적 값은 사용 사례, 벡터 데이터 세트, 쿼리 벡터에 따라 달라집니다. 새 벡터 색인을 만들고 CREATE VECTOR INDEX 문에서 index_option_list을 설정하여 이러한 값을 설정하고 조정할 수 있습니다. 특정 워크로드의 최적 값을 찾기 위해서는 반복 조정을 수행해야 할 수 있습니다.
적합한 값을 선택할 때 따라야 할 유용한 가이드라인은 다음과 같습니다.
tree_depth (트리 레벨): 색인을 작성하려는 테이블의 행 수가 1, 000만 개 미만이면 tree_depth로 2를 사용합니다. 그렇지 않고 tree_depth에 3을 사용하면 행이 최대 100억 개까지 포함된 테이블을 지원합니다.
num_leaves: 데이터 세트에서 행 수의 제곱근을 사용합니다. 값이 클수록 벡터 색인 빌드 시간이 증가할 수 있습니다. num_leaves를 table_row_count/1000보다 크게 설정하면 소규모 리프 수가 과도하게 늘어나고 성능이 저하될 수 있으므로 피해야 합니다.
num_leaves_to_search: 이 옵션은 검색되는 색인의 리프 노드 수를 지정합니다. num_leaves_to_search를 늘리면 재현율이 향상되지만 지연 시간과 비용도 증가합니다. CREATE VECTOR INDEX 문에 정의된 총 리프 수의 1%에 해당하는 숫자를 num_leaves_to_search의 값으로 사용하는 것이 좋습니다. 필터 절을 사용하는 경우 이 값을 늘려서 검색 범위를 넓힙니다.
적절한 재현율이 달성되었지만 쿼리 비용이 너무 높아서 최대 QPS가 낮아지면 다음 단계에 따라 num_leaves를 늘려보세요.
num_leaves를 원래 값의 k 배수로 설정합니다(예: 2 * sqrt(table_row_count)).
num_leaves_to_search를 원래 값의 k 배수로 설정합니다.
실험적으로 num_leaves_to_search를 줄여서 재현율을 유지하면서 비용 및 QPS를 개선해보세요.
재현율 개선
재현율을 개선하려면 num_leaves_to_search 값을 조정하거나 벡터 색인을 다시 빌드하는 것이 좋습니다.
num_leaves_to_search 값 늘리기
num_leaves_to_search 값이 너무 작으면 일부 쿼리 벡터의 최근접 이웃을 찾는 것이 어려울 수 있습니다. num_leaves_to_search 값이 증가된 새 벡터 색인을 만들면 더 많은 리프를 검색하여 재현율을 개선할 수 있습니다. 최근 쿼리에 처리하기 어려운 벡터가 더 많이 포함되어 있을 수 있습니다.
벡터 색인 다시 빌드
벡터 색인의 트리 구조는 처음 생성될 때 데이터 세트에 맞게 최적화되었으며, 이후 변경되지 않았습니다. 따라서 초기 벡터 색인을 만든 후 약간 다른 벡터가 추가되면 트리 구조의 효율성이 저하되어 재현율이 저하될 수 있습니다.
다운타임 없이 벡터 색인을 다시 빌드하려면 다음 안내를 따르세요.
현재 벡터 색인과 동일한 임베딩 열에서 새 벡터 색인을 만들고 OPTIONS과 같은 매개변수를 적절하게 업데이트합니다.
색인 만들기가 완료되면 FORCE_INDEX 힌트를 사용하여 벡터 검색어가 업데이트되도록 새 색인을 가리킵니다. 이렇게 하면 쿼리에 새로운 벡터 색인이 사용됩니다. 새 쿼리에서 num_leaves_to_search를 다시 조정해야 할 수도 있습니다.
[[["이해하기 쉬움","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-05(UTC)"],[],[],null,["# Vector indexing best practices\n\n| **PostgreSQL interface note:** The examples in this topic are intended for GoogleSQL-dialect databases. This feature doesn't support PostgreSQL interface.\n\n\u003cbr /\u003e\n\n\n| **Note:** This feature is available with the Spanner Enterprise edition and Enterprise Plus edition. For more information, see the [Spanner editions overview](/spanner/docs/editions-overview).\n\n\u003cbr /\u003e\n\nThis page describes vector indexing best practices that optimize your\n[vector indexes](/spanner/docs/vector-indexes) and improve\n[approximate nearest neighbor (ANN) query results](/spanner/docs/find-approximate-nearest-neighbors#query-vector-embeddings).\n\nTune the vector search options\n------------------------------\n\nThe most optimal values for your vector index options depend on your use case,\nvector dataset, and on the query vectors. You can set and tune these values\nby creating a new vector index and setting the [`index_option_list`](/spanner/docs/reference/standard-sql/data-definition-language#index_option_list)\nin the `CREATE VECTOR INDEX` statement. You might need to perform iterative\ntuning to find the best values for your specific workload.\n\nHere are some helpful guidelines to follow when picking appropriate values:\n\n- `tree_depth` (tree level): If the table you're indexing has fewer than 10\n million rows, use a `tree_depth` of `2`. Otherwise, a `tree_depth` of `3`\n supports tables of up to about 10 billion rows.\n\n- `num_leaves`: Use the square root of the number of rows in the dataset. A\n larger value can increase vector index build time. Avoid setting `num_leaves`\n larger than the `table_row_count` divided by 1000 as this results in overly\n small leaves and poor performance.\n\n- `num_leaves_to_search`: This option specifies how many leaf nodes of the index\n are searched. Increasing `num_leaves_to_search` improves recall but also\n increases latency and cost. We recommend using a number that is 1% the total\n number of leaves defined in the `CREATE VECTOR INDEX` statement as the value\n for `num_leaves_to_search`. If you're using a filter clause, increase\n this value to widen the search.\n\nIf acceptable recall is achieved, but the cost of querying is too high,\nresulting in low maximum QPS, try increasing `num_leaves` by following these\nsteps:\n\n1. Set `num_leaves` to some multiple k of its original value (for example, `2 * sqrt(table_row_count)`).\n2. Set `num_leaves_to_search` to be the same multiple k of its original value.\n3. Experiment with reducing `num_leaves_to_search` to improve cost and QPS while maintaining recall.\n\nImprove recall\n--------------\n\nTo improve recall, consider tuning the `num_leaves_to_search` value or\nrebuilding your vector index.\n\n### Increase the `num_leaves_to_search` value\n\nIf the `num_leaves_to_search` value is too small, you might find it more\nchallenging to find the nearest neighbors for some query vectors. Creating a new\nvector index with an increased `num_leaves_to_search` value can help improve\nrecall by searching more leaves. Recent queries might contain more of these\nchallenging vectors.\n\n### Rebuild the vector index\n\nThe tree structure of the vector index is optimized for the dataset at the time\nof creation, and is static thereafter. Therefore, if significantly different\nvectors are added after creating the initial vector index, then the tree\nstructure might be sub-optimal, leading to poorer recall.\n\nTo rebuild your vector index without downtime:\n\n1. Create a new vector index on the same embedding column as the current vector index, updating parameters (for example, `OPTIONS`) as appropriate.\n2. After the index creation completes, use the [`FORCE_INDEX` hint](/spanner/docs/secondary-indexes#index-directive) to point at the new index to update the vector search query. This ensures that the query uses the new vector index. You might also need to retune `num_leaves_to_search` in your new query.\n3. Drop the outdated vector index.\n\nWhat's next\n-----------\n\n- Learn more about Spanner [vector indexes](/spanner/docs/vector-indexes).\n\n- Learn more about Spanner [approximate nearest neighbors](/spanner/docs/find-approximate-nearest-neighbors).\n\n- Learn more about the [GoogleSQL `APPROXIMATE_COSINE_DISTANCE()`, `APPROXIMATE_EUCLIDEAN_DISTANCE()`, `APPROXIMATE_DOT_PRODUCT()`](/spanner/docs/reference/standard-sql/mathematical_functions) functions.\n\n- Learn more about the [GoogleSQL `VECTOR INDEX` statements](/spanner/docs/reference/standard-sql/data-definition-language#vector_index_statements)."]]