הסבר על מיקומים
יחידת קיבולת של BigQuery היא יחידת מחשוב וירטואלית שמשמשת את BigQuery להרצת שאילתות SQL, קוד Python או סוגים אחרים של עבודות. במהלך ההפעלה של שאילתה, BigQuery קובע באופן אוטומטי כמה משבצות זמן משמשות את השאילתה. מספר הסלוטים שנעשה בהם שימוש תלוי בכמות הנתונים שעוברים עיבוד, במורכבות של השאילתה ובמספר הסלוטים שזמינים. באופן כללי, גישה ליותר משבצות מאפשרת להריץ יותר שאילתות בו-זמנית, והשאילתות המורכבות יכולות לרוץ מהר יותר. אי אפשר לשנות באופן ידני את מספר הסלוטים שבהם BigQuery משתמש כדי להריץ שאילתות.
תמחור על פי דרישה ותמחור על בסיס קיבולת
כל השאילתות משתמשות במשבצות, אבל יש שתי אפשרויות לתשלום על השימוש: מודל התמחור על פי דרישה או מודל התמחור לפי קיבולת.
כברירת מחדל, החיוב מתבצע לפי המודל של שימוש בפועל. במודל הזה, אתם מחויבים על כמות הנתונים שעובדו (נמדדת ב-TiB) על ידי כל שאילתה. בפרויקטים שמשתמשים במודל לפי דרישה חלות מכסות משבצות לכל פרויקט ולכל ארגון עם יכולת זמנית של שימוש חורג. רוב המשתמשים במודל על פי דרישה חושבים שמגבלות הקיבולת של המשבצות מספיקות. עם זאת, בהתאם לעומס העבודה, גישה ליותר משבצות עשויה לשפר את ביצועי השאילתות. כדי לבדוק את השימוש במשבצות בחשבון, אפשר לעיין במאמר מעקב אחרי המצב, ניצול המשאבים והעבודות.
במודל מבוסס-קיבולת, אתם משלמים על קיבולת המשבצות שהוקצתה לשאילתות שלכם לאורך זמן. המודל הזה מאפשר לכם שליטה מפורשת בקיבולת הכוללת של המשבצות. אתם בוחרים במפורש את מספר המשבצות שבהן תרצו להשתמש באמצעות הזמנה. אפשר לציין את מספר המשבצות בהזמנה כסכום בסיסי שתמיד מוקצה, או כסכום שמוקצה לפי הצורך באמצעות שינוי גודל אוטומטי. הקיבולת של הזמנות עם משבצות להתאמה אוטומטית לעומס (automatic scaling) גדלה כדי להתאים לדרישות של עומס העבודה. מערכת BigQuery מקצה יחידות קיבולת כשיש שינויים בעומסי העבודה. כך תוכלו להגדיר את מספר המשבצות בהזמנה על סמך הביצועים או האופי הקריטי של עומס העבודה שמשתמש בהזמנה.
ביצוע שאילתות באמצעות משבצות
כש-BigQuery מריץ משימת שאילתה, הוא ממיר את הצהרת ה-SQL לתוכנית ביצוע, שכוללת סדרה של שלבים בשאילתה. השלבים מורכבים בתורם מקבוצות של שלבי הרצה. ב-BigQuery נעשה שימוש בארכיטקטורה מקבילית מבוזרת להרצת שאילתות. שלבים מדמים את יחידות העבודה שאפשר לבצע במקביל. הנתונים מועברים בין השלבים באמצעות ארכיטקטורת ערבוב מבוזר, שמוסברת בפירוט בפוסט הזה בבלוג.Cloud de Confiance by S3NS
הביצוע של שאילתות BigQuery הוא דינמי. אפשר לשנות תוכנית שאילתה בזמן שהשאילתה נמצאת בעיבוד. אפשר לבצע אופטימיזציה של חלוקת העבודה לחלוקת נתונים ככל שמוסיפים שלבים. בנוסף, הקיבולת להרצת שאילתה יכולה להשתנות כששאילתות אחרות מתחילות או מסתיימות, או כשמנגנון ההתאמה האוטומטית מוסיף משבצות להזמנה.
ב-BigQuery אפשר להריץ כמה שלבים במקביל, להשתמש בביצוע ספקולטיבי כדי להאיץ שאילתה ולשנות באופן דינמי את החלוקה למחיצות של שלב כדי להשיג מקביליות אופטימלית.
כלכלה של משאבי יחידות קיבולת
אם שאילתה מסוימת דורשת יותר יחידות קיבולת (Slot) מהכמות שזמינה כרגע, המערכת של BigQuery יוצרת תור של יחידות עבודה נפרדות וממתינה שיתפנו יחידות קיבולת. ככל שיש התקדמות בביצוע שאילתות וככל שמתפנות יותר יחידות קיבולת (slots), יחידות העבודה שנמצאות בתור נבחרות לביצוע באופן דינמי.
מערכת BigQuery יכולה לבקש כל מספר של יחידות קיבולת לשלב מסוים של שאילתה. מספר הסלוטים המבוקש לא קשור לכמות הקיבולת שאתם רוכשים, אלא הוא אינדיקציה לגורם המקביליות האופטימלי ביותר שנבחר על ידי BigQuery לשלב הזה. יחידות עבודה נכנסות לתור ומבוצעות כשיחידות קיבולת מתפנות.
אם הביקוש לשאילתות חורג ממספר המשבצות שהתחייבתם להן, לא תחויבו על משבצות נוספות ולא תחויבו על תעריפים נוספים על פי דרישה. היחידות האישיות של העבודה שלכם נכנסות לתור.
לדוגמה,
- שלב של שאילתה מבקש 2,000 משבצות, אבל זמינות רק 1,000.
- מערכת BigQuery צורכת את כל 1,000 המשבצות ומכניסה לתור את 1,000 המשבצות האחרות.
- לאחר מכן, אם 100 משבצות מסיימות את העבודה שלהן, הן בוחרות באופן דינמי 100 יחידות עבודה מתוך 1,000 יחידות העבודה שנמצאות בתור. נותרו 900 יחידות של עבודה בהמתנה.
- לאחר מכן, אם 500 משבצות זמן מסיימות את העבודה שלהן, הן בוחרות באופן דינמי 500 יחידות עבודה מתוך 900 יחידות העבודה שנמצאות בתור. נותרו 400 יחידות של עבודה בהמתנה.
אם עומס העבודה דורש יותר משבצות ממה שזמין בהזמנה, זמן הריצה של העבודה יכול להתארך כי העבודות ימתינו עד שמשבצות יהיו זמינות. התופעה הזו נקראת תחרות על משבצות. התחרות על משבצות יכולה לגדול אם הביקוש לעומס העבודה גדול בהרבה ממספר המשבצות שזמינות להזמנה.
תעדוף הקיבולת
כשיש ביקוש גבוה למשאבי משבצות ב-BigQuery באזור מסוים, המערכת מנהלת את התחרות על המשאבים על ידי תעדוף של קיבולת. התעדוף הזה מבטיח שההשפעה על לקוחות עם מודלים של קיבולת ברמה גבוהה יותר תהיה קטנה יותר. המערכת נותנת עדיפות לקיבולת לפי הסדר הבא:
- Enterprise Plus ו-Enterprise, וגם קווי בסיס וקיבולת מחויבת.
- קיבולת בהתאמה אוטומטית ב-Enterprise Plus.
- קיבולת שניתנת להרחבה אוטומטית במהדורת Enterprise.
- מהדורת Standard וקיבולת לפי דרישה.
במקרה של מחלוקת באזור מסוים, סביר יותר שיהיו עיכובים בגישה לבקשות של מהדורת Standard ולבקשות של קיבולת לפי דרישה, כי המערכת מקצה משאבים קודם למהדורות ברמה גבוהה יותר.
תזמון הוגן ב-BigQuery
BigQuery מקצה קיבולת של יחידות קיבולת בהזמנה אחת באמצעות אלגוריתם שנקרא תזמון הוגן.
מתזמן העבודות של BigQuery אוכף שיתוף שווה של משבצות בין פרויקטים עם שאילתות פעילות בהזמנה, ולאחר מכן בין משימות של פרויקט נתון. המתזמן מספק הוגנות בסופו של דבר. במהלך תקופות קצרות, יכול להיות שחלק מהמשימות יקבלו חלק לא פרופורציונלי מהמשבצות, אבל מתזמן המשימות יתקן את זה בסופו של דבר. המטרה של המתזמן היא למצוא איזון בין פינוי אגרסיבי של משימות פעילות (שמוביל לבזבוז של זמן המשבצת) לבין הקצאת זמן נדיבה מדי (שמובילה לכך שמשימות עם משימות פעילות ארוכות מקבלות חלק לא פרופורציונלי מזמן המשבצת).
תזמון הוגן מבטיח שלכל שאילתה תהיה גישה לכל המשבצות הזמינות בכל זמן, והקיבולת מוקצה מחדש באופן דינמי ואוטומטי בין השאילתות הפעילות ככל שהדרישות של הקיבולת של כל שאילתה משתנות. השאילתות מסתיימות ושאילתות חדשות נשלחות להרצה בתנאים הבאים:
- בכל פעם שנשלחת שאילתה חדשה, הקיבולת מוקצה מחדש באופן אוטומטי בין השאילתות הפועלות. אפשר להשהות, להמשיך ולהוסיף לתור יחידות עבודה בודדות, ככל שיש יותר קיבולת זמינה לכל שאילתה.
- בכל פעם ששאילתה מסתיימת, הקיבולת שנצרכה על ידי השאילתה הזו הופכת באופן אוטומטי לזמינה מיידית לשימוש של כל השאילתות האחרות.
- בכל פעם שדרישות הקיבולת של שאילתה משתנות בגלל שינויים ב-DAG הדינמי של השאילתה, BigQuery מעריך מחדש באופן אוטומטי את זמינות הקיבולת של השאילתה הזו ושל כל השאילתות האחרות, ומקצה מחדש משבצות או משעה אותן לפי הצורך.
בהתאם למורכבות ולגודל, יכול להיות ששאילתה לא תדרוש את כל המשבצות שיש לה זכות להשתמש בהן, או שהיא תדרוש יותר. מערכת BigQuery מבטיחה באופן דינמי שכל המשבצות יוכלו לשמש באופן מלא בכל נקודת זמן, בהתאם לתזמון הוגן.
אם עבודה חשובה צריכה באופן עקבי יותר משבצות ממה שהיא מקבלת מהמתזמן, כדאי ליצור הזמנה נוספת עם מספר המשבצות הנדרש ולהקצות את העבודה להזמנה הזו.
כדוגמה לתזמון הוגן, נניח שיש לכם את הגדרת ההזמנה הבאה:
- הזמנה
A, שכוללת 1,000 משבצות זמן בסיסיות ללא שינוי גודל אוטומטי - פרויקט
AופרויקטB, שהוקצו להזמנה שלכם
תרחיש 1: בפרויקט A, מריצים שאילתה A (שאילתה אחת בו-זמנית) שדורשת שימוש גבוה במשבצות, ובפרויקט B מריצים 20 שאילתות בו-זמניות. למרות שיש סך של 21 שאילתות שמשתמשות בהזמנה A, חלוקת המשבצות היא כדלקמן:
- פרויקט
Aמקבל 500 משבצות, והשאילתהAמופעלת עם 500 משבצות. - פרויקט
Bמקבל 500 משבצות שמשותפות בין 20 השאילתות שלו.
תרחיש 2: בפרויקט A, מריצים שאילתה A (שאילתה אחת בו-זמנית) שדורשת 100 משבצות כדי לפעול, ובפרויקט B מריצים 20 שאילתות בו-זמנית.
מכיוון שהשאילתה A לא דורשת 50% מההזמנה, חלוקת המשבצות היא כדלקמן:
- פרויקט
Aמקבל 100 משבצות, והשאילתהAמופעלת עם 100 משבצות. - פרויקט
Bמקבל 900 משבצות שמשותפות בין 20 השאילתות שלו.
לעומת זאת, נבחן את הגדרת ההזמנה הבאה:
- הזמנה
B, שכוללת 1,000 משבצות זמן בסיסיות ללא התאמה אוטומטית לעומס. - 10 פרויקטים, שכולם מוקצים להזמנה
B.
נניח ש-10 הפרויקטים מריצים שאילתות שיש להן ביקוש מספיק למשבצות זמן. במקרה כזה, כל פרויקט יקבל 1/10 ממשבצות הזמן הכוללות בהזמנה (או 100 משבצות זמן), בלי קשר למספר השאילתות שמופעלות בכל פרויקט.
מכסות ומגבלות של משבצות
מכסות ומגבלות של יחידות קיבולת מספקות הגנה ל-BigQuery. מודלים שונים של תמחור משתמשים בסוגים שונים של מכסות משבצות, באופן הבא:
מודל תמחור לפי דרישה: אתם כפופים למגבלת משבצות לכל פרויקט ולארגון עם יכולת זמנית של שימוש במשאבים מעבר למכסה. בהתאם לעומסי העבודה, גישה ליותר משבצות יכולה לשפר את ביצועי השאילתות.
מודל תמחור לפי קיבולת: מכסות ומגבלות להזמנות מגדירות את המספר המקסימלי של משבצות שאפשר להקצות לכל ההזמנות במיקום מסוים. אם משתמשים בהתאמה אוטומטית לעומס, סכום הגדלים המקסימליים של ההזמנות לא יכול לחרוג מהמכסה הזו. אתם מחויבים רק על ההזמנות וההתחייבויות שלכם, ולא על המכסות. למידע על הגדלת מכסת המשבצות, ראו בקשה להגדלת מכסה.
כדי לבדוק כמה משבצות אתם משתמשים, אפשר לעיין במאמר בנושא מעקב אחרי BigQuery.
משבצות זמן בלי פעילות
בכל זמן נתון, יכול להיות שחלק מהמשבצות יהיו בלי פעילות. למשל:
- התחייבויות לשימוש ביחידות קיבולת שלא הוקצו לאף בסיס להזמנה.
- משבצות זמן שמוקצות לשימוש בסיסי בהזמנה אבל לא נמצאות בשימוש.
משבצות זמן פנויות לא רלוונטיות כשמשתמשים במודל התמחור על פי דרישה.
כברירת מחדל, שאילתות שמופעלות בהזמנה משתמשות אוטומטית במשבצות פנויות מהזמנות אחרות באותו אזור ובאותו פרויקט ניהול. המערכת של BigQuery מקצה באופן מיידי יחידות קיבולת פנויות להזמנה שהוקצתה להן, כשצריך אותן. משבצות בלי פעילות שהיו בשימוש על ידי הזמנה אחרת, המערכת תפנה אותן במהירות אם הן נדרשות על ידי ההזמנה המקורית. יכול להיות שבמשך זמן קצר תראו שהשימוש הכולל במשבצות חורג מהמקסימום שציינתם בכל ההזמנות, אבל לא תחויבו על השימוש הנוסף במשבצות.
לדוגמה, נניח שהגדרתם את ההזמנה הבאה:
-
project_aמוקצה ל-reservation_a, שיש לו 500 משבצות בסיסיות ללא התאמה אוטומטית לעומס. -
project_bמוקצה ל-reservation_b, שיש לו 100 משבצות בסיסיות ללא התאמה אוטומטית לעומס. - שתי ההזמנות נמצאות באותו אזור ובאותו פרויקט ניהולי, ואין פרויקטים אחרים שמוקצים להזמנות האלה.
הפעילות שלך מתבצעת ב-query_b ב-project_b. אם לא מופעלת שאילתה ב-project_a, ל-query_b יש גישה ל-500 משבצות פנויות מ-reservation_a. בזמן ש-query_b עדיין פועל, הוא עשוי להשתמש בעד 600 משבצות: 100 משבצות בסיסיות ועוד 500 משבצות בלי פעילות.
בזמן ש-query_b פועל, נניח שמריצים את query_a ב-project_a שיכול להשתמש ב-500 משבצות.
- מכיוון ששוריינו לך 500 משבצות זמן בסיסיות ל-
project_a,query_aהפגישה מתחילה באופן מיידי ומוקצות לה 500 משבצות זמן. - מספר המשבצות שהוקצו ל-
query_bיורד במהירות ל-100 משבצות בסיסיות. - שאילתות נוספות מופעלות ב
project_bומשתמשות ב-100 המשבצות האלה. אם בשאילתות הבאות אין מספיק משבצות פנויות כדי להתחיל, הן יתווספו לתור עד שהשאילתות שפועלות יושלמו ומשבצות יהפכו לזמינות.
בדוגמה הזו, אם project_b הוקצה לשמירת מקום ללא משבצות Baseline או התאמה אוטומטית לעומס, ל-query_b לא יהיו משבצות אחרי ש-query_a יתחיל לפעול. המערכת של BigQuery תשהה את query_b עד שיהיו יחידות קיבולת פנויות או עד שזמן הקצוב לתפוגה של השאילתה יגיע. שאילתות נוספות ב-project_b יתווספו לתור עד שמשבצות בלי פעילות יהיו זמינות.
כדי לוודא שפרטי הבקשה ישתמשו רק במשבצות שהוקצו להם, מגדירים את ignore_idle_slots לערך true. עם זאת, אם הערך של המאפיין ignore_idle_slots
מוגדר כ-true, אפשר לשתף את המשבצות הפנויות עם הזמנות אחרות.
אי אפשר לשתף משבצות זמן פנויות בין הזמנות של מהדורות שונות. אפשר לשתף רק את משבצות הזמן של תוכנית הבסיס או את משבצות הזמן שהוקצו. יכול להיות שמשבצות עם שינוי גודל אוטומטי יהיו זמינות באופן זמני, אבל אי אפשר לשתף אותן כמשבצות פנויות להזמנות אחרות כי יכול להיות שהגודל שלהן יוקטן.
כל עוד הערך של ignore_idle_slots הוא False, אפשר להגדיר במקום שמור מספר משבצות של 0 ועדיין תהיה גישה למשבצות שלא נעשה בהן שימוש. אם אתם משתמשים רק בdefault
שמירת מקום, מומלץ להשבית את ignore_idle_slots. אחר כך תוכלו להקצות פרויקט או תיקייה להזמנה הזו, והיא תשתמש רק במשבצות זמן פנויות.
הקצאות מסוג ML_EXTERNAL הן יוצאות דופן, כי אי אפשר להפסיק את השימוש במשבצות שמשמשות משימות ליצירת מודלים חיצוניים של BigQuery ML. המשבצות בהזמנה עם שני סוגי הקצאות, ML_EXTERNAL ו-QUERY, זמינות רק למשימות אחרות של שאילתות כשהמשבצות לא מאוכלסות על ידי משימות ML_EXTERNAL. בנוסף, אי אפשר להשתמש במקומות פנויים בהזמנות אחרות עבור המשימות האלה.
הוגנות מבוססת-הזמנה
בשיטה 'הוגנות מבוססת-הזמנה', מערכת BigQuery נותנת עדיפות למשבצות פנויות ומקצה אותן באופן שווה לכל ההזמנות באותו פרויקט אדמין, בלי קשר למספר הפרויקטים שמריצים משימות בכל הזמנה. כל הזמנה מקבלת חלק דומה מהקיבולת הזמינה במאגר המשבצות הפנויות, ואז המשבצות שלה מחולקות באופן הוגן בין הפרויקטים שלה. התכונה הזו נתמכת רק במהדורות Enterprise או Enterprise Plus.
בתרשים הבא מוצגת חלוקת משבצות זמן פנויות בלי שההגדרה 'הוגנות מבוססת-הזמנה' מופעלת:
בתרשים הזה, משבצות זמן פנויות מחולקות באופן שווה בין הפרויקטים.
אם לא מפעילים את התכונה 'הקצאה הוגנת על בסיס הזמנה', המשבצות הפנויות יחולקו באופן שווה בין הפרויקטים בהזמנות.
בתרשים הבא מוצגת החלוקה של משבצות זמן בלי פעילות כשההגדרה 'הוגנות מבוססת-הזמנה' מופעלת:
בתרשים הזה, משבצות זמן פנויות מחולקות באופן שווה בין ההזמנות, ולא בין הפרויקטים.
אם מפעילים את התכונה 'הקצאה הוגנת על בסיס הזמנות', המשבצות הפנויות מחולקות באופן שווה בין ההזמנות.
כשמפעילים את התכונה 'הוגנות מבוססת-הזמנה', כדאי לבדוק את צריכת המשאבים כדי לנהל את זמינות המשבצות ואת ביצועי השאילתות.
מומלץ להימנע מהסתמכות בלעדית על משבצות זמן בלי פעילות לעומסי עבודה של Production עם דרישות זמן מחמירות – משימות כאלה צריכות להשתמש במשבצות זמן Baseline או במשבצות זמן עם התאמה אוטומטית לעומס. מומלץ להשתמש במשבצות בלי פעילות לעבודות בעדיפות נמוכה יותר, כי אפשר להפסיק את המשבצות בכל שלב.
התאמה אוטומטית של יחידות קיבולת (Slot) לעומס
בקטע הבא נסביר על משבצות שניתנות להתאמה אוטומטית לעומס ואיך הן פועלות עם הזמנות.
שימוש בהזמנות עם שינוי גודל אוטומטי
לא צריך לרכוש התחייבויות לשימוש במשבצות לפני שיוצרים הזמנות של התאמה אוטומטית לעומס. התחייבויות לשימוש במשבצות זמן מספקות תעריף מוזל על משבצות זמן שנעשה בהן שימוש באופן עקבי, אבל הן אופציונליות בהזמנות עם התאמה אוטומטית לעומס. כדי ליצור הזמנה עם התאמה אוטומטית לעומס, צריך להקצות להזמנה מספר מקסימלי של משבצות (הגודל המקסימלי של ההזמנה). כדי לזהות את המספר המקסימלי של משבצות להתאמה אוטומטית לעומס, צריך להפחית מגודל ההזמנה המקסימלי את מספר משבצות הבסיס האופציונליות שהוקצו להזמנה.
כשיוצרים הזמנות עם התאמה אוטומטית לעומס, חשוב לקחת בחשבון את הנקודות הבאות:
- מערכת BigQuery מרחיבה את ההזמנות כמעט באופן מיידי עד שהיא מגיעה למספר יחידות הקיבולת (Slot) שנדרש להרצת המשימות, או עד שהיא מגיעה למספר המקסימלי של יחידות הקיבולת שזמינות להזמנה. המשבצות תמיד משנות את הגודל שלהן באופן אוטומטי לכפולה של 50.
- הגדלת הקיבולת מבוססת על שימוש בפועל, והיא מעוגלת כלפי מעלה למרווח של 50 משבצות.
- החיוב על משבצות שניתנות להרחבה אוטומטית מתבצע לפי תמחור של קיבולת מחשוב במהדורות המשויכות בזמן ההרחבה. החיוב הוא על מספר המשבצות שהוגדל, ולא על מספר המשבצות שבשימוש. החיוב הזה חל גם אם המשימה שגורמת ל-BigQuery להגדיל את הקיבולת נכשלת. לכן, לא מומלץ להשתמש בסכימת המידע של משרות כדי להתאים את החיוב. במקום זאת, אפשר לעיין במאמר בנושא מעקב אחרי התאמה אוטומטית לעומס באמצעות סכימת מידע.
- מספר המשבצות תמיד גדל בכפולות של 50, אבל יכול להיות שהוא יגדל ביותר מ-50 משבצות בכל שלב. לדוגמה, אם עומס העבודה שלכם דורש 450 יחידות קיבולת נוספות, מערכת BigQuery יכולה לנסות להגדיל את הקיבולת ב-450 יחידות קיבולת בבת אחת כדי לעמוד בדרישות הקיבולת.
- היקף השימוש ב-BigQuery יצומצם אם העבודות שמשויכות להזמנה לא יזדקקו יותר לקיבולת (בכפוף למינימום של דקה אחת).
כל קיבולת שמתבצעת בה שינוי אוטומטי נשמרת למשך 60 שניות לפחות. התקופה של 60 שניות נקראת חלון ההקטנה. כל שיא חדש בקיבולת מאפס את חלון ההקטנה, ומתייחס לכל רמת הקיבולת כאל הרשאה חדשה. עם זאת, אם עברו 60 שניות או יותר מאז העלייה האחרונה בקיבולת ויש פחות ביקוש, המערכת מקטינה את הקיבולת בלי לאפס את חלון ההקטנה, וכך מאפשרת הקטנות רצופות בלי השהיה.
לדוגמה, אם קיבולת עומס העבודה ההתחלתי גדלה ל-100 משבצות, השיא נשמר למשך 60 שניות לפחות. אם במהלך חלון ההקטנה הזה, עומס העבודה שלכם יגיע לשיא חדש של 200 משבצות, יתחיל חלון הקטנה חדש למשך 60 שניות. אם לא יזוהה שיא חדש במהלך חלון ההקטנה הזה, עומס העבודה יתחיל להצטמצם בסוף 60 השניות.
לדוגמה: בשעה 12:00:00, הקיבולת ההתחלתית שלכם גדלה ל-100 משבצות והשימוש נמשך שנייה אחת. השיא הזה נשמר למשך 60 שניות לפחות, החל מהשעה 12:00:00. אחרי 60 שניות (בשעה 12:01:01), אם השימוש החדש הוא 50 משבצות, BigQuery מצמצם את מספר המשבצות ל-50. אם בשעה 12:01:02 השימוש החדש הוא 0 יחידות קיבולת, מערכת BigQuery שוב מצמצמת את הקיבולת באופן מיידי ל-0 יחידות. אחרי שחלון ההקטנה מסתיים, BigQuery יכול להקטין את הקיבולת כמה פעמים ברציפות בלי שיידרש חלון הקטנה חדש.
מידע נוסף על עבודה עם התאמה אוטומטית לעומס זמין במאמר עבודה עם משבצות להתאמה אוטומטית לעומס.
שימוש בהזמנות עם משבצות זמן בסיסיות ומשבצות זמן שמתאימות את עצמן לעומס
בנוסף לציון הגודל המקסימלי של ההזמנה, אפשר גם לציין מספר בסיסי של משבצות לכל הזמנה. הבסיס הוא מספר המקומות המינימלי שתמיד יוקצו להזמנה, ותמיד תחויבו עליהם. משבצות שניתנות להרחבה אוטומטית מתווספות רק אחרי שכל משבצות הבסיס (ומשבצות פנויות, אם יש) נוצלו. אפשר לשתף משבצות בסיס בלי פעילות בהזמנה אחת עם הזמנות אחרות שזקוקות לקיבולת.
אפשר להגדיל את מספר המשבצות הבסיסיות בהזמנה כל כמה דקות. אם רוצים להקטין את מספר המשבצות הבסיסיות, אפשר לעשות זאת רק פעם בשעה אם שיניתם לאחרונה את קיבולת המשבצות הבסיסיות ומספר המשבצות הבסיסיות גדול ממספר המשבצות המובטחות. אחרת, אפשר להקטין את מספר המשבצות הבסיסי כל כמה דקות.
המשבצות של בסיס הנתונים ושל שינוי הגודל האוטומטי נועדו לספק קיבולת על סמך עומס העבודה האחרון שלכם. אם אתם צופים עומס עבודה גדול ששונה מאוד מעומסי העבודה שהיו לכם בעבר הקרוב, מומלץ להגדיל את קיבולת הבסיס לפני האירוע, במקום להסתמך על הקצאת משבצות התאמה אוטומטית לעומס כדי לכסות את קיבולת עומס העבודה. אם נתקלתם בבעיה בהגדלת קיבולת הבסיס, המתינו 15 דקות ונסו לשלוח את הבקשה שוב.
אם במקום השמור אין יחידות קיבולת בסיסיות או שהוא לא מוגדר להשאלה של יחידות קיבולת פנויות ממקומות שמורים אחרים, מערכת BigQuery תנסה להגדיל את הקיבולת. אחרת, צריך להשתמש בכל משבצות הבסיס לפני שמגדילים את מספר המשבצות.
הזמנות משתמשות במשבצות זמן ומוסיפות אותן לפי סדר העדיפות הבא:
- משבצות זמן בסיסיות.
- שיתוף משבצות זמן פנויות (אם האפשרות מופעלת). אפשר לשתף בהזמנות רק משבצות בסיס בלי פעילות או משבצות שמוקצות מהזמנות אחרות שנוצרו באותו מהדורה ובאותו אזור.
- שינוי אוטומטי של מספר המיקומים למודעות.
בדוגמה הבאה, מספר המשבצות גדל בהתאם לכמות בסיסית שצוינה. הזמנות של etl ושל dashboard כוללות גודל בסיסי של 700 ו-300 משבצות בהתאמה.
בדוגמה הזו, אפשר להגדיל את השריין etl ל-1,300 משבצות (700 משבצות בסיסיות ועוד 600 משבצות של התאמה אוטומטית לעומס). אם לא נעשה שימוש בהזמנה dashboard, אפשר להשתמש ב-300 המשבצות של ההזמנה dashboard בהזמנה etl אם לא מופעלת שם אף משימה, וכך להגיע למקסימום של 1,600 משבצות אפשריות.
אפשר להגדיל את ההזמנה של dashboard ל-1,100 משבצות (300 משבצות בסיסיות ועוד 800 משבצות של שינוי גודל אוטומטי). אם ההזמנה etl בלי פעילות בכלל, אפשר להגדיל את ההזמנה dashboard עד למקסימום של 1,800 משבצות (300 משבצות Baseline, 800 משבצות של התאמה אוטומטית לעומס ו-700 משבצות בלי פעילות בהזמנה etl).
אם נדרשים יותר מ-700 משבצות בסיסיות להזמנה של etl, המערכת תנסה להוסיף משבצות בשיטות הבאות, לפי הסדר:
- 700 משבצות זמן בסיסיות.
- שיתוף משבצת פנויה עם 300 המשבצות הבסיסיות בהזמנה
dashboard. ההזמנה שלכם משתפת רק משבצות בסיס פנויות עם הזמנות אחרות שנוצרו באותה מהדורה. - הגדלת מספר המקומות ב-600 נוספים עד לגודל המקסימלי של ההזמנה.
שימוש בהתחייבויות ליחידות קיבולת
בדוגמה הבאה מוצגים משבצות של התאמה אוטומטית לעומס באמצעות התחייבויות לקיבולת.
בדומה לתוכניות בסיסיות להזמנות, התחייבויות למשבצות מאפשרות להקצות מספר קבוע של משבצות שזמינות לכל ההזמנות. בניגוד למשבצות בסיסיות, אי אפשר להקטין את המחויבות במהלך תקופת המינוי. התחייבויות לשימוש במשבצות הן אופציונליות, אבל הן יכולות לחסוך בעלויות אם נדרשות משבצות בסיסיות לתקופות ארוכות. התחייבויות ליחידות קיבולת (Slot) משמשות לכיסוי יחידות קיבולת בסיסיות להזמנות שלכם. אחרי כן, כל קיבולת של משבצות שלא נעשה בהן שימוש תשותף כמשבצות פנויות בין שאר ההזמנות. התחייבויות למשבצות לא חלות על משבצות שניתנות להרחבה אוטומטית. כדי לוודא שתקבלו את התעריף המוזל על ההתחייבויות שלכם למשבצות, חשוב לוודא שההתחייבויות שלכם למשבצות מספיקות לכיסוי משבצות הבסיס.
בדוגמה הזו, אתם מחויבים בתעריף מוגדר מראש על משבצות של התחייבות לקיבולת. תחויבו לפי התעריף של התאמה אוטומטית לעומס על מספר המשבצות של התאמה אוטומטית לעומס אחרי שההתאמה מופעלת וההזמנות נמצאות במצב של הגדלה. במקרה של קצב שינוי גודל אוטומטי, החיוב הוא על מספר המשבצות שהוגדלו, ולא על מספר המשבצות שהיו בשימוש.
בדוגמה הבאה מוצגות הזמנות כשמספר המשבצות הבסיסיות גדול ממספר המשבצות המוקצות.
בדוגמה הזו, יש סך של 1,000 משבצות זמן בסיסיות בין שתי ההזמנות, 500 מההזמנה etl ו-500 מההזמנה dashboard. עם זאת, ההתחייבות חלה רק על 800 משבצות. בתרחיש הזה, על המשבצות העודפות יחול חיוב לפי תעריף התשלום בפועל (PAYG).
מספר המשבצות הזמינות המקסימלי
כדי לחשב את המספר המקסימלי של משבצות שאפשר להשתמש בהן בהזמנה, צריך לחבר את מספר המשבצות הבסיסי, את המספר המקסימלי של משבצות שניתנות להרחבה אוטומטית ואת כל המשבצות בהתחייבויות שנוצרו באותו מהדורה ולא נכללות במספר המשבצות הבסיסי. הדוגמה בתמונה הקודמת מוגדרת כך:
- התחייבות לקיבולת של 1,000 משבצות שנתיות. המשבצות האלה מוקצות כמשבצות בסיסיות בהזמנה
etlובהזמנהdashboard. - 700 משבצות בסיסיות שהוקצו להזמנה
etl. - 300 משבצות זמן בסיסיות שהוקצו להזמנה
dashboard. - הגדרה של שינוי גודל אוטומטי של 600 משבצות להזמנה
etl. - הגדרה של שינוי גודל אוטומטי של משבצות של 800 להזמנה
dashboard.
במקרה של הזמנת etl, המספר המקסימלי האפשרי של משבצות שווה למספר משבצות הבסיס של etl (700) בתוספת מספר משבצות הבסיס של dashboard (300, אם כל המשבצות בלי פעילות) בתוספת המספר המקסימלי של משבצות ההתאמה האוטומטית לעומס (600). לכן, מספר המשבצות המקסימלי שבהן יכולה להשתמש הזמנת etl בדוגמה הזו הוא 1,600. המספר הזה גדול מהמספר בהתחייבות לקיבולת.
בדוגמה הבאה, ההתחייבות השנתית חורגת ממספר המשבצות שהוקצו כבסיס.
בדוגמה הזו, יש לנו:
- התחייבות לקיבולת של 1,600 משבצות שנתיות.
- גודל ההזמנה המקסימלי הוא 1,500 (כולל 500 משבצות להתאמה אוטומטית לעומס).
- 1,000 משבצות בסיסיות שהוקצו להזמנה
etl.
מספר המשבצות המקסימלי שזמין להזמנה שווה למספר משבצות הבסיס (1,000) בתוספת מספר המשבצות הפנויות המוקצות שלא מוקדשות למשבצות הבסיס (1,600 משבצות שנתיות – 1,000 משבצות בסיס = 600) בתוספת מספר המשבצות של התאמה אוטומטית לעומס (500). לכן, מספר המשבצות המקסימלי הפוטנציאלי בהזמנה הזו הוא 2,100. יחידות הקיבולת (Slots) שנוספו באמצעות שינוי הגודל האוטומטי הן יחידות קיבולת נוספות מעבר לקיבולת המינימלית.
שיטות מומלצות לשימוש בהתאמה אוטומטית לעומס
כשמשתמשים לראשונה במידרוג אוטומטי, צריך להגדיר את מספר המשבצות למידרוג אוטומטי למספר משמעותי על סמך הביצועים הקודמים והצפויים. אחרי שיוצרים את ההזמנה, חשוב לעקוב באופן פעיל אחרי שיעור הכשלים, הביצועים והחיוב, ולשנות את מספר המשבצות של התאמה אוטומטית לעומס לפי הצורך.
לפני שהמידרוג האוטומטי מקטין את מספר המכונות, הוא ממתין דקה אחת לפחות. לכן חשוב להגדיר את המספר המקסימלי של משבצות שניתן לשנות את הגודל שלהן באופן אוטומטי, כדי ליצור איזון בין הביצועים לבין העלות. אם מספר המשבצות המקסימלי להרחבה אוטומטית גדול מדי והעבודה יכולה להשתמש בכל המשבצות כדי להשלים עבודה תוך שניות, עדיין תחויבו על המשבצות המקסימליות למשך דקה שלמה. אם תורידו את מספר המשבצות המקסימלי למחצית מהמספר הנוכחי, ההזמנה תותאם למספר נמוך יותר והעבודה תוכל להשתמש ביותר
slot_secondsבמהלך אותה דקה, וכך תצמצמו את הבזבוז. כדי לקבל עזרה בקביעת הדרישות שלכם לגבי משבצות, אפשר לעיין במאמר מעקב אחרי ביצועי העבודות. דרך נוספת לקבוע את מספר המקומות שאתם צריכים מפורטת במאמר הצגת המלצות למקומות במהדורות.לפעמים השימוש במשבצות יכול לחרוג מהסכום של המשבצות הבסיסיות בתוספת המשבצות המותאמות. לא תחויבו על שימוש במשבצות שגדול מהשימוש הבסיסי בתוספת המשבצות המותאמות.
מידרוג אוטומטי יעיל במיוחד לעומסי עבודה כבדים שפועלים לאורך זמן, כמו עומסי עבודה עם כמה שאילתות מקבילות. מומלץ להימנע משליחת שאילתות אחת בכל פעם, כי כל שאילתה משנה את גודל ההזמנה, והיא תישאר בגודל הזה למשך דקה לפחות. אם אתם שולחים שאילתות באופן רציף ויוצרים עומס עבודה קבוע, הגדרת בסיס ורכישת התחייבות יספקו לכם קיבולת קבועה במחיר מוזל.
השימוש בהתאמה אוטומטית לעומס ב-BigQuery כפוף לזמינות הקיבולת. מערכת BigQuery מנסה לענות על דרישות הקיבולת של הלקוחות על סמך נתוני שימוש היסטוריים. כדי להשיג ערבויות לקיבולת, אפשר להגדיר בסיס אופציונלי למשבצת, שהוא מספר המשבצות המובטחות בהזמנה. כשמשתמשים בתוכנית הבסיסית, המשבצות זמינות באופן מיידי ומשלמים עליהן בין אם משתמשים בהן ובין אם לא. כדי לוודא שיש קיבולת זמינה לביקוש גדול ולא אורגני, כמו בחגים שבהם יש תנועה גבוהה, מומלץ לפנות אל צוות BigQuery כמה שבועות מראש.
תמיד יש חיוב על משבצות בסיסיות. אם התחייבות לקיבולת פגה, יכול להיות שתצטרכו לשנות ידנית את מספר המשבצות הבסיסיות בהזמנות כדי למנוע חיובים לא רצויים. לדוגמה, נניח שיש לכם התחייבות לשנה עם 100 משבצות ושריינתם 100 משבצות בסיסיות. המחויבות מסתיימת ואין תוכנית לחידוש המינוי. אחרי שתקופת ההתחייבות מסתיימת, אתם משלמים על 100 מקומות בסיסיים בתעריף תשלום לפי שימוש.
מעקב אחרי התאמה אוטומטית לעומס
מידע על מעקב אחרי השימוש במשבצות וביצועי העבודות באמצעות שינוי גודל אוטומטי זמין במאמר מעקב אחרי שינוי גודל אוטומטי.
שימוש מוגזם ביחידות קיבולת (Slot)
אם משימה תופסת משבצות זמן יותר מדי זמן, היא עלולה לקבל נתח לא הוגן של משבצות זמן. כדי למנוע עיכובים, BigQuery מאפשר לעבודות אחרות לשאול משבצות נוספות, וכך נוצרים פרקי זמן שבהם השימוש הכולל במשבצות גבוה מהקיבולת שצוינה. כל שימוש עודף במשבצות משויך רק למשימות שמקבלות יותר מהחלק ההוגן שלהן.
לא נחייב אתכם ישירות על החריגה ממספר המקומות. במקום זאת, העבודות ממשיכות לפעול ולצבור שימוש במשבצות בהתאם לחלק היחסי שלהן, עד שכל השימוש העודף שלהן מכוסה על ידי הקיבולת שהוקצתה. משבצות עודפות לא נכללות בשימוש במשבצות שמופיע בדוחות, למעט נתונים סטטיסטיים מפורטים מסוימים של ביצוע.
שימו לב: יכול להיות שיהיו מקרים שבהם המערכת תשאיל מראש משבצות זמן כדי לצמצם עיכובים עתידיים ולספק יתרונות אחרים, כמו הפחתת השונות בעלות של משבצות זמן והפחתת זמן האחזור של הזנב. ההשאלה של משבצות מוגבלת לחלק קטן מקיבולת המשבצות הכוללת.