אפשרויות ניתוב

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

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

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

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

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

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

זוהי מדיניות הניתוב היחידה שמאפשרת להפעיל עסקאות בשורה אחת.

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

ניתוב בין כמה אשכולות

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

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

כדאי להשתמש בניתוב בין כמה אשכולות אם רוצים זמינות גבוהה (HA). המלצות להגדרות של מופעים ופרטים נוספים זמינים במאמר בנושא יצירת זמינות גבוהה (HA).

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

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

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

בכל ניתוב של אשכול, כל אשכול במופע זמין לקבלת בקשות ולמעבר לגיבוי.

ניתוב קבוצות של אשכולות

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

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

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

כדי להפעיל ניתוב עם קירבה לשורה, משתמשים ב-CLI של gcloud, במסוףGoogle Cloud , בספריית הלקוח של Bigtable ל-Java או ב-Terraform. מידע נוסף זמין במאמר יצירת פרופיל אפליקציה.

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

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

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

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

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

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

מידע נוסף על מעבר לגיבוי זמין במאמר בנושא מעבר לגיבוי. איך מנהלים מעבר לגיבוי

ניתוב באמצעות SQL

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

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

עסקאות בשורה אחת

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

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

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

התנגשויות בין טרנזקציות של שורה אחת

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

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

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

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

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

כדי למנוע תוצאות לא רצויות, Bigtable מבצע את הפעולות הבאות:

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

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