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

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

שינוי אפשרויות החיפוש הווקטורי

אם לא מציינים אפשרויות לאינדקס וקטורי, Spanner מנסה לבחור אפשרויות אופטימליות באופן אוטומטי. משתמשים מתקדמים שרוצים לכוונן את האפשרויות של אינדקס הווקטורים עבור עומס העבודה הספציפי שלהם יכולים ליצור אינדקס וקטורים חדש ולהגדיר את הערכים האלה באמצעות index_option_list בהצהרת CREATE VECTOR INDEX. הערכים האופטימליים ביותר לאפשרויות של אינדקס הווקטורים תלויים בתרחיש לדוגמה, במערך נתוני הווקטורים ובשאילתות הווקטורים. יכול להיות שתצטרכו לבצע כוונון איטרטיבי כדי למצוא את הערכים הטובים ביותר לעומס העבודה הספציפי שלכם.

ריכזנו כאן כמה הנחיות שיעזרו לכם לבחור ערכים מתאימים:

  • ‫tree_depth (רמת העץ): אם בטבלה שמוסיפים לאינדקס יש פחות מ-10 מיליון שורות, משתמשים ב-tree_depth של 2. אחרת, tree_depth של 3 תומך בטבלאות עם עד כ-10 מיליארד שורות. אם לא מציינים ערך,‏ Spanner יקבע אוטומטית את הערך של tree_depth.

  • num_leaves: מומלץ לטרגט 200 עד 1,000 שורות לכל עלה. ערך גדול יותר של num_leaves מאריך את זמן בניית אינדקס הווקטור, אבל יכול להפחית את עלות השאילתה עבור recall יעד נתון. עם זאת, ערכים גדולים מדי של num_leaves עלולים לגרום לעלייה חוזרת בעלות השאילתה בגלל תקורה שקשורה לחיפוש של הרבה אשכולות עלים קטנים מאוד. אם לא מציינים ערך, Spanner קובע אוטומטית את הערך של num_leaves.

  • ‫num_branches: האפשרות הזו רלוונטית רק אם הערך של tree_depth הוא 3. מומלץ לטרגט 50 עד 500 עלים בכל ענף, והערך של num_branches צריך להיות קטן מ-num_leaves. ערך גדול יותר של num_branches מאריך את זמן הבנייה של אינדקס הווקטורים, אבל יכול להקטין את עלות השאילתה עבור ערך יעד נתון של דיוק. עם זאת, ערכים גדולים מדי של num_branches עלולים לגרום לעלות השאילתה לעלות שוב בגלל תקורה שקשורה לחיפוש של הרבה אשכולות עלים שהם קטנים מאוד. אם לא מציינים ערך, Spanner קובע אוטומטית את הערך של num_branches.

  • ‫num_leaves_to_search: האפשרות הזו מציינת כמה צמתי עלים של האינדקס נסרקים. הגדלת הערך של num_leaves_to_search משפרת את ההחזרה אבל גם מגדילה את זמן האחזור והעלות. מומלץ להשתמש במספר שהוא 1% ממספר העלים הכולל שמוגדר בהצהרת CREATE VECTOR INDEX בתור הערך של num_leaves_to_search. אם משתמשים בסעיף של מסנן, צריך להגדיל את הערך הזה כדי להרחיב את החיפוש.

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

  1. מגדירים את num_leaves ככפולה כלשהי k של הערך המקורי (לדוגמה, 2 * (table_row_count / 1000)).
  2. מגדירים את num_leaves_to_search כערך ששווה לערך המקורי שלו כפול k.
  3. כדאי לנסות להקטין את num_leaves_to_search כדי לשפר את העלות ואת השאילתות לשנייה, תוך שמירה על ההחזרה.

קביעת ערכי האפשרויות של חיפוש וקטורי

כדי לקבוע את הפרמטרים tree_depth, num_leaves ו-num_branches ש-Spanner משתמש בהם לאינדקס הווקטורי, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.INDEX_OPTIONS. יכול להיות שערכי הפרמטרים יהיו שונים קצת מהערכים שציינתם במפורש במהלך יצירת האינדקס, כי לפעמים Spanner משנה אותם כדי שיתאימו יותר לנתונים שלכם. אם לא ציינתם את הפרמטרים האלה, בתצוגה INFORMATION_SCHEMA.INDEX_OPTIONS מוצגים הערכים שנבחרו על ידי Spanner.

מריצים את השאילתה הזו כדי להציג את ערכי הפרמטרים:

SELECT
  opt.option_name,
  opt.option_type,
  opt.option_value
FROM
  INFORMATION_SCHEMA.INDEX_OPTIONS AS opt
WHERE
  opt.index_name = @vector_index_name;

השאילתה מחזירה שורות שכוללות את option_name: system_optimized_tree_depth,‏ system_optimized_num_leaves ו-system_optimized_num_branches, שמשקפים פרמטרים שמשמשים את האינדקס.

שיפור יכולת השליפה מהזיכרון

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

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

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

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

כדי לבנות מחדש את אינדקס הווקטורים ללא השבתה:

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

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

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

    ב. שינוי הסכימה: אפשר להגדיר את האפשרות disable_search באחד ממדדי הווקטורים. כשההגדרה היא true, ‏ Spanner משבית את אינדקס הווקטורים. אפשר לעשות את זה על ידי הפעלת הצהרת שינוי הסכימה ALTER VECTOR INDEX:

      ALTER VECTOR INDEX IncidentVectorIndex SET OPTIONS (disable_search=true);

    השיטה הזו מונעת מ-Spanner להשתמש באינדקס הווקטורי הזה במסד הנתונים. אם יש לכם שני אינדקסים והגדרתם את האפשרות הזו באינדקס הישן יותר, כל השאילתות ישתמשו באינדקס החדש אחרי שהשינוי בסכימה יחול. אם משתמשים ברמז FORCE_INDEX כדי לציין אינדקס וקטורי שהאפשרות disable_search שלו מוגדרת ל-true, השאילתה תיכשל.

  3. מבטלים את האינדקס הווקטורי המיושן.

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