Auf dieser Seite wird die AlloyDB Omni-Version 18.1.0 mit der Bereitstellungsoption Container dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Leistung von Vektorabfragen in AlloyDB Omni optimieren

Wählen Sie eine Dokumentationsversion aus:

In diesem Dokument wird beschrieben, wie Sie Ihre Indexe optimieren, um eine schnellere Abfrageleistung und einen besseren Recall in AlloyDB Omni zu erzielen.

Hinweis

Bevor Sie einen ScaNN-Index erstellen, führen Sie die folgenden Schritte aus:

Prüfen Sie, ob bereits eine Tabelle mit Ihren Daten erstellt wurde.
Damit beim Generieren des Index keine Probleme auftreten, muss der Wert, den Sie für das Flag maintenance_work_mem und shared_buffers festlegen, kleiner als der gesamte Arbeitsspeicher der Maschine sein.
Wenn Sie Indexe mit vier Ebenen verwenden möchten, müssen Sie zuerst die Vorschau-Funktion für Ihre Instanz aktivieren. Wählen Sie eine der folgenden beiden Methoden aus, um die Vorschaufunktion zu aktivieren:
- Aktivieren Sie das scann.enable_preview_features Datenbankflag.
- Legen Sie das Datenbankflag auf Sitzungsebene auf 3 fest.scann.max_allowed_num_levels sql SET scann.max_allowed_num_levels = 3;

`ScaNN`-Index optimieren

Anhand der folgenden Anleitung können Sie die Anzahl der Ebenen für Ihren ScaNN-Index bestimmen:

Für 0 bis 10 Millionen Zeilen: Wählen Sie einen Index mit zwei Ebenen aus.
Für 10 Millionen bis 100 Millionen Zeilen:
- Wenn Sie den Such-Recall priorisieren möchten, wählen Sie einen Index mit zwei Ebenen aus.
- Wenn Sie die Build-Dauer des Index priorisieren möchten, wählen Sie einen Index mit drei Ebenen aus.
Für 100 Millionen bis 1 Milliarde Zeilen:
- Wenn Sie den Such-Recall priorisieren möchten, wählen Sie einen Index mit drei Ebenen aus.
- Wenn Sie die Index-Build-Dauer priorisieren möchten, wählen Sie einen Index mit vier Ebenen aus (in der Vorschau).
Für 1 Milliarde bis 10 Milliarden Zeilen: Wählen Sie einen Index mit vier Ebenen aus (in der Vorschau).

In den folgenden Beispielen für ScaNN-Indexe mit zwei, drei und vier Ebenen wird gezeigt, wie Optimierungsparameter für eine Tabelle mit 1.000.000 Zeilen festgelegt werden:

Index mit zwei Ebenen

SET LOCAL scann.num_leaves_to_search = 1;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 1/2)]);

Index mit drei Ebenen

SET LOCAL scann.num_leaves_to_search = 10;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 2/3)], max_num_levels = 2);

Index mit vier Ebenen

(in der Vorschau)

SET LOCAL scann.num_leaves_to_search = 100;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 3/4)], max_num_levels = 3);

DML-Ungültigmachungen aufgrund der Beschleunigung mit der spaltenbasierten Engine verarbeiten

Wenn Sie Ihre Vektorsuchen mit der spaltenbasierten Engine beschleunigen möchten, beachten Sie, dass sich DML- und DDL-Ungültigmachungen in den Basistabellen auf die Leistung von Vektorabfragen auswirken können. Bei einem hohen DML-Durchsatz sollten Sie das Datenbankflag google_columnar_engine.refresh_threshold_percentage optimieren oder den Index manuell mit dem Befehl google_columnar_engine_refresh_index aktualisieren.

Abfragen analysieren

Verwenden Sie den Befehl EXPLAIN ANALYZE, um Ihre Abfrage-Insights zu analysieren, wie in der folgenden SQL-Abfrage gezeigt.

  EXPLAIN ANALYZE SELECT result-column
  FROM my-table
  ORDER BY EMBEDDING_COLUMN <-> embedding('text-embedding-005', 'What is a database?')::vector
  LIMIT 1;

Die Beispielantwort QUERY PLAN enthält Informationen wie die benötigte Zeit, die Anzahl der gescannten oder zurückgegebenen Zeilen und die verwendeten Ressourcen.

Limit  (cost=0.42..15.27 rows=1 width=32) (actual time=0.106..0.132 rows=1 loops=1)
  ->  Index Scan using my-scann-index on my-table  (cost=0.42..858027.93 rows=100000 width=32) (actual time=0.105..0.129 rows=1 loops=1)
        Order By: (embedding_column <-> embedding('text-embedding-005', 'What is a database?')::vector(768))
        Limit value: 1
Planning Time: 0.354 ms
Execution Time: 0.141 ms

Messwerte für Vektorindex ansehen

Mit den Messwerten für den Vektorindex können Sie die Leistung Ihres Vektorindex überprüfen, Bereiche für Verbesserungen identifizieren und den Index bei Bedarf anhand der Messwerte optimieren.

Führen Sie die folgende SQL-Abfrage aus, um alle Messwerte für den Vektorindex aufzurufen. Dabei wird die Ansicht pg_stat_ann_indexes verwendet:

SELECT * FROM pg_stat_ann_indexes;

Die Ausgabe sollte in etwa so aussehen:

-[ RECORD 1 ]----------+---------------------------------------------------------------------------
relid                  | 271236
indexrelid             | 271242
schemaname             | public
relname                | t1
indexrelname           | t1_ix1
indextype              | scann
indexconfig            | {num_leaves=100,max_num_levels=1,quantizer=SQ8}
indexsize              | 832 kB
indexscan              | 0
insertcount            | 250
deletecount            | 0
updatecount            | 0
partitioncount         | 100
distribution           | {"average": 3.54, "maximum": 37, "minimum": 0, "outliers": [37, 12, 11, 10, 10, 9, 9, 9, 9, 9]}
distributionpercentile |{"10": { "num_vectors": 0, "num_partitions": 0 }, "25": { "num_vectors": 0, "num_partitions": 30 }, "50": { "num_vectors": 3, "num_partitions": 30 }, "75": { "num_vectors": 5, "num_partitions": 19 }, "90": { "num_vectors": 7, "num_partitions": 11 }, "95": { "num_vectors": 9, "num_partitions": 5 }, "99": { "num_vectors": 12, "num_partitions": 4 }, "100": { "num_vectors": 37, "num_partitions": 1 }}

Führen Sie den folgenden Befehl aus, um die Anzahl der Zeilen aufzurufen, die zum Zeitpunkt der Indexerstellung erstellt wurden:

SELECT * FROM pg_stat_ann_index_creation;