מופעים, אשכולות וצמתים

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

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

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

מכונות

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

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

למופע יש כמה מאפיינים חשובים שצריך להכיר:

  • המהדורה (Enterprise או Enterprise Plus)
  • סוג האחסון (SSD או HDD)
  • פרופילי האפליקציות, שמשמשים בעיקר למופעים שמשתמשים בשכפול

בקטעים הבאים מפורטים המאפיינים האלה.

מהדורות

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

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

אם אתם צריכים חביון של פחות ממילי-שנייה לקריאת נקודות, אתם יכולים להפעיל את שכבת הזיכרון המשולבת (גרסת Preview) עבור האשכול שלכם. התכונה 'בזיכרון' זמינה רק במהדורת Enterprise Plus. מידע נוסף מופיע במאמר בנושא סקירה כללית של In-memory.

סוגי אחסון

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

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

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

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

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

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

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

אשכולות

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

כל אשכול נמצא באזור אחד. במופע יכולים להיות אשכולות בעד 8 אזורים שבהם Bigtable זמין. כל תחום באזור יכול להכיל רק אשכול אחד. לדוגמה, אם למופע יש אשכול ב-us-east1-b, אפשר להוסיף אשכול באזור אחר באותו אזור, כמו us-east1-c, או באזור באזור נפרד, כמו europe-west2-a.

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

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

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

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

צמתים

לכל אשכול במכונה יש צומת אחד או יותר, שהם משאבי מחשוב ש-Bigtable משתמש בהם כדי לנהל את הנתונים שלכם.

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

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

כל צומת אחראי ל:

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

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

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

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

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

צמתים של אשכולות משוכפלים

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

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

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

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

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

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

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