התאמה להיקף

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

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

אפשר לשנות את הגודל של אשכול Bigtable בדרכים הבאות:

שינוי גודל אופקי

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

שינוי גודל אנכי של רמת זיכרון

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

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

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

גורם לקביעת קנה מידה של צומת

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

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

אפשר ליצור אשכול עם גורם קנה מידה של 2x להגדלת מספר הצמתים כשמשתמשים במסוףGoogle Cloud או ב-CLI של gcloud.

אפשר להגדיר הגדלת קנה מידה של צמתים פי 2 באמצעות התאמה אוטומטית לעומס או הקצאה ידנית של צמתים. במהדורת Enterprise Plus, צריך להפעיל קנה מידה של 2x צמתים כדי לגשת למגבלת האחסון המורחבת של 64 TB לכל צומת (גרסת Preview).

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

אשכולות קטנים

הגדלת קנה המידה של הצמתים פי 2 היא אופטימלית לעומסי עבודה גדולים יותר. אם אתם שוקלים לשנות את קנה המידה של הצמתים מסטנדרטי (בפקטור של אחד) ל-2x, כדאי שתבדקו את ההשלכות על העלויות. במקרה של עומס עבודה קטן יותר, כמו עומס עבודה שמופעל באשכול עם צומת אחד, שימוש בהגדלת קנה מידה של צומת פי 2 יעלה פי 2 יותר. באופן דומה, שימוש בהגדלת קנה מידה של צומת פי 2 לעומס עבודה שהופעל בעבר באשכול עם 3 צמתים מגדיל את העלויות ב-33%.

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

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

מגבלות

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

זמינות הצומת

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

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

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

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

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

השהייה גדלה בגלל הקטנת הקיבולת מהר מדי

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

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

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

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

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

השימוש ברמת הביניים בזיכרון ובקנה מידה אנכי זמין רק באשכולות SSD במהדורת Enterprise Plus.

הגבלות על גורם קנה המידה של הצומת

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

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

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

  • me-central2-b
  • southamerica-east1-c

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