יצירת אינדקס משני אסינכרוני

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

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

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

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

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

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

מתי כדאי להשתמש באינדקס משני אסינכרוני

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

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

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

  • הצפנה מחדש של הנתונים: אם אתם צריכים להריץ שאילתות על הנתונים באמצעות מפתח שונה ממפתחות השורות של טבלת המקור, אתם יכולים ליצור תצוגה חומרית רציפה עם המפתח החלופי ולהריץ שאילתות על התצוגה הזו.
  • סינון נתונים: אם רוצים לסנן את טבלת המקור ולאכלס רק שורות נתונים ספציפיות באינדקס המשני האסינכרוני, צריך לספק פסקה WHERE בשאילתת ה-SQL שמגדירה את התצוגה.
  • מפתחות מאפיינים: אם אתם צריכים לשלוח שאילתה לנתונים על סמך מאפיין שאינו מפתח, כמו מסווג עמודה או ערך, אתם יכולים לכלול אותו בסעיף ORDER BY.

מידע על אינדקסים משניים אסינכרוניים

כדי להשתמש בתצוגה חומרית רציפה ב-Bigtable בתור אינדקס משני אסינכרוני, צריך לעמוד בדרישות הבאות:

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

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

  • כל עמודה בפסוקית ORDER BY חייבת להיכלל גם בפסוקית SELECT.
  • אחרי שמגדירים את האינדקס המשני האסינכרוני, האפליקציה צריכה להיות מסוגלת לבחור בין שאילתת טבלת המקור לבין התצוגה המגולמת שמייצגת את האינדקס המשני האסינכרוני.
  • האפליקציות לא כותבות ישירות לאינדקס, שמסונכרן באופן רציף עם טבלת המקור. תמיד לכתוב לטבלת המקור.
  • האינדקס המשני האסינכרוני הוא עקבי בסופו של דבר. הנתונים נכתבים קודם לטבלת המקור ואז מומרים לפורמט של האינדקס המשני האסינכרוני.
  • מומלץ ליצור אינדקס מכסה. מידע נוסף זמין בקטע אינדקסים מכסים במאמר הזה.
  • הסעיף ORDER BY צריך להכיל את מפתח השורה של טבלת המקור ללא שינוי, וכל הנתונים צריכים להיות ממוינים בסדר עולה. מפתח השורה בטבלת המקור תמיד מוקרן לתצוגה החומרית, אבל אפשר לשלב אותו עם מאפיינים אחרים.
  • העמודות בסעיף ORDER BY הופכות לחלק ממפתח השורה המובנה של האינדקס המשני האסינכרוני. כל שאר העמודות שנבחרו הופכות לערכים של עמודות לא מרכזיות באינדקס המשני האסינכרוני. אם ממירים ערך בסעיף ORDER BY לסוג נתונים ספציפי של GoogleSQL for Bigtable, סוג הנתונים נשמר במפתח השורה המובנה של האינדקס המשני האסינכרוני.

אינדקסים מכסים

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

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

הגדרת אינדקס משני אסינכרוני

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

בדוגמה הבאה, שאילתת ה-SQL יוצרת אינדקס משני אסינכרוני שמאפשר לשלוח שאילתות לגבי נתוני אינטראקציות של משתמשים. הפסקה ORDER BY מגדירה את מפתח השורה המובנה של האינדקס המשני האסינכרוני, באמצעות שילוב של מספר הטלפון של המשתמש, מזהה המשתמש וכתובת האימייל. היא גם מקצה את השם interactions לקבוצת העמודות activity:

SELECT
  user['phone'] AS phone,
  CAST(user['id'] AS INT64) AS user_id,
  _key AS email,
  activity AS interactions
FROM CLICKS_TABLE
ORDER BY 1, 2, 3;

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

שורה בטבלת המקור שורה באינדקס משני אסינכרוני
מפתח שורה:
_key: user1@example.com


 מאפיינים:
user: {id: "123", phone: "555-123-4567"}
activity: {action: "CLICKED_PRODUCT_A"}
מפתח שורה מובנה:
phone: 555-123-4567
user_id: 123
email: user1@example.com

מאפיין:
interactions: {action: "CLICKED_PRODUCT_A"}
מפתח שורה:
_key: user2@example.com


 מאפיינים:
user: {id: "456", phone: "555-987-6543"}
activity: {action: "VIEWED_PRODUCT_B"}
מפתח שורה מובנה:
phone: 555-987-6543
user_id: 456
email: user2@example.com

מאפיין:
interactions: {action: "VIEWED_PRODUCT_B"}
מפתח שורה:
_key: user3@example.com


 מאפיינים:
user: {id: "1000", phone: "555-111-2222"}
activity: {action: "ADDED_TO_CART_PRODUCT_C"}
מפתח שורה מובנה:
phone: 555-111-2222
user_id: 1000
email: user3@example.com

מאפיין:
interactions: {action: "ADDED_TO_CART_PRODUCT_C"}

מגבלות

  • כדי לקרוא את מפתח הפלט, שהוא מפתח האינדקס המשני האסינכרוני, אפשר להשתמש רק בשאילתות SQL.

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