שיטות מומלצות לחיפוש וקטור

במסמך הזה מפורטות המלצות לאופטימיזציה של הביצועים של חיפוש וקטורי ב-Spanner.

הסבר על מושגי יסוד ב-Spanner

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

כדאי לעיין במדריכים הבאים:

• סקירה כללית של הביצועים
• שיטות מומלצות ל-SQL
• ביצוע חיפוש של K השכנים הקרובים ביותר (KNN)
• ביצוע חיפוש משוער של השכנים הקרובים ביותר (ANN) באמצעות אינדקסים של וקטורים
• שיטות מומלצות ליצירת אינדקס של וקטורים

מערכת Spanner מעבדת שאילתות במקביל על סמך פיצולים של מסד הנתונים. בדיקה עם עומס שאילתות מתמשך של ייצור יכולה לאפשר פיצול מבוסס-עומס, שמשפר את ביצועי השאילתות באמצעות הגדלת המקביליות. כדי להגדיל את המקביליות של העומס העתידי, כדאי לשקול פיצול מראש של מסד הנתונים, במיוחד עבור KNN.

שיטות מומלצות לחיפוש וקטור

במסמך הזה מתוארות השיטות המומלצות הבאות לחיפוש וקטורי:

• הוספת הערה לעמודת ההטמעה
• שימוש בשאילתת top-k
• שימוש בערכים מילוליים של SQL עבור פסוקית LIMIT
• שימוש בסריקה מבוססת-אצווה
• שימוש ב-KNN למערכי נתונים קטנים
• שימוש ב-ANN למערכי נתונים גדולים

הוספת הערה לעמודה של ההטמעה

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

שימוש בשאילתת top-k

כדי למצוא את השכנים הקרובים ביותר, משתמשים בפסקה ORDER BY עם LIMIT. שאילתות Top-k מותאמות מאוד לחיפוש וקטורי. מומלץ להימנע מסינון לפי סף מרחק בתוך סעיף WHERE.

לדוגמה, לא מומלץ:

SELECT d.DocId
FROM Documents AS d
WHERE COSINE_DISTANCE(d.DocEmbedding, @vector) < 1;

במקום זאת, צריך להשתמש ב:

SELECT d.DocId
FROM Documents AS d
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

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

שימוש במחרוזות מילוליות של SQL עבור פסוקית LIMIT

אם מגבלת top-k קבועה, צריך להשתמש במחרוזת SQL במקום בפרמטר. לדוגמה, במקום LIMIT @limit, צריך להשתמש ב-LIMIT 10. כך כלי האופטימיזציה של שאילתות ב-Spanner מקבל יותר מידע כדי לבחור את תוכנית הביצוע של השאילתה הטובה ביותר.

שימוש בסריקה מבוססת-אצווה

שאילתות של חיפוש וקטורי דורשות סריקה אינטנסיבית. בשביל שאילתות KNN, כדאי להשתמש בסריקה מבוססת-batch עם ההנחיה לשאילתה scan_method=batch. זו שיטת הסריקה שמוגדרת כברירת מחדל לשאילתות ANN.

שימוש ב-KNN לקבוצות נתונים קטנות

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

שיפור הביצועים של KNN עם סינון באמצעות אינדקס משני

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

SELECT d.DocId
FROM Documents AS d
WHERE Category = 'toy'
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

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

CREATE INDEX ON Documents(Category) STORING (DocEmbedding);

יצירת האינדקס הזה עוזרת לזרז את שאילתת הסינון.

שימוש ב-ANN למערכי נתונים גדולים

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

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

  CREATE VECTOR INDEX ON Documents(DocEmbedding) STORING(Category);
  

• עמודות סינון מרכזיות: כדי להאיץ את הסינון של עמודות סלקטיביות מאוד שמסירות הרבה תוצאות, כדאי לארגן את העמודות האלה כעמודות מרכזיות נוספות באינדקס הווקטורי. השאילתות שבהן מצוין שוויון מדויק (באמצעות האופרטור =) למפתחות הנוספים האלה מואצות הכי הרבה. שימוש בסעיף IN עבור כל אחד ממקשי הקיצור הנוספים האלה לא ישיג את אותה רמת האצה.

  CREATE VECTOR INDEX ON Documents(DocEmbedding, Category);
  

• מומלץ להימנע מאחסון עמודות גדולות או משימוש בהן כמפתחות: פעולה כזו עלולה לדלל את בלוקי הנתונים של ההטמעות, מה שיכול להפחית את יעילות הקריאה. לחלופין, אפשר להשתמש בעמודת hash באינדקס, ולהשתמש בעמודה המקורית הגדולה כמסנן אחרי top-k.

• יצירת אינדקס וקטורי מסונן (חלקי):אם אתם מבצעים שאילתה רק על קבוצת משנה של מערך הנתונים, ותנאי סינון מגדיר את קבוצת המשנה הזו, כמו Category = "Tech", כדאי ליצור אינדקס וקטורי מסונן או חלקי.