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

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

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

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

מפעילים את cloudsql_vector בדגל מסד הנתונים במכונה של Cloud SQL.

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

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

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

  1. אחסון המבנה של אינדקס הווקטורים: החלק שאינו עלה של אינדקס הווקטורים (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 מנהל את הזיכרון הזה. אין צורך להקצות מקום לכל האינדקסים של הווקטורים בו-זמנית, כי אינדקסים לא פעילים נפרקים כדי לפנות מקום לבקשות אחרות.

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

     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 ערכים

גודל המכונה הווירטואלית 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 ];

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

  • ‫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;

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

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

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

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

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

כדי להסיר אינדקס וקטורי, משתמשים בהצהרות 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

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

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

  • אחרי פעולות משמעותיות של שפת טיפול בנתונים (DML), מומלץ לבנות מחדש את האינדקס.
  • בדרך כלל, אפשר לאפשר ל-Cloud SQL לחשב את מספר העלים או הקונטיינרים של ההטמעות שבהם צריך להשתמש. מספר העלים קובע לכמה מחיצות מחולק אינדקס הווקטור. אם יש לכם תרחיש שימוש שבו אתם רוצים לציין את מספר העלים, מומלץ להשתמש ב-100 וקטורים לפחות לכל עלה כדי לקבל את התוצאות הטובות ביותר. בהקשר של חיפוש וקטורי, recall (החזרה) מתייחס לאחוז הווקטורים שהאינדקס מחזיר שהם השכנים הקרובים האמיתיים.

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