שיטות מומלצות לעיצוב סכימה

בדף הזה מוסבר על עיצוב סכימה ב-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 טבלאות לכל מופע, אבל מומלץ לא ליצור מספר גדול של טבלאות מהסיבות הבאות:

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

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

קבוצות עמודות

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

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

בחירת שמות קצרים למשפחות העמודות. השמות נכללים בנתונים שמועברים בכל בקשה.

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

Columns

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

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

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

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

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

מפתח שורה Fred גבריאל Hiroshi Seo Yoon יעקב
Jose book-club עבודה טניס
סופיה עבודה בית ספר chess-club

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

מפתח שורה חבר מעגל
Jose#1 Fred מועדון-ספרים
Jose#2 גבריאל עבודה
Jose#3 Hiroshi טניס
Sofia#1 Hiroshi עבודה
Sofia#2 Seo Yoon בית ספר
Sofia#3 יעקב chess-club

העיצוב השני של הסכימה גורם לטבלה לגדול הרבה יותר מהר.

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

Rows

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

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

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

אחסון ישויות קשורות בשורות סמוכות,כדי לשפר את יעילות הקריאה.

תאים

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

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

מפתחות שורה

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

  • מפתח שורה
  • קידומת של מפתח שורה
  • טווח השורות שמוגדר על ידי מפתחות השורות של ההתחלה והסיום

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

הקפידו שמקשי השורה יהיו קצרים. מפתח שורה חייב להיות 4KB או פחות. מפתחות ארוכים של שורות תופסים יותר זיכרון ואחסון, ומאריכים את הזמן שלוקח לקבל תשובות מהשרת של Bigtable.

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

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

מפתח שורה לדוגמה

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

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

חשוב ליצור מפתח שורה שמאפשר לאחזר טווח מוגדר היטב של שורות. אחרת, השאילתה תדרוש סריקה של הטבלה, שהיא הרבה יותר איטית מאחזור של שורות ספציפיות.

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

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

העיצוב הזה של מפתח השורה מאפשר לאחזר נתונים באמצעות בקשה אחת עבור:

  • סוג המכשיר
  • שילוב של סוג המכשיר ומזהה המכשיר

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

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

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

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

מפתחות שורה מובנים

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

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

כשמבצעים שאילתה בטבלה באמצעות השיטה ReadRows של Bigtable Data API עם ספריית לקוח של Bigtable, המערכת מתעלמת מסכימות של מפתחות שורות.

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

מפתחות שורות שכדאי להימנע מהם

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

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

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

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

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

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

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

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

ערכים מגובבים (hashed). ביצוע גיבוב (hashing) של מפתח שורה מבטל את היכולת שלכם לנצל את סדר המיון הטבעי של Bigtable, ולכן אי אפשר לאחסן שורות בצורה אופטימלית לשאילתות. מאותה סיבה, ערכי גיבוב מקשים על השימוש בכלי Key Visualizer כדי לפתור בעיות ב-Bigtable. במקום ערכים מגובבים, צריך להשתמש בערכים שקלים לקריאה.

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

תרחישי שימוש מיוחדים

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

נתונים מבוססי-זמן

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

לדוגמה, יכול להיות שהאפליקציה שלכם תתעד נתונים שקשורים לביצועים, כמו שימוש במעבד ובזיכרון, פעם בשנייה עבור הרבה מכונות. מפתח השורה של הנתונים האלה יכול לשלב מזהה של המכונה עם חותמת זמן של הנתונים (לדוגמה, machine_4223421#1425330757685). חשוב לזכור שמפתחות השורה ממוינים בסדר לקסיקוגרפי.

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

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

אפשר לקבל חותמת זמן הפוכה על ידי הפחתת חותמת הזמן מהערך המקסימלי של מספרים שלמים ארוכים בשפת התכנות (ב-Java,‏ java.lang.Long.MAX_VALUE).

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

ריבוי דיירים

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

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

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

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

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

פרטיות

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

מידע נוסף על אופן הטיפול בנתוני השירות זמין בהודעת הפרטיות שלGoogle Cloud.

שמות דומיין

אפשר לאחסן שמות דומיין כנתוני Bigtable.

מגוון רחב של שמות דומיין

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

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

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

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

      drive.google.com
      en.wikipedia.org
      maps.google.com

זה לא רצוי בתרחיש השימוש שבו רוצים לשלוח שאילתה לכל השורות של google.com. לעומת זאת, נניח שיש לנו את אותן שורות, אבל שמות הדומיינים הפוכים:

      com.google.drive
      com.google.maps
      org.wikipedia.en

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

מספר קטן של שמות דומיין

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

אחסון נתונים בפורמט protobuf

כדי לצמצם את עלויות האחסון ולשפר את יעילות הקריאה והכתיבה, אפשר לקבץ נתונים קשורים בהודעה של protocol buffer (protobuf) ולאחסן אותה בעמודה אחת, במקום לאחסן כל שדה בעמודה נפרדת. אם בדרך כלל קוראים קבוצה של שדות ביחד, יעיל יותר לאחסן אותם בעמודה אחת כערך אחד, כי קריאה של עמודה אחת מהירה יותר מקריאה של הרבה עמודות נפרדות. אם מאחסנים נתונים כהודעות protobuf, אפשר לנצל את התכונות הבאות של Bigtable:

  • שימוש ב-protocol buffers לאחסון מבני נתונים גמישים מפחית את עלויות האחסון, כי הנתונים נשארים במקום ולא מתבצעת כפילות.
  • העלאת סכימת ה-protobuf ל-Bigtable בחבילות סכימות מאפשרת שאילתות בצד השרת. חבילת הסכימה מאפשרת ל-Bigtable להבין ולנתח את המבנה של הנתונים הסדרתיים במהלך ביצוע השאילתה.
  • שימוש ב-GoogleSQL כדי לשלוח שאילתות ולסנן שדות נפרדים בהודעות protobuf ישירות ב-Bigtable הוא מהיר ויעיל. באמצעות ביטול הסריאליזציה של הנתונים בצד השרת, אפשר להריץ שאילתות והשלכות גרנולריות בלי להעביר את אובייקט ה-protobuf כולו ללקוח.
  • שימוש בטבלאות חיצוניות של BigQuery כדי לנתח נתוני protobuf שמאוחסנים ב-Bigtable מאפשר לכם לפשט את הניתוח.

מידע נוסף זמין במאמר בנושא יצירה וניהול של סכימות protobuf.

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