Nilai paling optimal untuk opsi indeks vektor Anda bergantung pada kasus penggunaan, set data vektor, dan vektor kueri Anda. Anda dapat menetapkan dan menyesuaikan nilai ini dengan membuat indeks vektor baru dan menetapkan index_option_list dalam pernyataan CREATE VECTOR INDEX. Anda mungkin perlu melakukan penyesuaian
berulang untuk menemukan nilai terbaik untuk workload spesifik Anda.
Berikut beberapa panduan berguna yang harus diikuti saat memilih nilai yang sesuai:
tree_depth (tingkat hierarki): Jika tabel yang Anda indeks memiliki kurang dari 10 juta baris, gunakan tree_depth2. Jika tidak, tree_depth dari 3
mendukung tabel hingga sekitar 10 miliar baris.
num_leaves: Gunakan akar kuadrat dari jumlah baris dalam set data. Nilai yang lebih besar dapat meningkatkan waktu pembuatan indeks vektor. Hindari menetapkan num_leaves
yang lebih besar dari table_row_count dibagi 1000 karena akan menghasilkan
daun yang terlalu kecil dan performa yang buruk.
num_leaves_to_search: Opsi ini menentukan jumlah node daun indeks yang
ditelusuri. Meningkatkan num_leaves_to_search akan meningkatkan perolehan, tetapi juga meningkatkan latensi dan biaya. Sebaiknya gunakan angka yang 1% dari total jumlah daun yang ditentukan dalam pernyataan CREATE VECTOR INDEX sebagai nilai untuk num_leaves_to_search. Jika Anda menggunakan klausa filter, tingkatkan
nilai ini untuk memperluas penelusuran.
Jika perolehan yang dapat diterima tercapai, tetapi biaya kueri terlalu tinggi,
sehingga menghasilkan QPS maksimum yang rendah, coba tingkatkan num_leaves dengan mengikuti
langkah-langkah berikut:
Tetapkan num_leaves ke beberapa kelipatan k dari nilai aslinya (misalnya,
2 * sqrt(table_row_count)).
Tetapkan num_leaves_to_search agar sama dengan kelipatan k dari nilai aslinya.
Lakukan eksperimen dengan mengurangi num_leaves_to_search untuk meningkatkan biaya dan QPS sambil mempertahankan perolehan.
Meningkatkan perolehan
Untuk meningkatkan perolehan, pertimbangkan untuk menyesuaikan nilai num_leaves_to_search atau membangun ulang indeks vektor Anda.
Naikkan nilai num_leaves_to_search
Jika nilai num_leaves_to_search terlalu kecil, Anda mungkin akan lebih
kesulitan menemukan tetangga terdekat untuk beberapa vektor kueri. Membuat indeks vektor baru dengan nilai num_leaves_to_search yang lebih tinggi dapat membantu meningkatkan perolehan dengan menelusuri lebih banyak daun. Kueri terbaru mungkin berisi lebih banyak vektor sulit ini.
Membangun ulang indeks vektor
Struktur pohon indeks vektor dioptimalkan untuk set data pada saat
pembuatan, dan bersifat statis setelahnya. Oleh karena itu, jika vektor yang sangat berbeda ditambahkan setelah membuat indeks vektor awal, struktur hierarki mungkin menjadi kurang optimal, sehingga menyebabkan perolehan yang lebih buruk.
Untuk membangun ulang indeks vektor tanpa periode nonaktif:
Buat indeks vektor baru pada kolom embedding yang sama dengan indeks vektor saat ini, perbarui parameter (misalnya, OPTIONS) sebagaimana mestinya.
Setelah pembuatan indeks selesai, gunakan petunjuk FORCE_INDEX
untuk menunjuk indeks baru guna memperbarui kueri penelusuran vektor. Hal ini memastikan
bahwa kueri menggunakan indeks vektor baru. Anda mungkin juga perlu menyetel ulang
num_leaves_to_search dalam kueri baru Anda.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
