Die optimalen Werte für Ihre Vektorindexoptionen hängen von Ihrem Anwendungsfall, Ihrem Vektordatensatz und den Abfragevektoren ab. Sie können diese Werte festlegen und optimieren, indem Sie einen neuen Vektorindex erstellen und index_option_list in der CREATE VECTOR INDEX-Anweisung festlegen. Möglicherweise müssen Sie die Werte für Ihre spezifische Arbeitslast iterativ optimieren.
Hier sind einige hilfreiche Richtlinien für die Auswahl geeigneter Werte:
tree_depth (Baumebene): Wenn die Tabelle, die Sie indexieren, weniger als 10 Millionen Zeilen hat, verwenden Sie für tree_depth den Wert 2. Andernfalls unterstützt ein tree_depth von 3 Tabellen mit bis zu etwa 10 Milliarden Zeilen.
num_leaves: Verwenden Sie die Quadratwurzel der Anzahl der Zeilen im Dataset. Ein größerer Wert kann die Build-Zeit des Vektorindex verlängern. Vermeiden Sie es, num_leaves größer als table_row_count / 1.000 festzulegen, da dies zu zu kleinen Blättern und einer schlechten Leistung führt.
num_leaves_to_search: Mit dieser Option wird angegeben, wie viele Blattknoten des Index durchsucht werden. Durch Erhöhen von num_leaves_to_search wird der Recall verbessert, aber auch die Latenz und die Kosten steigen. Wir empfehlen, für num_leaves_to_search eine Zahl zu verwenden, die 1% der Gesamtzahl der Blätter ist, die in der CREATE VECTOR INDEX-Anweisung definiert sind. Wenn Sie eine Filterklausel verwenden, erhöhen Sie diesen Wert, um die Suche auszuweiten.
Wenn ein akzeptabler Recall erreicht wird, die Kosten für Abfragen jedoch zu hoch sind, was zu einer niedrigen maximalen QPS führt, versuchen Sie, num_leaves zu erhöhen. Gehen Sie dazu so vor:
Setzen Sie num_leaves auf ein Vielfaches k des ursprünglichen Werts (z. B. 2 * sqrt(table_row_count)).
Legen Sie num_leaves_to_search als das k-fache des ursprünglichen Werts fest.
Reduzieren Sie num_leaves_to_search, um Kosten und QPS zu verbessern und gleichzeitig den Recall beizubehalten.
Recall verbessern
Um den Recall zu verbessern, können Sie den num_leaves_to_search-Wert anpassen oder den Vektorindex neu erstellen.
Erhöhen Sie den Wert von num_leaves_to_search.
Wenn der Wert von num_leaves_to_search zu klein ist, kann es schwieriger sein, die nächsten Nachbarn für einige Anfragevektoren zu finden. Wenn Sie einen neuen Vektorindex mit einem höheren num_leaves_to_search-Wert erstellen, kann dies die Erinnerung verbessern, da mehr Blätter durchsucht werden. Die letzten Suchanfragen enthalten möglicherweise mehr dieser anspruchsvollen Vektoren.
Vektorindex neu erstellen
Die Baumstruktur des Vektorindex wird zum Zeitpunkt der Erstellung für den Datensatz optimiert und ist danach statisch. Wenn nach der Erstellung des ursprünglichen Vektorindex deutlich unterschiedliche Vektoren hinzugefügt werden, ist die Baumstruktur möglicherweise suboptimal, was zu einem schlechteren Recall führt.
So erstellen Sie Ihren Vektorindex ohne Ausfallzeiten neu:
Erstellen Sie einen neuen Vektorindex für dieselbe Einbettungsspalte wie den aktuellen Vektorindex und aktualisieren Sie die Parameter (z. B. OPTIONS) entsprechend.
Nachdem der Index erstellt wurde, verwenden Sie den FORCE_INDEX-Hinweis, um auf den neuen Index zu verweisen und die Vektorsuchanfrage zu aktualisieren. So wird sichergestellt, dass für die Abfrage der neue Vektorindex verwendet wird. Möglicherweise müssen Sie num_leaves_to_search in Ihrer neuen Abfrage neu abstimmen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
