‫Bigtable למשתמשי Aerospike

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

כדי לעזור לכם להתחיל לעבוד עם Bigtable ו-Aerospike, המסמך הזה:

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

מידע על תהליך ההעברה ועל כלים בקוד פתוח שאפשר להשתמש בהם כדי להשלים את ההעברה זמין במאמר העברה מ-Aerospike ל-Bigtable.

השוואה בין מונחים

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

‫Aerospike מאחסן נתונים ברשומות. כל רשומה מכילה סל אחד או יותר עם שם, וגם מטא-נתונים כמו גודל הרשומה (בבייטים), זמן החיים (TTL) וזמן העדכון האחרון (LUT).

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

מידע נוסף זמין במאמר מודל האחסון של Bigtable.

בטבלה הבאה מפורטים מושגים משותפים והטרמינולוגיה המתאימה שבה משתמש כל מוצר:

Aerospike Bigtable
אין פריט תואם ישירות. מופע: קבוצה מנוהלת של אשכולות באזורים או בתחומים שונים של Google Cloud זמינות, שמתבצעת ביניהם שכפול וניתוב של חיבורים.
אשכול: פריסת Aerospike שמורכבת מאוסף של צמתים. קלאסטר: קבוצה של צמתים באותם אזורים גיאוגרפיים Google Cloud .
צומת: שרת שמספק מחשוב ובעל אחסון משלו. ‫node: שרת שמספק רק יכולת חישוב. האחסון מתבצע על ידי Colossus, מערכת קבצים מבוזרת נפרדת.
‫namespace: מאחסן פרמטרים כמו TTL או סוג האחסון. בתוך מרחב שמות, הנתונים מחולקים לקבוצות ולרשומות. ‫table: המקבילה הקרובה ביותר למרחב שמות של Aerospike. חלק מהפרמטרים מוגדרים לכל הטבלאות ברמת האשכול. אפשר להגדיר רמת שליטה מדויקת יותר ברמת הטבלה או ברמת קבוצת העמודות.
‫set: משמש לחלוקה לוגית של רשומות ופרמטרים כמו TTL וגודל מכסה. המפתחות צריכים להיות ייחודיים בתוך קבוצה. אין פריט תואם ישירות.
אין פריט תואם ישירות. ‫table: משאב ברמת המופע שמשוכפל אוטומטית לכל אשכול. טבלה מכילה קבוצה של ערכים שמזוהים על ידי מפתחות שורה ייחודיים. הטבלאות דלילות, כלומר הן לא תופסות מקום נוסף כדי לאחסן עמודות שלא מכילות ערכים.
אין פריט תואם ישירות. טבלה: טווח רציף של שורות שמאוחסנות יחד. ‫Bigtable משתמש בטבלאות כדי לאזן את העומס על ידי הקצאת הטבלאות לצמתים. הגבולות של הטאבלטים הם דינמיים – הם יכולים להתפצל או להתמזג עם הזמן.
רשומה: קבוצה של תאים בעלי שמות שמשמשים לאחסון נתונים. הגודל המקסימלי הוא 8 MB. שורה: קבוצת ערכים שמזוהים לפי קבוצת עמודות, מגדיר העמודה וחותמת זמן. כל הפעולות הן אטומיות ברמת השורה.
אין פריט תואם ישירות. קבוצת עמודות: קבוצה של עמודות שממוינות בסדר לקסיקוגרפי. מנגנון איסוף הזבל מוגדר ברמה הזו.
‫bin: צמד מפתח/ערך שבו שם ה-bin הוא המזהה של ערך ברשומה. מסווג עמודה: תווית של ערך שמאוחסן בטבלה.
אין פריט תואם ישירות. ‫cell: תווית של ערך עם חותמת זמן שמאוחסן בטבלה.
תקציר (digest) של רשומה: גיבוב (hash) של טריפלט שמזהה רשומה: מרחב שמות, קבוצה ומפתח. אין פריט תואם ישירות.
הערה: במהלך ההעברה, תקצירי הרשומות משמשים כמפתחות שורות ב-Bigtable. מידע נוסף זמין במאמר בנושא תכנון מפתח שורה.
record Last Update Time (LUT): חותמת זמן של הכתיבה האחרונה לרשומה. ‫cell timestamp: גרסה עם חותמת זמן של הערך בצומת של שורה ועמודה שיש להן כמה תאים.
‫key: מזהה רשומה ייחודי בתוך קבוצה. ‫row key: מפתח שורה, ייחודי בטבלה.
‫AQL: כלי לשורת הפקודה לעיון בנתונים ולפיתוח פונקציות בהגדרת משתמש למסד הנתונים של Aerospike. ‫GoogleSQL: שפת שאילתות שמשמשת מספר Google Cloud שירותים, כולל Spanner,‏ BigQuery ו-Bigtable.

מגבלות על סוגי נתונים

בטבלה הבאה מוצגת השוואה בין המגבלות של סוגי הנתונים שמשמשים את Aerospike ואת Bigtable:

Aerospike Bigtable
‫namespace: מספר מרחבי השמות המקסימלי ב מהדורת Enterprise הוא 32. ‫table: מופע יכול להכיל עד 1,000 טבלאות. שם הטבלה לא יכול להיות ארוך מ-50 תווים.
set: באשכול יכולות להיות עד 4,095 קבוצות. האורך המקסימלי של שם קבוצה הוא 63 בייט. אין פריט תואם ישירות.
רשומה: הגודל המקסימלי של רשומה הוא 8 MB. ‫row: הגודל המקסימלי של שורה הוא 256 MB.
אין פריט תואם ישירות. משפחת עמודות: מספר משפחות העמודות הוא בלתי מוגבל, אבל יותר מ-100 עלולות לגרום לירידה בביצועים.
‫bin: מספר התאים לא מוגבל, אבל כל תא יכול להכיל עד 1 MB של נתונים. האורך המקסימלי של שם הפח הוא 15 בייט. מגדיר העמודה: המגבלה היא 100MB, אבל מומלץ לא לחרוג מ-10MB. מספר העמודות לא מוגבל.
‫key: הגודל המקסימלי של המפתח הוא 8 KB. מפתח שורה: הגודל המקסימלי של מפתח שורה הוא 4 KB.

מידע נוסף על מגבלות Bigtable זמין במאמר מכסות ומגבלות. מידע נוסף על מגבלות Aerospike זמין במאמר Aerospike system limits and thresholds.

ארכיטקטורה

בקטעים הבאים מופיעה סקירה כללית של הארכיטקטורה של Bigtable ושל Aerospike.

Bigtable

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

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

הארכיטקטורה של Bigtable מספקת את היתרונות הבאים:

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

Aerospike

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

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

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

שכפול

בקטע הזה מוצג תהליך השכפול ב-Aerospike וב-Bigtable.

Bigtable

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

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

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

Aerospike

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

אפשר להגדיר שכפול בין מרכזי נתונים (XDR) כדי לסנכרן נתונים בין אשכולות שונים. התכונה 'מיזוג נתונים' ב-Aerospike מבטיחה שבסופו של דבר הנתונים יהיו זהים בכל מרכזי הנתונים, אחרי השכפול. עם זאת, יכול להיות שעדכונים ביניים יאבדו.

כדי להבטיח עמידות, אלגוריתם העקביות מבוסס-הרשימה של Aerospike דורש N+1 עותקים כדי לטפל ב-N כשלים.

מודל נתונים

בקטע הזה מוצגות השוואות בין מודלי הנתונים שמשמשים את Bigtable ואת Aerospike.

סכימה גמישה

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

עיצוב מפתח השורה

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

במהלך ההעברה,‏ Bigtable משתמש בסיכומי רשומות של Aerospike כמפתחות שורות מהסיבות הבאות:

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

סוגי הנתונים

‫Aerospike תומך בסוגי נתונים מתקדמים, כולל סקלרים, GeoJSON,‏ HyperLogLogs, רשימות ואובייקטים מקוננים. אפשר ליצור אינדקסים לסוגים האלה ולשאול עליהם שאילתות בעזרת אינדקסים משניים. בנוסף, Aerospike מספקת ממשקי API בצד השרת שמאפשרים לבצע פעולות מורכבות על סוגי הנתונים האלה, כמו סינון לפי מיקום גיאוגרפי או שינוי של תוכן הרשימה.

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

מיפוי סוגים

במהלך ההעברה מ-Aerospike ל-Bigtable, ספריית המתאמים עוזרת לשמור על סוגי Aerospike גם אם Bigtable לא תומך בהם.

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

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

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

בדוגמאות הבאות אפשר לראות איך רשומות של Aerospike ממופות לשורות של Bigtable:

סוג נתונים רשומת Aerospike שורה ב-Bigtable
סקלרים integerBin: 1
floatBin: 2.2
stringBin: "abc" 
<record's digest>:
  SCALARS:floatBin__FLOAT64
    "@\x01\x99\x99\x99\x99\x99\x9a"
  SCALARS:integerBin__INT64
    "\x00\x00\x00\x00\x00\x00\x00\x01"
  SCALARS:stringBin__STRING
    "abc"
אובייקטים listBin: [1,2]
mapBin: {"x": 1} 
<record's digest>:
  OBJECT:listBin__LIST__0__INT64
    "\x00\x00\x00\x00\x00\x00\x00\x01"
  OBJECT:listBin__LIST__1__INT64
    "\x00\x00\x00\x00\x00\x00\x00\x02"
  OBJECT:mapBin__MAP__x__INT64
    "\x00\x00\x00\x00\x00\x00\x00\x01"

קבוצת עמודות

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

אורך חיים (TTL)

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

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

מגדירי עמודות

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

תאים

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

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

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

טרנזקציות

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

איזון עומסים ומעבר לגיבוי (failover)

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

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

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

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

גיבוי ושחזור

‫Aerospike מספקת כלים חיצוניים לגיבוי ולשחזור שנקראים asbackup ו-asrestore. הכלים האלה יוצרים גיבויים לוגיים בצד הלקוח, והם דומים לביצוע סריקה. אפשר לנהל את הגיבוי גם באמצעות Aerospike Backup Service או Aerospike Kubernetes Operator. שני השירותים האלה משתמשים ב-asbackup וב-asrestore באופן פנימי, ומספקים תזמון ותיאום של כמה תהליכים. הגיבויים לא אטומיים, כלומר יכול להיות שפעולות כתיבה שמתרחשות במהלך הגיבוי לא יתועדו.

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

הבדלים מרכזיים בטיפול בגיבוי

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

שיקולי ביצועים

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

התעניינות ברכישה Bigtable Aerospike
שורות חמות מפיץ טאבלטים ופעולות כדי לאזן את השימוש במשאבים. אפשר לבודד שורה שמתבצעת אליה גישה לעיתים קרובות לטבלט של שורה אחת בצומת אחד, וכך להגביל את ההשפעה על שורות אחרות. מפיץ שורות על סמך גיבובים בכל הצמתים, ללא קשר לתנועה. שורה פעילה יכולה להשפיע על הביצועים של מחיצה שלמה.
סריקות של מפתחות ממוינים הנתונים מאוחסנים בסדר לקסיקוגרפי, ולכן הם יעילים מאוד להזרמת נתונים ממוינים. הרשומות מופצות על סמך ערכי גיבוב (hash), ולכן כדי לסרוק הרבה מפתחות עוקבים צריך לשלוח שאילתות לכמה צמתים ולצבור את התוצאות, מה שיכול להיות איטי יותר. תומך באינדקסים משניים, כולל סוגים מתקדמים, שעשויים לצמצם את הצורך בסריקות.
הוספה של הרבה מקשים עוקבים הנתונים מאוחסנים בסדר לקסיקוגרפי, כלומר צומת יחיד מטפל בהרבה פעולות כתיבה של מפתחות רצופים. כתוצאה מכך, דפוס קריאה או כתיבה יכול להגיע לצומת שמחזיק את הטאבלט שאחראי על סוף מרחב מפתחות השורות, ובפועל להעמיס עליו יותר מדי. מפיץ מפתחות על סמך hash, ומפיץ את העומס בין כמה צמתים כשכותבים מפתחות עוקבים.
שורות עם מספר גדול מאוד של עמודות למרות ש-Bigtable יכול לתמוך בשורות בגודל של עד 256 MB, עיבוד של שורות גדולות יכול להשפיע על הביצועים. ‫Bigtable מותאם לשורות קטנות יותר. לכן, כדאי לקחת בחשבון את ארגון התאים ואת הגישה לנתונים במהלך תכנון הסכימה, כדי להימנע מפיזור מיותר של נתונים על פני תאים רבים. הביצועים של הפונקציה לא אופטימליים כשנתקלים בשורה או ברשומה עם מספר גדול מאוד של עמודות או תאים.
הפעלות במצב התחלתי (cold start) הביצועים הכי טובים מתקבלים עם טבלאות גדולות שניגשים אליהן לעיתים קרובות. אם מתחילים לשלוח בקשות אחרי תקופה שבה לא היה שימוש (הפעלה במצב התחלתי), יכול להיות שתבחינו בחביון גבוה. זה קורה כי הפיצול לטבלטים וההפצה שלהם בין הצמתים לא אופטימליים, וכי המטמון לא חם. יכול להיות שהחלוקה בין הצמתים לא תהיה אופטימלית לחלוטין במשך כמה דקות במהלך הפעלה במצב התחלתי (cold start) ובמהלך איזון מחדש. הביצועים לא משתנים לאורך זמן כי חלוקת הנתונים לא מבוססת על עומס. למרות שצריך לחמם את המטמון, האינדקסים נשמרים בזיכרון, מה שמקצר את זמן החיפוש בדיסק ומפחית את החשיבות של שמירת נתונים במטמון.
הרבה טבלאות קטנות מומלץ להימנע מיצירה של הרבה טבלאות קטנות. הצדקה לשימוש בטבלאות נפרדות היא תרחישי שימוש או סכימות שונים, אבל לא נתונים דומים, כי זה לא משפר את איזון העומסים ומגדיל את תקורה הניהול. רוב הרשומות נמצאות במרחב שמות אחד, ומקובצות לקבוצות. לקבוצות אין סכימות ספציפיות, אבל אפשר להגדיר אינדקסים משניים או פעולות סריקה לכל קבוצה. פיצול הנתונים לקבוצות לא משפיע על הביצועים.
מערך נתונים גדול אפשר לאחסן קבוצות נתונים בגודל אקסה-בייט. הביצועים לא מושפעים מגודל מערך הנתונים הכולל בגלל הארכיטקטורה שלו ופיצול הטאבלטים הדינמי. מבחינה טכנית, אין מגבלת גודל למסדי נתונים של Aerospike, אבל Aerospike מאחסן אינדקסים ורשומות בנפרד. כדי לשפר את הביצועים, אפשר לאחסן את שני סוגי הנתונים ב סוגים שונים של מכשירי אחסון. אחסון אינדקסים בזיכרון RAM חיוני לזמני אחזור קצרים, אבל יכול להיות שלא יהיה אפשרי במערכי נתונים גדולים מאוד. לדוגמה, אם יש 4 מיליארד אובייקטים וגורם שכפול של 2 (RF2), הזיכרון שנצרך בשיוך לאינדקס הראשי בכל האשכול ב-All Flash הוא 2.5 GiB. באותו מקרה לדוגמה, בהגדרת זיכרון היברידי שבה האינדקס הראשי נמצא בזיכרון, ייעשה שימוש ב-476.8 GiB של זיכרון.
שינוי גודל העיבוד והאחסון מופרדים ויכולים להתרחב באופן עצמאי. צומת יחיד יכול לטפל בחלקים של נתונים בגודל של כמה מאות טרה-בייט או אפילו פטה-בייט. כדי לקבל זמני אחזור קצרים, חשוב לאחסן את האינדקסים ב-RAM. במקרה כזה, צריך להגדיל את הקיבולת של המכונות באופן אנכי יחד עם קיבולת האחסון, כדי להתחשב באינדקס הראשי.

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