בדף הזה מוסבר איך מתבצעים חיפושים וקטוריים במכונות של Cloud SQL ל-MySQL. ב-Cloud SQL אפשר לאחסן הטמעות וקטורים, ליצור אינדקסים של וקטורים ולבצע חיפושים וקטוריים בשילוב עם נתונים אחרים שמאוחסנים.
אחסון של הטמעת וקטורים
הטמעות וקטורים מאוחסנות בטבלה שתואמת למאפייני ACID (אטומיות, עקביות, בידוד ועמידות). כמו נתונים יחסיים אחרים בטבלה, אתם יכולים לגשת להטמעות הווקטורים בטבלה באמצעות סמנטיקה קיימת של טרנזקציות.
כדי ליצור מיפוי בין שורות בטבלה לבין ייצוגים וקטוריים, צריך ליצור עמודה בטבלה שבה יאוחסנו הטמעות הווקטורים. העמודה חייבת להשתמש בסוג הנתונים VECTOR. בעמודה של הטמעת הווקטורים אפשר לאחסן רק הטמעות וקטורים שמשתמשות בדיוק באותם מאפיינים שציינתם כשהגדרתם את העמודה. אין הגבלות על מספר השורות בטבלה שבה אתם מאחסנים את הטמעות הווקטורים.
אם יש לכם מספיק נפח אחסון וזיכרון זמין במכונה של Cloud SQL, אתם יכולים ליצור כמה טבלאות עם עמודות משלהן להטמעת וקטורים.
שכפול הנתונים פועל באותו אופן בעמודה של הטמעת הווקטורים כמו בעמודות אחרות של MySQL InnoDB.
בקטע מגבלות מפורטות המגבלות וההגבלות על טבלאות, עמודות ופקודות DML של הטמעת וקטורים.
אינדקסים של וקטורים
כדי לבצע חיפושי דמיון של ANN בהטמעות הווקטוריות, צריך להשתמש באינדקס וקטורי. Cloud SQL יוצר אינדקסים של וקטורים באמצעות האלגוריתם Scalable Nearest Neighbors (ScANN).
אלה הדרישות לאינדקסים של וקטורים:
- אפשר ליצור רק אינדקס וקטורי אחד לכל טבלה.
- אם יש לכם כמה טבלאות עם הטמעות וקטורים במכונה, אתם יכולים ליצור אינדקסים של וקטורים לכל אחת מהן.
- אם אתם יוצרים אינדקס וקטורי, אתם לא יכולים להוסיף אילוץ למפתח הראשי של הטבלה שנוסף לה אינדקס.
כדי לשפר את איכות החיפוש, כדאי ליצור אינדקס וקטורי רק אחרי שטוענים את רוב הנתונים במסד הנתונים הטבלאי. אם יש פחות מ-1,000 הטמעות במסד הנתונים הטבלאי, יצירת האינדקס תיכשל.
כשמחליטים אם ליצור אינדקס וקטורי, אם יש לכם מספר קטן של שורות, כדאי לשקול אם אתם יכולים לבצע חיפוש KNN במקום זאת. ההחלטה אם להשתמש בחיפוש KNN או בחיפוש ANN תלויה גם במספר הממדים בהטמעת הווקטורים. אם יש לכם מספר גדול של הטמעות, יכול להיות שתצטרכו אינדקס וקטורי.
לרשימה של מגבלות והגבלות על אינדקסים וקטוריים, ראו מגבלות. במאמר יצירה וניהול של אינדקסים וקטוריים מוסבר איך יוצרים אינדקס וקטורי.
עדכונים של אינדקס וקטורים
Cloud SQL מעדכן אינדקסים של וקטורים בזמן אמת. כל טרנזקציה שמבצעת פעולות של שפת טיפול בנתונים (DML) במסד הנתונים הטבלאי, מעבירה את השינויים גם לאינדקסים המשויכים של הווקטורים. אינדקסים של וקטורים פועלים כמו כל אינדקס משני אחר בטבלה. האינדקסים של הווקטורים עקביים לחלוטין מבחינת טרנזקציות ותואמים ל-ACID. אם מבטלים טרנזקציה, השינויים של הביטול מתרחשים גם באינדקס הווקטורי.
שכפול של אינדקסים של וקטורים
Cloud SQL משכפל אינדקסים של וקטורים לכל הרפליקות לקריאה בלבד, כולל לרפליקות מדורגות. כשיוצרים עותק חדש לקריאה בלבד ממכונה ראשית שיש בה הטמעת וקטורים, העותק לקריאה בלבד מקבל את הגדרות הטמעת הווקטורים מהמכונה הראשית. אם יש לכם עותקי replica לקריאה בלבד, אתם צריכים להפעיל בכל אחד מהם תמיכה בהטמעת וקטורים.
מבחינת ההשפעה על השהיית הרפליקציה, יצירה ותחזוקה של אינדקסים וקטוריים פועלות באותו אופן כמו אינדקסים רגילים של MySQL.
התמדה, השבתה והשפעה על התחזוקה
אינדקסים של וקטורים נשמרים באותו אופן כמו מסדי נתונים טבלאיים, עם תמיכה מלאה ב-ACID. אינדקסים של וקטורים תמיד מסונכרנים עם הנתונים של מסד הנתונים הטבלאי שלהם, ויש להם את אותה רמת חשיפה, בידוד ובטיחות במקרה של קריסה. אין השפעה על האינדקס הווקטורי כשהמכונה מושבתת או עוברת תחזוקה.
תחזוקת אינדקסים
אחרי שמבצעים פעולות DML נרחבות במסד הנתונים הטבלאי, יכול להיות שאינדקס הווקטורים שאומן על הנתונים הראשוניים (בזמן יצירת האינדקס) לא ישקף את המצב החדש. זה עלול לפגוע באיכות החיפוש.
האינדקס מורכב משני חלקים:
- עץ האינדקס. המודל הזה נוצר על ידי אימון על נתונים קיימים. הוא לא משתנה במהלך חיי האינדקס.
- האינדקס נשאר. הם מכילים את כל שורות הנתונים. העלים של האינדקס אף פעם לא יוצאים מסנכרון.
עץ האינדקסים עשוי להיות פחות יעיל אחרי שמריצים מספר גדול של פקודות DML, כי השורות עוברות מעלה אחד לאחר. כדי לרענן את עץ האינדקס, צריך לבנות מחדש את האינדקס.
פעולות DDL שלא נתמכות בטבלאות עם אינדקסים של וקטורים
אי אפשר לבצע את הפעולות הבאות של שפת הגדרת נתונים (DDL) בטבלאות שיש בהן אינדקסים של וקטורים.
- פעולות לשינוי טבלאות שדורשות את אלגוריתם ההעתקה
- פעולות לשינוי טבלה שמחייבות בנייה מחדש של הטבלה
- הסרה או שינוי של המפתח הראשי
- העברת הטבלה למרחב טבלאות כללי
חיפוש וקטורי
ב-Cloud SQL יש פונקציות של מרחק וקטורי שמאפשרות לבצע חיפושים של דמיון וקטורי לפי השכן הקרוב ביותר (KNN) והשכן הקרוב ביותר בקירוב (ANN) במכונה. כשמריצים שאילתה, וקטור השאילתה מושווה לווקטורים במערך הנתונים. פונקציות מרחק מחשבות את המרחק בין הווקטורים באמצעות מדד דמיון כמו קוסינוס. הווקטורים עם המרחק הקצר ביותר ביניהם הם הכי דומים, והם מוחזרים בתוצאות החיפוש.
ב-Cloud SQL משתמשים בפונקציות הבאות כדי למדוד את המרחק בין וקטורים בחיפושים וקטוריים, כשמבצעים חיפושים וקטוריים של ANN ו-KNN:
- קוסינוס: מודד את הקוסינוס של הזווית בין שני וקטורים. ערך קטן יותר מצביע על דמיון רב יותר בין הווקטורים.
- מכפלה סקלרית: מחשבת את הקוסינוס של הזווית כפול המכפלה של גודלי הווקטורים התואמים.
- L2 squared distance: מודד את המרחק האוקלידי בין שני וקטורים על ידי הוספת המרחק בריבוע בכל מימד.
חיפוש KNN
חיפוש וקטורי של KNN הוא שיטת החיפוש המועדפת כשצריך תוצאות מדויקות או כשרוצים להוסיף סינון סלקטיבי. בחיפוש KNN מתבצע חישוב מרחק של וקטור השאילתה עם כל הטמעה בקבוצת הנתונים כדי למצוא את השכן הקרוב ביותר. חיפושי KNN ב-Cloud SQL מספקים אחזור מושלם. בחיפושי KNN לא משתמשים באינדקס וקטורי, ולכן הם מתאימים לעבודה עם מערכי נתונים קטנים יותר.
כדי לבצע חיפוש KNN, משתמשים בפונקציה vector_distance שמקבלת שני וקטורים כקלט: וקטור השאילתה (מה שמחפשים) ווקטור מועמד מקבוצת הנתונים. הוא מחשב את המרחק בין שני הווקטורים האלה.
משתמשים ב-vector_distance בהצהרת SELECT. מידע נוסף זמין במאמר חיפוש K-nearest neighbors (KNN).
אם אתם מגלים ש-KNN לא מניב ביצועים טובים, אתם יכולים ליצור אינדקס וקטורי מאוחר יותר ולהמשיך להשתמש ב-approx_distance באפליקציה שלכם לחיפושי ANN.
חיפוש ANN
חיפוש וקטורי של ANN הוא סוג החיפוש המועדף כשחשובה יעילות השאילתה. הוא מאיץ את חיפושי הדמיון על ידי חישוב המרחק בין וקטור השאילתה לבין חלק מהווקטורים במערך הנתונים. כדי לעשות את זה, Cloud SQL מארגן את הנתונים באשכולות או במחיצות, ואז מתמקד בחיפוש באשכולות שהכי קרובים לשאילתה. כדי לבצע חיפושי ANN, צריך אינדקסים של וקטורים. האינדקסים האלה נותנים עדיפות למהירות החיפוש על פני שליפה מושלמת. ב-Cloud SQL, סוג האינדקס TREE_SQ משמש לחיפושי ANN.
כדי לבצע חיפוש ANN, משתמשים בפונקציה approx_distance עם אפשרות למדידת מרחק. אתם משתמשים ב-approx_distance ברשימה ORDER BY או SELECT, ומותר להשתמש בסעיף LIMIT כדי להגביל את תוצאות החיפוש. אפשר גם להוסיף משפט WHERE כדי לבצע סינון לאחר החיפוש של תוצאות החיפוש.
אם אתם רוצים יותר שליטה על מספר התוצאות שמוחזרות כשמבצעים חיפוש ANN עם מסננים, אתם יכולים להשתמש בסינון איטרטיבי. בעזרת סינון איטרטיבי, שאילתת החיפוש יכולה להחזיר יותר תוצאות חיפוש על ידי סריקה של חלק גדול יותר מאינדקס הווקטורים עד למציאת המספר המועדף של השכנים.
כדי להפעיל סינון איטרטיבי לשאילתת החיפוש, מגדירים את הדגל cloudsql_vector_iterative_filtering לערך ON ברמת הסשן ללקוחות ספציפיים, או ברמה הגלובלית לכל הלקוחות שמתחברים למכונה.
מידע נוסף זמין במאמר חיפוש השכנים הקרובים ביותר (ANN).
יש מקרים שבהם חיפוש ANN חוזר לחיפוש KNN. מידע נוסף זמין במאמר בדיקת סטטוס החלופה לחיפושי ANN.
ההבדלים בתמיכה בווקטורים בגרסאות של Cloud SQL ל-MySQL
ב-Cloud SQL ל-MySQL יש תמיכה בחיפוש וקטורי בגרסה 8.0.36 ואילך. החל מגרסה 9.7 של Cloud SQL ל-MySQL, שינינו יכולות ספציפיות של חיפוש וקטורי ב-Cloud SQL כדי לשלב אותן טוב יותר עם פונקציות האחסון והתמיכה בווקטורים שפותחו על ידי הקהילה, שהוצגו בגרסה 9.0 של MySQL שפותחה על ידי הקהילה.
בטבלה הבאה מוצגת השוואה בין גרסאות של Cloud SQL ל-MySQL, שמראה איך ההבדלים בגרסאות יכולים להשפיע על השימוש בחיפוש וקטורי ב-Cloud ל-MySQL.
| אזור התמיכה | Cloud SQL ל-MySQL בגרסה 8.4 ומטה | Cloud SQL ל-MySQL מגרסה 9.7 ואילך |
|---|---|---|
| הפעלת וקטורים | כדי להוסיף הטמעות וקטורים למסד הנתונים של MySQL ולהשתמש בחיפוש וקטורי, צריך להגדיר את הדגל cloudsql_vector לערך on במכונה של Cloud SQL.
|
כדי ליצור אינדקסים של וקטורים ולבצע חיפוש ANN, צריך להגדיר את הדגל cloudsql_vector לערך on. |
| עמודות של הטמעת וקטורים בטבלה | בטבלה יכולה להיות רק עמודה אחת של הטמעת וקטורים. | אפשר להוסיף רק עמודה אחת של הטמעת וקטורים לכל טבלה רק אם יוצרים אינדקס בטבלה. אם לא יוצרים אינדקס בטבלה, היא יכולה להכיל כמה עמודות של הטמעת וקטורים. |
שימוש ב-COMMENT וב-CONSTRAINT לזיהוי עמודות של הטמעת וקטורים
|
כדי להבדיל בין עמודת הטמעת הווקטורים לעמודות אחרות, Cloud SQL מוסיף לעמודה הערה מיוחדת של COMMENT וכלל של CONSTRAINT.
האילוץ נדרש לאימות הקלט, וההערה של עמודת הטמעת הווקטורים מוצגת כתגובה. אי אפשר לשנות או למחוק את ההערה או את האילוץ.
|
ההערה COMMENT והכלל CONSTRAINT לא משמשים יותר לזיהוי עמודות של הטמעת וקטורים ב-Cloud SQL ל-MySQL 9.7.
|
| מגבלת המאפיינים | הטמעת וקטורים מוגבלת ל-16,000 מאפיינים, ואין לה ערך ברירת מחדל. | הטמעת וקטורים מוגבלת ל-16,383 מאפיינים, וברירת המחדל היא 2,048. |
| פורמט אחסון וקטורי |
פורמט VARBINARY
|
פורמט אחסון מבוסס-קהילה |
| תחביר להצהרה על סוג הנתונים של וקטור |
VECTOR(VECTOR_DIMENSIONS)
|
VECTOR(VECTOR_DIMENSIONS)
|
| הבדלים בפונקציות ההמרה | הפלט של הפונקציה vector_to_string מודפס כערך כולו.
|
הפלט של הפונקציה vector_to_string מוצג בכתיב מדעי, שהוא הסטנדרט המקובל בקהילה.
|
מגבלות
אלה המגבלות שחלות על כל הגרסאות של Cloud SQL שתומכות בווקטורים:
- לכל טבלה יכול להיות רק אינדקס וקטורי אחד.
- העמודה של הטמעת הווקטורים לא יכולה להיות עמודה שנוצרה.
- אי אפשר לחלק טבלאות עם עמודות של הטמעת וקטורים ברמת הטבלה.
- מפתחות ראשיים שמשתמשים בסוגי הנתונים
BIT,BINARY,VARBINARY,JSON,BLOB,TEXTאו בנתונים מרחביים לא נתמכים באינדקסים של וקטורים. גם מפתחות ראשיים מורכבים לא יכולים לכלול את הסוגים האלה. - אם יש אינדקס וקטורי, אי אפשר להוסיף אילוץ למפתח הראשי של מסד הנתונים הטבלאי.
- כשיש אינדקס וקטורי בטבלה, יש פעולות DDL שאי אפשר לבצע. מידע נוסף זמין במאמר פעולות DDL שלא נתמכות בטבלאות עם אינדקסים של וקטורים.
ההגבלות הבאות חלות על שאילתות חיפוש וקטורי:
- אפשר להשתמש בפונקציה
approx_distanceרק ברשימה מסוגORDER BYאוSELECT. - אפשר להשתמש בפרדיקטים שכוללים את מסד הנתונים הטבלאי בתנאי
WHEREבשילוב עם ביטוייapprox_distanceברשימהORDER BYאוSELECT. הפרדיקטים של התנאיWHEREמוערכים אחרי שפונקציות הווקטורapprox_distanceמוערכות.