עיצוב סכימה

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

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

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

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

איסוף מידע

  1. זיהוי הנתונים שאתם מתכננים לאחסן ב-Bigtable. דוגמאות לשאלות שאפשר לשאול:
    • באיזה פורמט הנתונים? הפורמטים האפשריים כוללים raw bytes, מחרוזות, protobufs ו-json.
    • מה נחשב לישות בנתונים שלכם? לדוגמה, האם אתם מאחסנים צפיות בדפים, מחירי מניות, מיקומי מודעות, מדידות של מכשירים או סוג אחר של ישות? ממה מורכבות הישויות?
    • האם הנתונים מבוססים על זמן?
  2. זיהוי ודירוג של השאילתות שבהן אתם משתמשים כדי לקבל את הנתונים שאתם צריכים. כשחושבים על הישויות שרוצים לאחסן, צריך לחשוב על האופן שבו רוצים למיין ולקבץ את הנתונים כשמשתמשים בהם. יכול להיות שעיצוב הסכימה לא יספק את כל השאילתות, אבל באופן אידיאלי הוא יספק את השאילתות הכי חשובות או הכי נפוצות. דוגמאות לשאילתות:
    • ערכי טמפרטורה של אובייקטים ב-IoT שנמדדו במהלך חודש.
    • מספר הצפיות במודעה מדי יום מכתובת IP מסוימת.
    • המיקום העדכני ביותר של מכשיר נייד.
    • כל האירועים באפליקציה ליום לכל משתמש.

עיצוב

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

אם אתם מתכננים להריץ שאילתות בטבלה באמצעות SQL במקום באמצעות השיטה ReadRows של Bigtable Data API, כדאי לעיין במסמכים הבאים:

אם רוצים להשתמש ב-SQL כדי לשלוח שאילתות לתצוגות של הטבלה וגם לטבלה עצמה, כדאי לעיין במאמר טבלאות ותצוגות.

בדיקה

  1. יוצרים טבלה באמצעות משפחות העמודות ומסווגי העמודות שיצרתם עבור הסכימה.
  2. טוענים לטבלה לפחות 30GB של נתוני בדיקה באמצעות מפתחות שורות שזיהיתם בטיוטת התוכנית. השימוש בנפח האחסון בכל צומת צריך להיות מתחת למגבלות השימוש בנפח האחסון לכל צומת.
  3. מריצים בדיקת עומס כבד למשך כמה דקות. בשלב הזה, מערכת Bigtable מקבלת הזדמנות לאזן את הנתונים בין הצמתים על סמך דפוסי הגישה שהיא מזהה.
  4. מריצים סימולציה של שעה של פעולות הקריאה והכתיבה שבדרך כלל שולחים לטבלה.

  5. בודקים את תוצאות הסימולציה באמצעות Key Visualizer ו-Cloud Monitoring.

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

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

צמצום

  1. משנים את תכנון הסכימה לפי הצורך, על סמך מה שלמדתם באמצעות Key Visualizer. לדוגמה:
    • אם אתם רואים סימנים לבעיית hotspotting, כדאי להשתמש במפתחות שורות שונים.
    • אם אתם מבחינים בהשהיה, כדאי לבדוק אם השורות חורגות מהמגבלה של 100MB לכל שורה.
    • אם אתם מגלים שאתם צריכים להשתמש במסננים כדי לקבל את הנתונים שאתם צריכים, כדאי לשקול לנרמל את הנתונים באופן שיאפשר קריאות פשוטות יותר (ומהירות יותר): קריאה של שורה אחת או של טווחים של שורות לפי מפתח שורה.
  2. אחרי שמשנים את הסכימה, בודקים את התוצאות שוב.
  3. ממשיכים לשנות את עיצוב הסכימה ולבדוק אותה עד שבדיקה ב-Key Visualizer מראה שעיצוב הסכימה הוא אופטימלי.

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