Les valeurs les plus optimales pour les options de votre index vectoriel dépendent de votre cas d'utilisation, de votre ensemble de données vectorielles et des vecteurs de requête. Vous pouvez définir et ajuster ces valeurs en créant un index vectoriel et en définissant index_option_list dans l'instruction CREATE VECTOR INDEX. Vous devrez peut-être effectuer un réglage itératif pour trouver les meilleures valeurs pour votre charge de travail spécifique.
Voici quelques consignes utiles à suivre pour choisir les valeurs appropriées :
tree_depth (niveau d'arbre) : si la table que vous indexez comporte moins de 10 millions de lignes, utilisez un tree_depth de 2. Sinon, un tree_depth de 3 accepte les tables comportant jusqu'à environ 10 milliards de lignes.
num_leaves : utilisez la racine carrée du nombre de lignes dans l'ensemble de données. Une valeur plus élevée peut augmenter le temps de création de l'index vectoriel. Évitez de définir num_leaves sur une valeur supérieure à table_row_count divisé par 1 000, car cela entraîne des feuilles trop petites et de mauvaises performances.
num_leaves_to_search : cette option spécifie le nombre de nœuds feuilles de l'index à rechercher. L'augmentation de num_leaves_to_search améliore le rappel, mais augmente également la latence et les coûts. Nous vous recommandons d'utiliser une valeur num_leaves_to_search égale à 1 % du nombre total de feuilles défini dans l'instruction CREATE VECTOR INDEX. Si vous utilisez une clause de filtre, augmentez cette valeur pour élargir la recherche.
Si vous obtenez un rappel acceptable, mais que le coût des requêtes est trop élevé, ce qui entraîne un faible nombre maximal de requêtes par seconde, essayez d'augmenter num_leaves en suivant ces étapes :
Définissez num_leaves sur un multiple k de sa valeur d'origine (par exemple, 2 * sqrt(table_row_count)).
Définissez num_leaves_to_search sur le même multiple k de sa valeur d'origine.
Essayez de réduire num_leaves_to_search pour améliorer le coût et les RPS tout en conservant le rappel.
Améliorer le rappel
Pour améliorer le rappel, envisagez d'ajuster la valeur num_leaves_to_search ou de reconstruire votre index vectoriel.
Augmenter la valeur num_leaves_to_search
Si la valeur num_leaves_to_search est trop petite, vous aurez peut-être plus de mal à trouver les voisins les plus proches pour certains vecteurs de requête. Créer un index vectoriel avec une valeur num_leaves_to_search plus élevée peut aider à améliorer le rappel en recherchant davantage de feuilles. Les requêtes récentes peuvent contenir davantage de ces vecteurs complexes.
Recompiler l'index vectoriel
La structure arborescente de l'index vectoriel est optimisée pour l'ensemble de données au moment de la création et reste statique par la suite. Par conséquent, si des vecteurs très différents sont ajoutés après la création de l'index vectoriel initial, la structure arborescente peut être sous-optimale, ce qui entraîne un rappel moins performant.
Pour reconstruire votre index vectoriel sans temps d'arrêt :
Créez un index vectoriel sur la même colonne d'embedding que l'index vectoriel actuel, en mettant à jour les paramètres (par exemple, OPTIONS) selon vos besoins.
Une fois l'index créé, utilisez l'indication FORCE_INDEX pour pointer vers le nouvel index afin de mettre à jour la requête de recherche vectorielle. afin que la requête utilise le nouvel index de vecteur. Vous devrez peut-être également réajuster num_leaves_to_search dans votre nouvelle requête.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]