חיפוש וקטורי שעבר אופטימיזציה לאחסון

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

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

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

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

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

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

הפשרות שצריך לעשות כדי לשפר את הביצועים

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

  • זמן האחזור של השאילתות עלה: זמן האחזור של השאילתות גבוה יותר מעט ברמת היזכרות נתונה.

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

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

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

בדוגמה הבאה מוצג קובץ ה-JSON שנדרש כדי ליצור אינדקס חדש של סטרימינג שעבר אופטימיזציה לאחסון.

{
  "displayName": "my-storage-optimized-index",
  "description": "An index configured to prioritize storage over performance.",
  "metadata": {
    "contentsDeltaUri": "gs://your-bucket/source-data/",
    "config": {
      "dimensions": 100,
      "approximateNeighborsCount": 150,
      "distanceMeasureType": "DOT_PRODUCT_DISTANCE",
      "shardSize": "SHARD_SIZE_SO_DYNAMIC"
    }
  },
  "indexUpdateMethod": "STREAM_UPDATE"
}

בדוגמה, הערך של shardSize מוגדר ל-SHARD_SIZE_SO_DYNAMIC, מה שמורה ל-Vector Search ליצור אינדקס צפוף יותר. כך כל שבר יכול להכיל הרבה יותר נקודות נתונים, ולכן נדרש מספר קטן יותר של שברים עבור מערך הנתונים. שדות אחרים, כמו dimensions ו-distanceMeasureType, מוגדרים בהתאם לצרכים שלכם.

נקודות קצה

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

פריסת אינדקס

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

{
  "deployedIndex": {
    "id": "PROJECT_UNIQUE_ID_NAME",
    "index": "projects/PROJECT_ID/locations/LOCATION/indexes/INDEX_ID",
    "displayName": "INDEX_DISPLAY_NAME",
    "deploymentTier": "STORAGE"
  }
}

הגדרה של deploymentTier ל-STORAGE פורסת את האינדקס שעבר אופטימיזציה לאחסון עם displayName שצוין לנקודת קצה.

אפשר גם לציין את מספר הרפליקות המינימלי (minReplicaCount) ואת מספר הרפליקות המקסימלי (minReplicaCount) כדי לשלוט במספר הרפליקות של המכונות שיוגדרו לפריסה. אין תמיכה בהגדרת סוג המכונה (machineType).

מה השלב הבא?