האצת חיפוש וקטורים באמצעות מנוע מבוסס-עמודות

בחירת גרסה של מאמר העזרה:

אתם יכולים להשתמש במנוע מבוסס-העמודות של AlloyDB Omni כדי להאיץ את חיפושי הווקטורים כשאתם משתמשים באינדקס Scalable Nearest Neighbors ‏ (ScaNN) או באינדקס Hierarchical Navigable Small World ‏ (HNSW). מנוע מבוסס-עמודות פועל כמטמון בזיכרון עם אופטימיזציה לקריאה של אינדקסים וקטוריים.

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

אפשר להשתמש ב-HNSW עם מנוע מבוסס-עמודות רק עבור קלאסטרים של AlloyDB Omni שמופעלים באמצעות PostgreSQL בגרסה 17 ואילך. ב-ScaNN עם מנוע עמודות אין מגבלה כזו.

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

  • מגדירים את דגלי מסד הנתונים google_columnar_engine.enabled ו-google_columnar_engine.enable_index_caching לערך on כדי להפעיל את המנוע מבוסס-העמודות ואת התכונה שלו לשמירת אינדקסים במטמון.

    כדי להגדיר את הדגלים של מסד הנתונים, מריצים את הפקודה ALTER SYSTEM PostgreSQL:

    ALTER SYSTEM SET google_columnar_engine.enabled = 'on';
ALTER SYSTEM SET google_columnar_engine.enable_index_caching = 'on';

    כדי שהשינוי בפרמטרים של ההגדרות ייכנס לתוקף, מפעילים מחדש את הקונטיינר הפועל עם AlloyDB Omni:

    Docker 

    sudo docker restart CONTAINER_NAME

    Podman 

    sudo podman restart CONTAINER_NAME

    מידע נוסף על הגדרת דגלים זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

  • יוצרים אינדקס ScaNN או יוצרים אינדקס HNSW במסד הנתונים.

הוספת אינדקס למנוע מבוסס-עמודות

אחרי שמפעילים את מנוע מבוסס-העמודות, אפשר להוסיף אינדקס קיים למטמון באמצעות פונקציית ה-SQL‏ google_columnar_engine_add_index().

כדי להוסיף אינדקס למנוע מבוסס-עמודות, מריצים את השאילתה הבאה:

SELECT google_columnar_engine_add_index('INDEX_NAME');

מחליפים את INDEX_NAME בשם של אינדקס הווקטורים.

אחרי שמוסיפים אינדקס למנוע מבוסס-עמודות, כל השאילתות שמשתמשות באינדקס הזה מואצות באופן אוטומטי על ידי המנוע מבוסס-העמודות. כדי לוודא שהשאילתות הווקטוריות שלכם מואצות על ידי מנוע מבוסס-עמודות, אתם יכולים להשתמש בEXPLAIN (ANALYZE, COLUMNAR_ENGINE)תוכנית בשאילתה.

אימות השימוש במטמון

כדי לוודא שהשאילתות הווקטוריות מואצות על ידי מנוע מבוסס-עמודות, אפשר להשתמש בתוכנית EXPLAIN (ANALYZE, COLUMNAR_ENGINE) בשאילתה.

דוגמה לתוכנית הרצה של ScaNN

הדוגמה הבאה היא של תוכנית הפעלה לשאילתה שמשתמשת באינדקס ScaNN שנוסף למנוע העמודות:

EXPLAIN (ANALYZE TRUE, SCANN TRUE, COSTS FALSE, TIMING FALSE, SUMMARY FALSE, VERBOSE FALSE, COLUMNAR_ENGINE TRUE)
SELECT * FROM t ORDER BY val <=> '[0.5,0.5,0.5,0.5]' LIMIT 100;

--This contains details about ScaNN's usage from the columnar engine. Example:
------------------------------------------------------------------------------------------------------
 Index Scan using scann_idx on t t_1 (actual rows=100 loops=1)
      Order By: (val <=> '[0.5,0.5,0.5,0.5]'::vector)
      Limit: 100
      ScaNN Info: (... columnar engine nodes hit=6...)
      Columnar Engine ScaNN Info: (index found=true)
(5 rows)

הנוכחות של columnar engine nodes hit ו-Columnar Engine ScaNN Info: (index found=true) בפלט מאשרת שהמנוע מבוסס-עמודות משמש לשאילתה.

דוגמה לתוכנית הרצה של HNSW

בתוכנית הרצה מוצג הקטע Columnar Engine HNSW Info עבור האינדקס הרלוונטי, שבו מוצגים מדדים כמו היחס בין הרכיבים שאוחזרו ממנוע מבוסס-עמודות (elements_from_ce) לבין הרכיבים שאוחזרו מהדיסק (elements_from_disk).

הדוגמה הבאה היא תוכנית הרצה לשאילתה שמשתמשת באינדקס HNSW שנוסף למנוע מבוסס-עמודות:

EXPLAIN (ANALYZE, COLUMNAR_ENGINE) SELECT * FROM documents ORDER BY embedding <=> '[0.1, 0.2, 0.3, 0.4, 0.5]'::vector LIMIT 5;

--This contains details about HNSW's usage from the columnar engine. Example:
------------------------------------------------------------------------------------------------------
 Limit (actual rows=5 loops=1)
   ->  Index Scan using hnsw_idx on documents (actual rows=5 loops=1)
         Order By: (embedding '[0.1, 0.2, 0.3, 0.4, 0.5]'::vector)
         Columnar Engine HNSW Info: (index found=true elements_from_ce=385 elements_from_disk=0)
         Columnar Check: table is not in the columnar store
(5 rows)

התגובה מראה שהאינדקס מואץ על ידי מנוע מבוסס-עמודות, כי כל הרכיבים אוחזרו ממנוע מבוסס-עמודות (elements_from_ce=385) ואף אחד מהם לא אוחזר מהדיסק (elements_from_disk=0).

כששינויים בנתונים, כמו הצהרות INSERT,‏ UPDATE או DELETE, מבטלים את התוקף של רשומות במטמון, מנוע העמודות משתמש בגישה היברידית כדי לשמור על דיוק ועל ביצועים. הוא קורא וקטורים תקפים שנשמרו במטמון ישירות מהזיכרון, ומביא רק את הווקטורים החדשים או את הווקטורים ששונו מהדיסק.

אם משנים כמות גדולה של נתונים, יכול להיות שיהיה גידול זמני בערך של elements_from_disk וירידה בביצועים עד לרענון של המטמון.

ניהול האינדקס שנשמר במטמון

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

  • כדי לרענן את המטמון באופן ידני, מריצים את הפקודה הבאה:

    SELECT google_columnar_engine_refresh_index('INDEX_NAME');

  • כדי לבדוק את סטטוס האינדקס, מריצים את הפקודה הבאה:

    SELECT google_columnar_engine_verify('INDEX_NAME');

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

    SELECT google_columnar_engine_drop_index('INDEX_NAME');

  • כדי לראות את האינדקסים הפעילים, מריצים את הפקודה הבאה:

    SELECT * FROM g_columnar_indexes;

  • כדי להציג אינדקסים עם חלוקה למחיצות, מריצים את הפקודה הבאה:

    SELECT * FROM g_columnar_index_partitions;

מחליפים את INDEX_NAME בשם האינדקס.

מגבלות

כשמרעננים אינדקסים של HNSW שמנוע מבוסס-עמודות מאיץ, יכול להיות שזמנית ייעשה שימוש בזיכרון עד פי שניים מגודל האינדקס.

המאמרים הבאים