בדף הזה מתוארת גרסה 18.4.0 של AlloyDB Omni, עם אפשרות הפריסה של RPM. בחירת אפשרות פריסה אחרת

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שיפור הביצועים של שאילתות וקטוריות ב-AlloyDB Omni

בוחרים גרסת תיעוד:

במאמר הזה מוסבר איך לשפר את הביצועים של השאילתות ואת יכולת האחזור ב-AlloyDB Omni באמצעות כוונון של האינדקסים.

לפני שמתחילים

לפני שיוצרים אינדקס ScaNN, צריך לבצע את הפעולות הבאות:

מוודאים שכבר נוצרה טבלה עם הנתונים.
כדי למנוע בעיות בזמן יצירת האינדקס, ודאו שהערך שהגדרתם לדגל maintenance_work_mem ולדגל shared_buffers קטן מנפח הזיכרון הכולל של המכונה.
כדי להשתמש באינדקסים עם ארבע רמות, קודם צריך להפעיל את התכונה תצוגה מקדימה במכונה. כדי להפעיל את תכונת התצוגה המקדימה, בוחרים באחת משתי השיטות הבאות:
- מפעילים את הדגל לניהול מסד הנתונים scann.enable_preview_features.
- מגדירים את דגל מסד הנתונים scann.max_allowed_num_levels ברמת הסשן לערך 3. sql SET scann.max_allowed_num_levels = 3;

כוונון אינדקס `ScaNN`

כדי לקבוע את מספר הרמות שנדרשות לאינדקס ScaNN, אפשר להיעזר בהנחיות הבאות:

אם יש 0 עד 10 מיליון שורות: בוחרים אינדקס דו-רמתי.
ל-10 מיליון עד 100 מיליון שורות:
- כדי לתת עדיפות לאחזור החיפוש, בוחרים אינדקס דו-שלבי.
- כדי לתת עדיפות לזמן בניית האינדקס, בוחרים אינדקס ברמה 3.
בטבלאות עם 100 מיליון עד מיליארד שורות:
- כדי לתת עדיפות לאחזור החיפוש, בוחרים באינדקס של שלוש רמות.
- כדי לתת עדיפות למשך הזמן של תהליך ה-build של האינדקס, בוחרים אינדקס עם ארבע רמות (בתצוגה מקדימה).
למיליארד עד 10 מיליארד שורות: בוחרים אינדקס עם ארבע רמות (בתצוגה מקדימה).

בדוגמאות הבאות מוצגים אינדקסים של ScaNN בשתי רמות, בשלוש רמות ובארבע רמות, שממחישים איך מגדירים פרמטרים של אופטימיזציה לטבלה עם 1,000,000 שורות:

אינדקס דו-רמתי

-- Setting num_leaves to 1000 as power(1000000, 1/2) for two-level index
BEGIN;

SET LOCAL maintenance_work_mem = '300MB';

CREATE INDEX my_scann_index ON my_table
  USING scann (vector_column cosine)
  WITH (num_leaves = 1000);
END;

אינדקס עם שלוש רמות

-- Setting num_leaves to 10000 as power(1000000, 2/3) for three-level index
BEGIN;

SET LOCAL maintenance_work_mem = '3000MB';

CREATE INDEX my_scann_index ON my_table
  USING scann (vector_column cosine)
  WITH (num_leaves = 10000, max_num_levels = 2);
END;

אינדקס עם ארבע רמות

(בגרסת טרום-השקה)

-- Setting num_leaves to 31623 as power(1000000, 3/4) for four-level index
BEGIN;

SET LOCAL maintenance_work_mem = '9300MB';

CREATE INDEX my_scann_index ON my_table
  USING scann (vector_column cosine)
  WITH (num_leaves = 31623, max_num_levels = 3);
END;

טיפול בביטולים של DML בגלל האצה באמצעות מנוע מבוסס-עמודות

אם בחרתם להאיץ את החיפושים הווקטוריים באמצעות המנוע מבוסס-העמודות, חשוב לדעת שביטולים של DML ו-DDL במסדי נתונים טבלאיים יכולים להשפיע על הביצועים של השאילתות הווקטוריות. אם קצב הנתונים של DML גבוה, כדאי לשקול לשנות את הדגל לניהול מסד הנתונים google_columnar_engine.refresh_threshold_percentage או לרענן את האינדקס באופן ידני באמצעות הפקודה google_columnar_engine_refresh_index.

ניתוח השאילתות

כדי לנתח את התובנות לגבי השאילתות, משתמשים בפקודה EXPLAIN ANALYZE, כמו בדוגמה הבאה של שאילתת SQL.

  EXPLAIN ANALYZE SELECT result_column
  FROM my_table
  ORDER BY EMBEDDING_COLUMN <=> embedding('text-embedding-005', 'What is a database?')::vector
  LIMIT 1;

תגובת הדוגמה QUERY PLAN כוללת מידע כמו הזמן שחלף, מספר השורות שנסרקו או הוחזרו והמשאבים שהיו בשימוש.

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

צפייה במדדים של אינדקס וקטורים

אתם יכולים להשתמש במדדים של אינדקס וקטורי כדי לבדוק את הביצועים של האינדקס הווקטורי, לזהות תחומים לשיפור ולכוונן את האינדקס על סמך המדדים, אם צריך.

כדי לראות את כל המדדים של אינדקס וקטורי, מריצים את שאילתת ה-SQL הבאה, שמשתמשת בתצוגה pg_stat_ann_indexes:

SELECT * FROM pg_stat_ann_indexes;

הפלט אמור להיראות כך:

-[ 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 }}

כדי לראות את מספר השורות שנוצרו בזמן יצירת האינדקס, מריצים את הפקודה הבאה:

SELECT * FROM pg_stat_ann_index_creation;