העברה מ-DynamoDB ל-Bigtable

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

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

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

איך מתחילים להשתמש בכלי להעברה מ-DynamoDB ל-Bigtable

Google Cloud Professional Services מספק כלי להעברת נתונים בקוד פתוח כדי לייעל את העברת הנתונים מ-DynamoDB ל-Bigtable. הכלי מבצע אוטומציה של תהליך ייבוא הנתונים אל Google Cloud ואז טעינתם אל Bigtable.

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

מידע נוסף על כלי ההעברה מ-DynamoDB ל-Bigtable זמין במאמר DynamoDB to Bigtable Migration Utility.

השוואה בין DynamoDB לבין Bigtable

בסעיף הזה נבחנים הדמיון וההבדלים בין DynamoDB לבין Bigtable.

מישור הבקרה

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

בטבלה הבאה מוצגת השוואה בין משאבי מישור הבקרה של DynamoDB ו-Bigtable.

DynamoDB	Bigtable
טבלה: אוסף של פריטים עם מפתח ראשי מוגדר. לטבלאות יש הגדרות לגיבויים, שכפול וקיבולת.	מופע: קבוצה של אשכולות Bigtable באזורים שונים, שמתבצעת ביניהם שכפול וניתוב חיבורים. Google Cloud מדיניות השכפול מוגדרת ברמת המופע. אשכול: קבוצה של צמתים באותו אזור גיאוגרפיGoogle Cloud , רצוי באותו מיקום עם שרת האפליקציה שלכם, מסיבות שקשורות לזמן אחזור ולשכפול. כדי לנהל את הקיבולת, משנים את מספר הצמתים בכל אשכול. טבלה: ארגון לוגי של ערכים שממוינים לפי מפתח שורה. הגדרות הגיבויים נקבעות ברמת הטבלה.
יחידת קיבולת קריאה (RCU) ויחידת קיבולת כתיבה (WCU): יחידות שמאפשרות קריאה או כתיבה בשנייה עם גודל מטען קבוע. תחויבו על יחידות קריאה או כתיבה עבור כל פעולה עם גודל מטען גדול יותר.פעולות UpdateItem צורכות את קיבולת הכתיבה שמשמשת לגודל הגדול ביותר של פריט מעודכן – לפני או אחרי העדכון – גם אם העדכון כולל קבוצת משנה של מאפייני הפריט.	צומת: משאב מחשוב וירטואלי שאחראי לקריאה ולכתיבה של נתונים. מספר הצמתים באשכול מתורגם למגבלות על קצב העברת הנתונים לקריאות, לכתיבות ולסריקות. אפשר לשנות את מספר הצמתים בהתאם לשילוב של יעדי ההשהיה, מספר הבקשות וגודל המטען הייעודי (payload). צמתים של SSD מספקים את אותה מהירות העברה לקריאה ולכתיבה, בניגוד להבדל המשמעותי בין RCU ל-WCU. מידע נוסף זמין במאמר בנושא ביצועים של עומסי עבודה אופייניים.
מחיצה: בלוק של שורות רצופות, שמגובה על ידי כונני SSD שמוצבים יחד עם הצמתים. כל מחיצה כפופה למגבלה קשיחה של 1,000 יחידות WCU,‏ 3,000 יחידות RCU ו-10GB של נתונים.	טבלט: בלוק של שורות סמוכות שמגובה על ידי אמצעי האחסון שנבחר (SSD או HDD). הטבלאות מחולקות ל-shards כדי לאזן את עומס העבודה. טבלאות לא מאוחסנות בצמתים ב-Bigtable, אלא במערכת הקבצים המבוזרת של Google. כך אפשר לבצע במהירות חלוקה מחדש של נתונים כשמבצעים שינוי גודל, וגם לשפר את העמידות על ידי שמירה של כמה עותקים.
טבלאות גלובליות: דרך להגדיל את הזמינות והעמידות של הנתונים על ידי הפצת שינויים בנתונים באופן אוטומטי בכמה אזורים.	שכפול: דרך להגדיל את הזמינות והעמידות של הנתונים על ידי הפצה אוטומטית של שינויים בנתונים בכמה אזורים או בכמה אזורים באותו אזור.
לא רלוונטי	פרופיל אפליקציה: הגדרות שמנחות את Bigtable איך לנתב קריאה ל-API של לקוח לאשכול המתאים במופע. אפשר גם להשתמש בפרופיל אפליקציה כתג לפילוח מדדים לצורך שיוך (Attribution).

שכפול גיאוגרפי

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

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

‫Bigtable תומך באשכולות משוכפלים בכמה שיותר אזורים שזמינים בעד 8 אזורים שבהם Bigtable זמין. Google Cloud לרוב האזורים יש שלושה תחומים. מידע נוסף זמין במאמר אזורים ותחומים.

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

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

בטבלה הבאה מפורטים מושגים שקשורים לשכפול, ומתוארת הזמינות שלהם ב-DynamoDB וב-Bigtable.

נכס	DynamoDB	Bigtable
שכפול עם כמה שרתים ראשיים	כן. אתם יכולים לקרוא ולכתוב בכל טבלה גלובלית.	כן. אפשר לקרוא ולכתוב לכל אשכול Bigtable.
מודל העקביות	מודל עקביות הדרגתי. עקביות של קריאה אחרי כתיבה ברמה האזורית לטבלאות גלובליות.	מודל עקביות הדרגתי. עקביות של קריאה אחרי כתיבה ברמת האשכול לכל הטבלאות, בתנאי ששולחים את פעולות הקריאה והכתיבה לאותו אשכול.
Replication latency	אין הסכם רמת שירות (SLA). שניות	אין הסכם רמת שירות (SLA). שניות
רמת הפירוט של ההגדרה	רמת הטבלה.	ברמת המופע. מופע יכול להכיל כמה טבלאות.
הטמעה	יוצרים טבלה גלובלית עם העתק של הטבלה בכל אזור שנבחר. ברמה אזורית. שכפול אוטומטי בין רפליקות על ידי המרת טבלה לטבלה גלובלית. צריך להפעיל את DynamoDB Streams בטבלאות, כך שהזרם יכיל את התמונות החדשות והישנות של הפריט. מחיקת אזור כדי להסיר את הטבלה הגלובלית באזור הזה.	ליצור מכונה עם יותר מאשכול אחד. השכפול מתבצע אוטומטית בכל האשכולות באותו מופע. ברמת האזור. הוספה והסרה של אשכולות ממופע Bigtable.
אפשרויות שכפול	לכל טבלה.	לכל מופע.
ניתוב תעבורת הנתונים וזמינות	התנועה מנותבת אל העותק הגיאוגרפי הקרוב ביותר. במקרה של כשל, אתם מפעילים לוגיקה עסקית מותאמת אישית כדי לקבוע מתי להפנות בקשות לאזורים אחרים.	משתמשים בפרופילי אפליקציות כדי להגדיר מדיניות לניתוב תנועה באשכול. משתמשים בניתוח תנועה בין אשכולות כדי לנתב תנועה באופן אוטומטי לאשכול הקרוב ביותר שפועל בצורה תקינה. במקרה של כשל, Bigtable תומך במעבר אוטומטי לגיבוי בין אשכולות לצורך זמינות גבוהה.
שינוי גודל	קיבולת הכתיבה ב יחידות בקשות כתיבה משוכפלות (R-WRU) מסונכרנת בין העותקים. קיבולת הקריאה ביחידות קיבולת קריאה משוכפלות (R-RCU) היא לכל עותק משוכפל.	אפשר לשנות את גודל האשכולות באופן עצמאי על ידי הוספה או הסרה של צמתים מכל אשכול משוכפל לפי הצורך.
עלות	העלות של R-WRU גבוהה ב-50% מהעלות של WRU רגיל.	החיוב הוא על הצמתים והאחסון של כל אשכול. אין עלויות של שכפול רשת לשכפול אזורי בין אזורים. עלויות נצברות כששכפול מתבצע בין אזורים או בין יבשות.
הסכם רמת שירות (SLA)	99.999%	99.999%

מישור הנתונים

בטבלה הבאה מוצגות השוואות בין מושגים של מודל נתונים ב-DynamoDB וב-Bigtable. כל שורה בטבלה מתארת תכונות דומות. לדוגמה, פריט ב-DynamoDB דומה לשורה ב-Bigtable.

DynamoDB	Bigtable
פריט: קבוצה של מאפיינים שאפשר לזהות אותה באופן ייחודי מבין כל הפריטים האחרים באמצעות המפתח הראשי שלה. הגודל המקסימלי המותר הוא 400KB.	שורה: ישות אחת שמזוהה על ידי מפתח השורה. הגודל המקסימלי המותר הוא 256MB.
לא רלוונטי	משפחת עמודות: מרחב שמות שמוגדר על ידי המשתמש ומקבץ עמודות.
מאפיין: קיבוץ של שם וערך. ערך מאפיין יכול להיות סקלרי, קבוצה או מסמך. אין מגבלה מפורשת על גודל המאפיין עצמו. עם זאת, מכיוון שכל פריט מוגבל ל-400KB, אם לפריט יש רק מאפיין אחד, גודל המאפיין יכול להיות עד 400KB פחות הגודל שתופס שם המאפיין.	מזהה עמודה: המזהה הייחודי של עמודה בתוך משפחת עמודות. המזהה המלא של עמודה מופיע בתבנית column-family:column-qualifier. המסווגים של העמודות ממוינים בסדר לקסיקוגרפי בתוך קבוצת העמודות. הגודל המקסימלי המותר של מסווג עמודות הוא 16KB. תא: תא מכיל את הנתונים של שורה, עמודה וחתימת זמן מסוימות. כל תא מכיל ערך אחד בגודל של עד 100MB.
מפתח ראשי: מזהה ייחודי של פריט בטבלה. זה יכול להיות מפתח מחיצה או מפתח מורכב. מפתח מחיצה: מפתח ראשי פשוט שמורכב מתכונה אחת. המאפיין הזה קובע את המחיצה הפיזית שבה הפריט נמצא. הגודל המקסימלי המותר הוא 2KB. מפתח מיון: מפתח שקובע את סדר השורות במחיצה. הגודל המקסימלי המותר הוא 1KB. מפתח מורכב: מפתח ראשי שמורכב משני מאפיינים, מפתח המחיצה ומפתח המיון או מאפיין הטווח.	‫מפתח שורה: מזהה ייחודי של פריט בטבלה. בדרך כלל מיוצג על ידי שרשור של ערכים ותוחמים. הגודל המקסימלי המותר הוא 4KB. אפשר להשתמש במסנני עמודות כדי לספק התנהגות ששווה לזו של מפתח המיון ב-DynamoDB. אפשר ליצור מפתחות מורכבים באמצעות שרשור של מפתחות שורות ושל מסווגי עמודות. פרטים נוספים מופיעים בדוגמה לתרגום סכימה בקטע 'עיצוב סכימה' במסמך הזה.
אורך חיים (TTL): חותמות הזמן של כל פריט קובעות מתי פריט כבר לא נחוץ. אחרי התאריך והשעה של חותמת הזמן שצוינה, הפריט יימחק מהטבלה בלי לצרוך נפח העברה לכתיבה.	איסוף אשפה: חותמות זמן לכל תא קובעות מתי פריט אינו נחוץ עוד. איסוף האשפה מוחק פריטים שפג תוקפם במהלך תהליך רקע הנקרא דחיסה. כללי המדיניות של איסוף נתונים לא רלוונטיים מוגדרים ברמת קבוצת העמודות, ויכולים למחוק פריטים לא רק על סמך הגיל שלהם, אלא גם על סמך מספר הגרסאות שהמשתמש רוצה לשמור. כשקובעים את הגודל של האשכולות, לא צריך להביא בחשבון את הקיבולת של הדחיסה.
אינדקס משני גלובלי: טבלה שמכילה מאפיינים נבחרים מטבלת הבסיס, מאורגנים לפי מפתח ראשי ששונה מהמפתח של הטבלה. מפתח האינדקס לא צריך לכלול אף אחד ממאפייני המפתח מהטבלה. היא לא צריכה להיות עם אותה סכימת מפתחות כמו הטבלה. ‫DynamoDB מעדכן אינדקסים משניים גלובליים באופן אסינכרוני.	אינדקס משני אסינכרוני: כדי להריץ שאילתות על אותם נתונים באמצעות תבניות או מאפיינים שונים של חיפוש, אפשר ליצור אינדקס משני אסינכרוני. סוג האינדקס הזה מכיל מאפיינים נבחרים מטבלת הבסיס. המאפיינים האלה מאורגנים לפי מפתח ששונה מהמפתח של הטבלה עצמה. ההתנהגות דומה לאינדקסים משניים גלובליים ב-DynamoDB.

תפעול

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

DynamoDB	Bigtable
CreateTable	CreateTable
PutItem BatchWriteItem	‫MutateRow MutateRows ב-Bigtable, פעולות כתיבה נחשבות לפעולות upsert.
UpdateItem כתיבה מותנית הגדלה והקטנה	CheckAndMutateRow ReadModifyWriteRow ב-Bigtable, פעולות כתיבה נחשבות לפעולות upsert.
GetItem BatchGetItem, Query, Scan	‫`ReadRow` ‫`ReadRows` (range,‏ prefix,‏ reverse scan) ‫Bigtable תומך בסריקה יעילה לפי קידומת של מפתח שורה, תבנית של ביטוי רגולרי או טווח של מפתחות שורה קדימה או אחורה.

סוגי הנתונים

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

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

ב-Bigtable, כל הנתונים נחשבים לבייטים, והמערכת מצפה שקוד הלקוח יכיר את הסוג והקידוד כדי שהלקוח יוכל לנתח את התשובות בצורה נכונה. יוצא מן הכלל הוא פעולות increment, שבהן הערכים מתפרשים כמספרים שלמים עם סימן בפורמט big-endian‏ (64 ביט).

בטבלה הבאה מוצגת השוואה בין סוגי הנתונים ב-DynamoDB וב-Bigtable.

DynamoDB	Bigtable
סוגים סקלריים: מוחזרים כאסימוני מתאר של סוג הנתונים בתגובת השרת.	בייט: הבייטים מועברים לסוגים המיועדים באפליקציית הלקוח.‫ ‫Increment מפרשת את הערך כמספר שלם עם סימן בפורמט big-endian של 64 ביט
הגדרה: אוסף לא ממוין של רכיבים ייחודיים.	משפחת עמודות: אפשר להשתמש במאפייני עמודות כשמות של חברים בקבוצה, ולספק לכל אחד מהם ערך של תא בגודל 0 בייט. החברים בקבוצה מסודרים בסדר מילוני בתוך עמודת המשפחה שלהם.
מיפוי: אוסף לא ממוין של צמדי מפתח/ערך עם מפתחות ייחודיים.	Column family Use column qualifier as map key and cell value for value. המפתחות במפה ממוינים בסדר לקסיקוגרפי.
רשימה: אוסף ממוין של פריטים.	מגדיר העמודה כדי להשיג התנהגות שוות ערך ל-list_append, משתמשים בחותמת הזמן של ההוספה, ובחותמת הזמן של ההוספה הפוכה כדי להוסיף בתחילת הרשימה.

עיצוב סכימה

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

• עדכונים של ערכים בודדים
• מיון נתונים
• ניהול גרסאות של נתונים
• אחסון של ערכים גדולים

עדכונים של ערכים בודדים

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

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

מיון נתונים

‫DynamoDB מבצע גיבוב (hashing) ומפיץ באופן אקראי מפתחות של מחיצות, בעוד ש-Bigtable מאחסן שורות בסדר לקסיקוגרפי לפי מפתח השורה, והגיבוב נתון לבחירת המשתמש.

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

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

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

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

ב-Bigtable התהליך הזה נקרא key salting, והוא יכול להיות דרך יעילה להימנע מלוחות חמים.

ניהול גרסאות של נתונים

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

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

עסקאות מרובות שורות לעומת קיבולת גדולה של שורות

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

אחסון ערכים גדולים

מכיוון שגודל הפריט ב-DynamoDB, שמקביל לשורה ב-Bigtable, מוגבל ל-400KB, כדי לאחסן ערכים גדולים צריך לפצל את הערך בין פריטים או לאחסן אותו במדיה אחרת כמו S3. שתי הגישות האלה מוסיפות מורכבות לאפליקציה. לעומת זאת, תא ב-Bigtable יכול לאחסן עד 100MB, ושורה ב-Bigtable יכולה לתמוך בעד 256MB.

דוגמאות לתרגום סכימה

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

העברת סכימות בסיסיות

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

מפתח ראשי		מאפיינים
מפתח מחיצה	מפתח מיון	תיאור	מחיר	תמונה ממוזערת
כובעים	fedoras#brandA	עשוי מצמר איכותי…	30	https://storage…
כובעים	fedoras#brandB	עשוי מבד קנבס עמיד במים שנועד ל..	28	https://storage…
כובעים	newsboy#brandB	מוסיפים מגע של קסם וינטג' למראה היומיומי..	25	https://storage…
נעליים	sneakers#brandA	צאו מהבית בסטייל ובנוחות עם…	40	https://storage…
נעליים	sneakers#brandB	תכונות קלאסיות עם חומרים עכשוויים…	50	https://storage…

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

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

	מק"ט
מפתח שורה	תיאור	מחיר	תמונה ממוזערת
hats#fedoras#brandA	עשוי מצמר איכותי…	30	https://storage…
hats#fedoras#brandB	עשוי מבד קנבס עמיד במים שנועד ל..	28	https://storage…
hats#newsboy#brandB	מוסיפים מגע של קסם וינטג' למראה היומיומי..	25	https://storage…
shoes#sneakers#brandA	צאו מהבית בסטייל ובנוחות עם…	40	https://storage…
shoes#sneakers#brandB	תכונות קלאסיות עם חומרים עכשוויים…	50	https://storage…

תבנית עיצוב של טבלה יחידה

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

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

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

מפתח ראשי		מאפיינים
מפתח מחיצה	מפתח מיון	UploadDate	פורמטים
0123	וידאו	2023-09-10T15:21:48	‪{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	תוכן
		ממש אהבתי את זה. האפקטים המיוחדים מדהימים.
	VideoComment#86751345	תוכן
		נראה שיש תקלה באודיו בדקה 1:05.
	VideoStatsLikes	מספר יחידות
		3
	VideoStatsViews	מספר יחידות
		156
0124	וידאו	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	תוכן
		שיתפתי את זה עם כל החברים שלי.
	VideoComment#87616471	תוכן
		הסגנון מזכיר לי במאי קולנוע, אבל אני לא מצליח להבין מי זה.
	VideoStats	ViewCount
		45

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

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

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

	מאפיינים
מפתח שורה	פורמטים	לייקים	צפיות	UserComments
0123	‪{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48	3	156	ממש אהבתי את זה. האפקטים המיוחדים מדהימים. @ 2023-09-10T19:01:15 נראה שיש שיבוש באודיו בדקה 1:05. @ 2023-09-10T16:30:42
0124	‪{"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21		45	הסגנון מזכיר לי במאי קולנוע, אבל אני לא מצליח להבין מי זה. @2023-10-12T07:08:51

תבנית עיצוב של רשימת סמיכויות

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

מפתח ראשי		מאפיינים
מפתח מחיצה	מפתח מיון	DateCreated	פרטים
Invoice-0123	Invoice-0123	2023-09-10T15:21:48	‪{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."}
	Payment-0680	2023-09-10T15:21:40	‪{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"}
	Payment-0789	2023-09-10T15:21:31	‪{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"}
Invoice-0124	Invoice-0124	2023-09-09T10:11:28	‪{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."}
	Payment-0327	2023-09-09T10:11:10	‪{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"}
	Payment-0275	2023-09-09T10:11:03	‪{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"}

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

	Invoice	תשלום
row key	פרטים	0680	0789
0123	‪{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 2023-09-10T15:21:48	‪{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"} @ 2023-09-10T15:21:40	‪{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"} @ 2023-09-10T15:21:31
row key	פרטים	0275	0327
0124	‪{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 2023-09-09T10:11:28	‪{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"} @ 2023-09-09T10:11:03	‪{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"} @ 2023-09-09T10:11:10

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

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

• מידע נוסף על עיצוב סכימת Bigtable
• מידע נוסף על אמולטור Bigtable
• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאיGoogle Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.