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

‫MySQL | PostgreSQL | SQL Server

כדי להשתמש בגרסת ה-GA של חיפוש וקטורי, גרסת התחזוקה של המופע צריכה להיות גרסה MYSQL_8_0_version.R20241208.01_00 ומעלה, כאשר version הוא מספר הגרסה המשנית. במאמר תחזוקה בשירות עצמי מוסבר איך לשדרג את המופע לגרסה חדשה יותר שתומכת בהטמעות וקטוריות של GA.

במאמר שימוש בהטמעות וקטורים (גרסת Preview) מוסבר על התחביר וההתנהגות של הטמעות וקטורים בגרסת ה-Public Preview של התכונה הזו.

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

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

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

הגדרת הקצאת זיכרון לאינדקסים של וקטורים

הדגל של מסד הנתונים cloudsql_vector_max_mem_size קובע כמה זיכרון מכונת Cloud SQL מקצה לאינדקסים של וקטורים. זהו דגל סטטי שנדרשת הפעלה מחדש של המכונה כדי להשתמש בו. הזיכרון הזה משמש לשתי מטרות עיקריות:

אחסון המבנה של אינדקס הווקטורים: החלק שאינו עלה של אינדקס הווקטורים (TREE_MEMORY) נמצא בזיכרון הזה. הגודל המשוער של העץ הזה תלוי במספר צמתי העלה (num_leaves) ובממדים של הווקטורים:
```
 Approximate TREE_MEMORY = num_leaves * vector dimensions * 4 * 2
```
לדוגמה, לאינדקס עם 1,000 עלים ו-768 מימדים יהיה ערך משוער של TREE_MEMORY בגודל ‎1,000 * 768 * 4 * 2 או 6,144,000 בייט. אפשר גם לבדוק את TREE_MEMORY בפועל באמצעות הטבלה information_schema.innodb_vector_indexes. ‫Cloud SQL מנהל את הזיכרון הזה. אין צורך להקצות מקום לכל אינדקס וקטורי בו-זמנית, כי אינדקסים לא פעילים נפרקים כדי לפנות מקום לבקשות אחרות.
זיכרון ליצירת אינדקס (נתוני אימון): במהלך יצירת אינדקס וקטורי, נדרש זיכרון לעיבוד מדגם של הנתונים מהטבלה הבסיסית כדי לבנות את האינדקס. הזיכרון הזה נמצא בשימוש רק במהלך תהליך יצירת האינדקס, ומתפנה לאחר מכן. הגודל המשוער של הזיכרון שנדרש לאימון הוא:
```
 approximate_training_memory = num_rows in base table * 0.1 * 4 * vector dimensions
```
לדוגמה, אם יש לכם טבלה עם 1,000,000 שורות ו-768 מאפיינים, הערך של training_memory יהיה ‎1,000,000 * 0.1 * 768 * 4 או 307,200,000 בייטים. רק 10% מהנתונים בטבלת הבסיס נדגמים כדי לחשב את מרכזי הכובד של העץ.

כשמפעילים את הדגל cloudsql_vector, מערכת Cloud SQL מגדירה באופן אוטומטי ערך ברירת מחדל של cloudsql_vector_max_mem_size על סמך גודל המכונה הווירטואלית. בדרך כלל ברירת המחדל הזו מספיקה לעומסי עבודה טיפוסיים. ‫Cloud SQL מקטין את הערך של הדגל innodb_buffer_pool_size כדי להקצות את הזיכרון הזה. ערך ברירת המחדל המקסימלי של cloudsql_vector_max_mem_size הוא 16GB. אם אתם צריכים לשנות את גודל הזיכרון, אתם יכולים לשנות את cloudsql_vector_max_mem_size באופן דינמי בהתאם לשימוש שלכם באינדקס הווקטורים.

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

ערכים של `cloudsql_vector_max_mem_size`

גודל ה-VM	cloudsql_vector_max_mem_size
‎4GB	‫194MB
‫8GB	‫515MB
‫16GB	‫1.2GB
32GB	‫2.56GB
‫64GB	‫5.12GB
‫128GB	‫10.24GB
‫256GB ומעלה	‫16GB

טווח הזיכרון שמוקצה לאינדקס הווקטורי הוא:

מינימום 128MB
‫10% ממאגר הנתונים הזמני
עד 16GB

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

מידע על מעקב אחר הגודל של אינדקס וקטורי זמין במאמר מעקב אחר אינדקסים וקטוריים.

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

gcloud sql instances patch INSTANCE_NAME \
 --database-flags= cloudsql_vector_max_mem_size=NEW_MEMORY_VALUE;

מחליפים את מה שכתוב בשדות הבאים:

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

השינוי הזה ייכנס לתוקף מיד אחרי הפעלה מחדש של מסד הנתונים.

יצירת אינדקס וקטורי

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

‫CREATE VECTOR INDEXstatement, תוסף של Cloud SQL לתחביר הסטנדרטי של MySQL.
הצהרת ALTER TABLE עם תוסף הסעיף ADD VECTOR INDEX של Cloud SQL. אי אפשר להריץ את ההצהרה הזו בו-זמנית עם הצהרות DDL אחרות בטבלה.

כדי ליצור אינדקס וקטורי באמצעות CREATE VECTOR INDEX, משתמשים בתחביר הבא:

CREATE
  VECTOR INDEX INDEX_NAME
ON TABLE_NAME(COLUMN_NAME)
USING
  SCANN[QUANTIZER = SQ8]
    DISTANCE_MEASURE
  = L2_SQUARED | COSINE | DOT_PRODUCT[NUM_LEAVES = INT_VALUE { '</var>' }}];

אלה האפשרויות של האינדקס:

‫USING SCANN: אופציונלי. מציין את סוג האינדקס שבו צריך להשתמש. ‫SCANN הוא הערך הנתמך היחיד.
‫QUANTIZER: אופציונלי. מיפוי של וקטור עם הרבה ממדים לייצוג דחוס. הערך הנתמך היחיד הוא SQ8.
‫DISTANCE_MEASURE: חובה. מציינת נוסחה מתמטית לחישוב הדמיון בין שני וקטורים. בפרמטר הזה צריך להגדיר את אותו מרחק שהגדרתם באפשרויות החיפוש approx_distance. הליטרלים הנתמכים הם:
- L2_SQUARED
- COSINE
- DOT_PRODUCT
‫NUM_LEAVES: אופציונלי. מציינים כמה מחיצות (ענפים) ליצור. כדאי לשנות את ההגדרה הזו מברירת המחדל רק אם אתם מבינים היטב את החיפוש ברשתות עצביות מלאכותיות ואת מערך הנתונים שלכם. המספר שצוין לא יכול להיות גדול ממספר ההטמעות בטבלת הבסיס.

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

CREATE
  VECTOR INDEX vectorIndex
ON dbname.books(embeddings) DISTANCE_MEASURE = L2_SQUARED;

בזמן שההצהרה CREATE פועלת, טבלת הבסיס עוברת למצב קריאה בלבד ולא ניתן לבצע פעולות DML בטבלת הבסיס.

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

ALTER TABLE tbl_name
  ADD VECTOR INDEX index_name(key_part)[index_option];

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

ALTER TABLE t1 ADD VECTOR INDEX index1(j)
USING SCANN QUANTIZER = SQ8 DISTANCE_MEASURE = l2_squared NUM_LEAVES = 10;

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

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

פרמטר	תיאור	ברירת מחדל	היקף	השפעה
`cloudsql_vector_max_mem_size`	הזיכרון שהוקצה לאימון האינדקס.	משתנה	Instance	זיכרון לא מספיק עלול לגרום לכשלים בבנייה. מידע נוסף מופיע במאמר בנושא הגדרת הקצאת זיכרון לאינדקסים של וקטורים.
`innodb_ddl_threads`	רמת המקביליות של אימון האינדקס ובנייתו.	4	אירוע	ערכים גבוהים יותר מקצרים את משך זמן של תהליך build, אבל מגדילים את עומס המעבד. הערך הזה צריך להיות מספר המעבדים שאפשר להקצות בלי להשפיע לרעה על פעולות מסד הנתונים.

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

הסרת אינדקס וקטורי

כדי להסיר אינדקס וקטורי, משתמשים בהצהרות SQL‏ DROP INDEX או ALTER TABLE עם שם האינדקס שרוצים להסיר, כמו בדוגמה הבאה:

DROP INDEX index_name ON books;

ALTER TABLE table_name
DROP INDEX index_name;

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

ב-Cloud SQL יש טבלאות של סכימת מידע עם נתונים בזמן אמת על אינדקסים של וקטורים שנטענו בזיכרון שלו:

information_schema.innodb_vector_indexes מציגה רשימה של כל האינדקסים של הווקטורים שנפתחים בזיכרון אחרי הפעלה מחדש.
‫information_schema.innodb_all_vector_indexes מציג את כל אינדקסים של וקטורים שקיימים במופע (גם אם הם עדיין לא נפתחו בזיכרון).
‫information_schema.innodb_vector_indexes_memory מספק מידע על השימוש הכולל בזיכרון של אינדקסים וקטוריים במופע.

מידע מפורט יותר זמין במאמר בנושא סכימת מידע.

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

SELECT * FROM information_schema.innodb_vector_indexes \ G;

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

 INDEX_NAME: t1_vec_index
 TABLE_NAME: test.t1
 INDEX_TYPE: TREE_SQ
 DIMENSION: 3
 DIST_MEASURE: COSINE
 STATUS: Ready
 STATE: INDEX_READY_TO_USE
 NUM_LEAVES: 10
 NUM_LEAVES_TO_SEARCH: 10
 QUERIES: 1
 MUTATIONS: 1
 TREE_MEMORY: 443