שיטות מומלצות לעיצוב סכימה
בדף הזה מוסבר על עיצוב סכימה ב-Bigtable. לפני שקוראים את הדף הזה, כדאי לעיין בסקירה הכללית של Bigtable. בדף הזה מפורטים הנושאים הבאים:
- מושגים כלליים: מושגים בסיסיים שכדאי לזכור כשמעצבים את הסכימה.
- שיטות מומלצות: הנחיות עיצוב שרלוונטיות לרוב תרחישי השימוש, מחולקות לפי רכיב בטבלה.
- תרחישים מיוחדים לדוגמה: המלצות לתרחישים ספציפיים לדוגמה ולדפוסי נתונים.
מושגים כלליים
תכנון סכימה ב-Bigtable שונה מתכנון סכימה למסד נתונים רלציוני. סכימת Bigtable מוגדרת על ידי לוגיקת האפליקציה ולא על ידי אובייקט או קובץ של הגדרת סכימה. אפשר להוסיף משפחות עמודות לטבלה כשיוצרים או מעדכנים את הטבלה, אבל העמודות ודפוסי מפתחות השורות מוגדרים לפי הנתונים שכותבים בטבלה.
ב-Bigtable, סכימה היא תוכנית או מודל של טבלה, כולל המבנה של רכיבי הטבלה הבאים:
- מפתחות שורה
- משפחות עמודות, כולל מדיניות איסוף האשפה שלהן
- Columns
ב-Bigtable, עיצוב הסכימה מבוסס בעיקר על השאילתות, או בקשות הקריאה, שאתם מתכננים לשלוח לטבלה. קריאת טווח שורות היא הדרך הכי מהירה לקרוא את נתוני Bigtable, ולכן ההמלצות בדף הזה נועדו לעזור לכם לבצע אופטימיזציה לקריאות של טווח שורות. ברוב המקרים, המשמעות היא שליחת שאילתה שמבוססת על קידומות של מפתחות שורה.
שיקול משני הוא הימנעות מנקודות חמות – כדי למנוע נקודות חמות, צריך לשקול דפוסי כתיבה ואיך אפשר להימנע מגישה למרחב קטן של מפתחות בפרק זמן קצר.
המושגים הכלליים הבאים רלוונטיים לעיצוב סכימת Bigtable:
- Bigtable הוא מאגר של צמדי מפתח/ערך, ולא מאגר יחסי. היא לא תומכת בצירופים, והתמיכה בעסקאות מוגבלת לשורה אחת בלבד.
- לכל טבלה יש אינדקס: מפתח השורה. כל מפתח שורה צריך להיות ייחודי. כדי ליצור אינדקס משני, משתמשים בתצוגה חומרית רציפה. מידע נוסף זמין במאמר יצירת אינדקס משני אסינכרוני.
- מפתחות השורות ממיינים את השורות בסדר לקסיקוגרפי מהנמוך לגבוה ביותר של מחרוזת הבייטים. הסדר הזה הוא big-endian (לפעמים נקרא סדר בייטים ברשת), שהוא המקבילה הבינארית של סדר אלפביתי.
- משפחות העמודות לא מאוחסנות בסדר מסוים.
- העמודות מקובצות לפי משפחת עמודות וממוינות בסדר לקסיקוגרפי בתוך משפחת העמודות. לדוגמה, במשפחת עמודות בשם
SysMonitorעם מזהי עמודותProcessName,User,%CPU,ID,Memory,DiskReadו-Priority, Bigtable מאחסן את העמודות בסדר הזה:
| SysMonitor | ||||||
|---|---|---|---|---|---|---|
| %CPU | DiskRead | מזהה | זיכרון | עדיפות | ProcessName | משתמש |
- הצומת של שורה ועמודה יכול להכיל כמה תאים עם חותמת זמן. כל תא מכיל גרסה ייחודית של הנתונים עם חותמת זמן עבור השורה והעמודה האלה.
- משפחות עמודות של צבירה מכילות תאים של צבירה. אפשר ליצור משפחות של עמודות שמכילות רק תאים של נתונים מצטברים. פונקציית צבירה מאפשרת לכם למזג נתונים חדשים עם נתונים שכבר נמצאים בתא.
- כל הפעולות הן אטומיות ברמת השורה. פעולה משפיעה על שורה שלמה או לא משפיעה על אף חלק בשורה.
- באופן אידיאלי, פעולות הקריאה והכתיבה צריכות להתחלק באופן שווה בין השורות בטבלה.
- טבלאות Bigtable הן דלילות. עמודה לא תופסת מקום בשורה שלא נעשה בה שימוש בעמודה.
שיטות מומלצות
סכימה טובה מובילה לביצועים ולמדרגיות מצוינים, וסכימה שתכננו בצורה לא טובה עלולה להוביל למערכת עם ביצועים נמוכים. כל תרחיש שימוש הוא שונה ודורש עיצוב משלו, אבל השיטות המומלצות הבאות רלוונטיות לרוב תרחישי השימוש. החריגים מצוינים.
הקטעים הבאים מתארים את השיטות המומלצות לעיצוב סכימה, החל מרמת הטבלה ועד לרמת מפתח השורה:
צריך לתכנן את כל רכיבי הטבלה, במיוחד את מפתחות השורות, בהתאם לבקשות הקריאה המתוכננות. במאמר בנושא מכסות ומגבלות מפורטות מגבלות הגודל המומלצות והקשיחות לכל רכיבי הטבלה.
מכיוון שכל הטבלאות במופע מאוחסנות באותם טאבלטים, עיצוב סכימה שיוצר נקודות חמות בטבלה אחת יכול להשפיע על זמן האחזור של טבלאות אחרות באותו מופע. נקודות חמות נוצרות כתוצאה מגישה תכופה לחלק אחד של הטבלה בפרק זמן קצר.
Tables
אחסון מערכי נתונים עם סכימות דומות באותה טבלה, במקום בטבלאות נפרדות.
במערכות אחרות של מסדי נתונים, יכול להיות שתבחרו לאחסן נתונים בכמה טבלאות, בהתאם לנושא ולמספר העמודות. לעומת זאת, ב-Bigtable, בדרך כלל עדיף לאחסן את כל הנתונים בטבלה אחת. אתם יכולים להקצות קידומת ייחודית למפתח שורה לשימוש בכל מערך נתונים, כך ש-Bigtable יאחסן את הנתונים הקשורים בטווח רציף של שורות שאפשר להריץ עליהן שאילתות לפי קידומת מפתח השורה.
ב-Bigtable יש מגבלה של 1,000 טבלאות לכל מופע, אבל מומלץ לא ליצור מספר גדול של טבלאות מהסיבות הבאות:
- שליחת בקשות להרבה טבלאות שונות יכולה להגדיל את התקורה של החיבור לקצה העורפי, וכתוצאה מכך להגדיל את חביון הזנב.
- יצירת טבלאות נוספות לא משפרת את איזון העומסים ועשויה להגדיל את תקורה הניהול.
יכול להיות שתרצו להשתמש בטבלה נפרדת לתרחיש שימוש אחר שדורש סכימה שונה, אבל לא מומלץ להשתמש בטבלאות נפרדות לנתונים דומים. לדוגמה, לא כדאי ליצור טבלה חדשה כי השנה התחלפה או כי יש לכם לקוח חדש.