סקירה כללית על שכפול

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

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

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

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

איך השכפול פועל

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

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

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

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

‫Bigtable משכפל את כל השינויים בנתונים, כולל כל סוגי השינויים הבאים:

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

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

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

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

ביצועים

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

תרחישים לדוגמה

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

בידוד אפליקציות להצגת מודעות מקריאות אצווה

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

שיפור הזמינות

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

גיבוי כמעט בזמן אמת

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

מוודאים שהנתונים שלכם זמינים בכל העולם

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

מודלים של עקביות

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

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

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

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

עקביות של קריאה אחרי כתיבה

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

ניתוב באשכול יחיד

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

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

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

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

ניתוב לפי שורה

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

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

מודל עקביות חזק

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

יישוב סכסוכים

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

פרופילים של אפליקציות

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

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

מדיניות תכנון מסלול

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

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

מעבר לגיבוי (Failover)

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

השמטה של טווחי שורות כשהשכפול מופעל

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

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