I valori più ottimali per le opzioni dell'indice vettoriale dipendono dal caso d'uso,
dal set di dati vettoriali e dai vettori di query. Puoi impostare e ottimizzare questi valori
creando un nuovo indice vettoriale e impostando index_option_list
nell'istruzione CREATE VECTOR INDEX. Potresti dover eseguire una messa a punto iterativa per trovare i valori migliori per il tuo carico di lavoro specifico.
Ecco alcune linee guida utili da seguire quando scegli i valori appropriati:
tree_depth (livello dell'albero): se la tabella che stai indicizzando ha meno di 10
milioni di righe, utilizza un tree_depth di 2. In caso contrario, un tree_depth di 3
supporta tabelle con un massimo di circa 10 miliardi di righe.
num_leaves: utilizza la radice quadrata del numero di righe nel set di dati. Un
valore maggiore può aumentare il tempo di creazione dell'indice vettoriale. Evita di impostare num_leaves
superiore a table_row_count diviso per 1000, in quanto ciò comporta foglie eccessivamente
piccole e prestazioni scarse.
num_leaves_to_search: questa opzione specifica il numero di nodi foglia dell'indice
che vengono cercati. L'aumento di num_leaves_to_search migliora il richiamo, ma aumenta anche la latenza e i costi. Ti consigliamo di utilizzare un numero pari all'1% del numero totale di foglie definito nell'istruzione CREATE VECTOR INDEX come valore per num_leaves_to_search. Se utilizzi una clausola di filtro, aumenta
questo valore per ampliare la ricerca.
Se si ottiene un richiamo accettabile, ma il costo delle query è troppo elevato,
con conseguente basso QPS massimo, prova ad aumentare num_leaves seguendo questi
passaggi:
Imposta num_leaves su un multiplo k del suo valore originale (ad esempio,
2 * sqrt(table_row_count)).
Imposta num_leaves_to_search in modo che sia lo stesso multiplo k del suo valore originale.
Prova a ridurre num_leaves_to_search per migliorare il costo e le QPS
mantenendo il richiamo.
Migliorare il ricordo
Per migliorare il richiamo, valuta la possibilità di ottimizzare il valore di num_leaves_to_search o
di ricompilare l'indice vettoriale.
Aumenta il valore di num_leaves_to_search
Se il valore di num_leaves_to_search è troppo piccolo, potrebbe essere più
difficile trovare i vicini più vicini per alcuni vettori di query. La creazione di un nuovo
indice vettoriale con un valore num_leaves_to_search maggiore può contribuire a migliorare
il richiamo cercando più foglie. Le query recenti potrebbero contenere un numero maggiore di questi
vettori difficili.
Ricrea l'indice vettoriale
La struttura ad albero dell'indice vettoriale viene ottimizzata per il set di dati al momento
della creazione e rimane statica in seguito. Pertanto, se vengono aggiunti vettori
significativamente diversi dopo la creazione dell'indice vettoriale iniziale, la struttura
ad albero potrebbe non essere ottimale, con conseguente richiamo peggiore.
Per ricompilare l'indice vettoriale senza tempi di inattività:
Crea un nuovo indice vettoriale nella stessa colonna di incorporamento dell'indice vettoriale attuale, aggiornando i parametri (ad esempio OPTIONS) in base alle esigenze.
Una volta completata la creazione dell'indice, utilizza il suggerimento FORCE_INDEX
per indicare il nuovo indice per aggiornare la query di ricerca vettoriale. In questo modo
la query utilizza il nuovo indice vettoriale. Potresti anche dover eseguire di nuovo l'ottimizzazione
num_leaves_to_search nella nuova query.
[[["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-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)."]]
