הסבר על מיקומים
יחידת קיבולת של BigQuery היא יחידת מחשוב וירטואלית שמשמשת את BigQuery להרצת שאילתות SQL, קוד Python או סוגים אחרים של עבודות. במהלך ההפעלה של שאילתה, BigQuery קובע באופן אוטומטי כמה משבצות נעשה שימוש בשאילתה. מספר המשבצות שנעשה בהן שימוש תלוי בכמות הנתונים שעוברים עיבוד, במורכבות של השאילתה ובמספר המשבצות שזמינות. באופן כללי, גישה ליותר משבצות מאפשרת להריץ יותר שאילתות בו-זמנית, והשאילתות המורכבות יכולות לרוץ מהר יותר. אי אפשר לשנות באופן ידני את מספר הסלוטים שמשמשים את BigQuery להפעלת שאילתות.
תמחור על פי דרישה ותמחור על בסיס קיבולת
כל השאילתות משתמשות במשבצות, אבל יש שתי אפשרויות לתמחור השימוש: מודל התמחור על פי דרישה או מודל התמחור לפי קיבולת.
כברירת מחדל, אתם מחויבים לפי המודל של שימוש בפועל. במודל הזה, אתם מחויבים על כמות הנתונים שעובדו (נמדדת ב-TiB) על ידי כל שאילתה. בפרויקטים שבהם נעשה שימוש במודל על פי דרישה, חלות מגבלות על מספר המשבצות לכל פרויקט ולכל ארגון, עם יכולת זמנית של שימוש במשבצות מעבר למגבלה. רוב המשתמשים במודל על פי דרישה חושבים שמגבלות הקיבולת של המשבצות מספיקות. עם זאת, בהתאם לעומס העבודה, גישה ליותר משבצות עשויה לשפר את ביצועי השאילתות. כדי לבדוק את השימוש במשבצות בחשבון, אפשר לעיין במאמר מעקב אחרי המצב, ניצול המשאבים והעבודות.
במודל מבוסס-קיבולת, אתם משלמים על קיבולת המשבצות שהוקצתה לשאילתות שלכם לאורך זמן. במודל הזה יש לכם שליטה מפורשת על הקיבולת הכוללת של משבצות. אתם בוחרים במפורש את מספר המשבצות שבהן תרצו להשתמש באמצעות הזמנה. אפשר לציין את מספר המשבצות בהזמנה כסכום בסיסי שתמיד מוקצה, או כסכום שמוקצה לפי הצורך באמצעות שינוי גודל אוטומטי. הקיבולת של הזמנות עם משבצות להתאמה אוטומטית לעומס (automatic scaling) גדלה כדי להתאים לדרישות של עומס העבודה. מערכת BigQuery מקצה יחידות קיבולת ככל שהעומסים משתנים. כך תוכלו להגדיר את מספר המשבצות בהזמנה על סמך הביצועים או האופי הקריטי של עומס העבודה שמשתמש בהזמנה.
ביצוע שאילתות באמצעות משבצות
כש-BigQuery מריץ משימת שאילתה, הוא ממיר את הצהרת ה-SQL לתוכנית ביצוע, שמורכבת מסדרה של שלבים בשאילתה. בכל שלב יש קבוצה של שלבי ביצוע. ב-BigQuery נעשה שימוש בארכיטקטורה מקבילית מבוזרת להרצת שאילתות. שלבים מדמים את יחידות העבודה שאפשר לבצע במקביל. הנתונים מועברים בין השלבים באמצעות ארכיטקטורת ערבוב מבוזר, שמוסברת בפירוט בפוסט הזה בבלוג.Google Cloud
הביצוע של שאילתות 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 מקצה באופן מיידי יחידות קיבולת פנויות להזמנה שהוקצתה להן, כשצריך אותן. אם יש משבצות פנויות שהיו בשימוש של הזמנה אחרת, המערכת תפנה אותן במהירות אם הן נדרשות להזמנה המקורית. מכיוון שההפסקה הזמנית הזו לא מתבצעת באופן מיידי, יכול להיות שיהיו תקופות קצרות שבהן יחידות קיבולת (Slots) בלי פעילות לא יחולקו באופן שווה בין המקומות השמורים, אבל 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 יחידות קיבולת (Slot): 100 יחידות קיבולת (Slot) בסיסיות ועוד 500 יחידות קיבולת (Slot) בלי פעילות.
בזמן ש-query_b פועל, נניח שמריצים את query_a ב-project_a שיכול להשתמש ב-500 משבצות.
- מכיוון ששוריינו לך 500 משבצות בסיסיות ל-
project_a,query_aהשימוש במשבצות מתחיל באופן מיידי ומוקצות לך 500 משבצות. - מספר המשבצות שהוקצו ל-
query_bיורד במהירות ל-100 משבצות בסיסיות. - שאילתות נוספות מופעלות ב
project_bומשתמשות ב-100 המשבצות האלה. אם בשאילתות הבאות אין מספיק משבצות פנויות כדי להתחיל, הן יתווספו לתור עד שהשאילתות שפועלות יסתיימו ומשבצות יהפכו לזמינות.
בדוגמה הזו, אם project_b הוקצה למקום שמור ללא יחידות קיבולת בסיסיות או התאמה אוטומטית לעומס, ל-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. בנוסף, אי אפשר להשתמש ביחידות קיבולת (Slots) פנויות ממקומות שמורים אחרים במשימות האלה.
הוגנות מבוססת-הזמנה
בשיטה 'הוגנות מבוססת-מקום שמור', מערכת BigQuery נותנת עדיפות ומקצה יחידות קיבולת פנויות באופן שווה לכל המקומות השמורים באותו פרויקט אדמין, בלי קשר למספר הפרויקטים שמריצים משימות בכל מקום שמור. כל הזמנה מקבלת חלק דומה מהקיבולת הזמינה במאגר המשבצות הפנויות, ואז המשבצות שלה מחולקות באופן הוגן בין הפרויקטים שלה. התכונה הזו נתמכת רק במהדורות Enterprise או Enterprise Plus.
בתרשים הבא אפשר לראות איך יחידות קיבולת פנויות מחולקות בלי שההגדרה 'הוגנות מבוססת-הזמנה' מופעלת:
בתרשים הזה, משבצות זמן פנויות מחולקות באופן שווה בין הפרויקטים.
אם לא מפעילים את התכונה 'הקצאה הוגנת על בסיס הזמנה', המשבצות הפנויות יחולקו באופן שווה בין הפרויקטים בהזמנות.
בתרשים הבא אפשר לראות איך משבצות זמן פנויות מחולקות כשההגדרה 'הוגנות מבוססת-הזמנות' מופעלת:
בתרשים הזה, משבצות זמן פנויות מחולקות באופן שווה בין ההזמנות, ולא בין הפרויקטים.
אם מפעילים את התכונה 'הקצאת משאבים הוגנת על בסיס הזמנות', המשבצות הפנויות מחולקות באופן שווה בין ההזמנות.
כשמפעילים את התכונה 'הוגנות מבוססת-הזמנה', כדאי לבדוק את צריכת המשאבים כדי לנהל את זמינות המשבצות ואת ביצועי השאילתות.
Avoid relying solely on idle slots for production workloads with strict time requirements - these jobs must use baseline or autoscaled slots. מומלץ להשתמש במשבצות זמן פנויות למשימות בעדיפות נמוכה יותר, כי יכול להיות שהמערכת תבטל את המשבצות האלה בכל שלב.
התאמה אוטומטית של יחידות קיבולת (Slot) לעומס
בקטע הבא מוסבר על יחידות קיבולת שניתנות להתאמה אוטומטית לעומס ואיך הן פועלות עם מקומות שמורים.
שימוש במקומות שמורים עם התאמה אוטומטית לעומס
לא צריך לרכוש התחייבויות לשימוש ביחידות קיבולת (Slot) לפני שיוצרים מקומות שמורים של התאמה אוטומטית לעומס (automatic scaling). התחייבויות לשימוש ביחידות קיבולת מספקות תעריף מוזל על יחידות קיבולת שנעשה בהן שימוש באופן עקבי, אבל הן אופציונליות במקומות שמורים עם התאמה אוטומטית לעומס. כדי ליצור מקום שמור עם התאמה אוטומטית לעומס, צריך להקצות למקום השמור מספר מקסימלי של יחידות קיבולת (הגודל המקסימלי של המקום השמור). כדי לזהות את המספר המקסימלי של משבצות להתאמה אוטומטית לעומס, מפחיתים את הגודל המקסימלי של ההזמנה מכל משבצות הבסיס האופציונליות שהוקצו להזמנה.
כשיוצרים מקומות שמורים עם התאמה אוטומטית לעומס, חשוב לקחת בחשבון את הנקודות הבאות:
- מערכת BigQuery מרחיבה את ההזמנות כמעט באופן מיידי עד שהיא מגיעה למספר יחידות הקיבולת שנדרש להרצת המשימות, או עד שהיא מגיעה למספר המקסימלי של יחידות הקיבולת שזמינות להזמנה. תמיד מתבצעת התאמה אוטומטית של מספר המשבצות כך שיהיה כפולה של 50.
- הגדלת הקיבולת מבוססת על השימוש בפועל, והיא מעוגלת כלפי מעלה למרווח של 50 משבצות.
- המשבצות שנוספו אוטומטית יחויבו לפי תמחור של קיבולת מחשוב במהדורות המשויכות, בזמן ההגדלה. החיוב הוא על מספר המשבצות שהוגדל, ולא על מספר המשבצות שבשימוש. החיוב הזה חל גם אם המשימה שגורמת ל-BigQuery להגדיל את הקיבולת נכשלת. לכן, לא מומלץ להשתמש בסכימת המידע על משרות כדי להתאים את החיוב. במקום זאת, אפשר לעיין במאמר בנושא מעקב אחרי שינוי גודל אוטומטי באמצעות סכימת מידע.
- מספר המשבצות תמיד גדל בכפולות של 50, אבל יכול להיות שהוא יגדל ביותר מ-50 משבצות בבת אחת. לדוגמה, אם עומס העבודה שלכם דורש 450 יחידות קיבולת נוספות, מערכת BigQuery יכולה לנסות להגדיל את הקיבולת ב-450 יחידות קיבולת בבת אחת כדי לעמוד בדרישת הקיבולת.
- הקיבולת של BigQuery מצטמצמת כשהמשימות שמשויכות להזמנה לא צריכות יותר את הקיבולת. כברירת מחדל, הקיבולת מחויבת לפי שניות, עם משך מינימלי של דקה אחת. אתם יכולים להפעיל את התאמת הקיבולת הדינמית ב-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 יכול להקטין את הקיבולת כמה פעמים ברציפות בלי שיידרש חלון הקטנה חדש.
שינוי גודל דינמי ב-BigQuery
התכונה 'שינוי קיבולת דינמי ב-BigQuery' מסירה את משך הזמן המינימלי של דקה אחת שנדרש על ידי התאמה אוטומטית לעומס רגיל, ומשנה את קיבולת יחידות הקיבולת שלכם משנייה לשנייה. התכונה הזו לא משנה את הגידולים של 50 משבצות בפריסה.
כדי להתאים במהירות לביקוש להזמנות, שינוי הגודל הדינמי ב-BigQuery משפיע על חלוקת משבצות פנויות בין הזמנות במרווחי זמן קצרים, וכתוצאה מכך, מספר המשבצות הפנויות שמוקצות להזמנה יהיה קצת יותר או קצת פחות מהחלק היחסי המדויק שלה.
הוראות להפעלת התכונה הזו מופיעות במאמר עדכון הזמנות.
אם משתמשים בניהול תוכנית התאוששות מאסון (DR) למקומות שמורים, צריך להפעיל את התכונה 'התאמה לעומס (scaling) דינמית ב-BigQuery' באזורים הראשי והמשני כדי להבטיח חיוב לפי שניות אחרי יתירות כשל.
מידע נוסף על עבודה עם התאמה אוטומטית לעומס זמין במאמר ניהול מקומות שמורים של עומסי עבודה.
שימוש בהזמנות עם משבצות זמן בסיסיות ומשבצות זמן שמתאימות את עצמן לעומס
בנוסף לציון הגודל המקסימלי של ההזמנה, אפשר גם לציין מספר בסיסי של משבצות לכל הזמנה. הבסיס הוא המספר המינימלי של משבצות שתמיד יוקצו להזמנה, ותמיד תחויבו עליהן. יחידות קיבולת להתאמה אוטומטית לעומס מתווספות רק אחרי שכל יחידות הקיבולת הבסיסיות (ויחידות קיבולת בלי פעילות, אם יש) נוצלו. אפשר לשתף יחידות קיבולת (Slot) בסיסיות פנויות בהזמנה אחת עם הזמנות אחרות שזקוקות לקיבולת.
אפשר להגדיל את מספר המשבצות הבסיסיות בהזמנה כל כמה דקות. אם רוצים להקטין את מספר המשבצות הבסיסיות, אפשר לעשות זאת רק פעם בשעה אם שיניתם לאחרונה את קיבולת המשבצות הבסיסיות ומספר המשבצות הבסיסיות גדול ממספר המשבצות המובטחות. אחרת, אפשר להקטין את מספר המשבצות הבסיסי כל כמה דקות.
המשבצות של בסיס הנתונים וההתאמה האוטומטית לעומס נועדו לספק קיבולת על סמך עומס העבודה האחרון שלכם. אם אתם צופים עומס עבודה גדול ששונה מאוד מעומסי העבודה שהיו לכם בעבר הקרוב, מומלץ להגדיל את קיבולת הבסיס לפני האירוע, במקום להסתמך על התאמה אוטומטית של משבצות לכיסוי קיבולת עומס העבודה. אם נתקלתם בבעיה בהגדלת קיבולת הבסיס, המתינו 15 דקות ונסו לשלוח את הבקשה שוב.
אם במקום השמור אין יחידות קיבולת בסיסיות או שהוא לא מוגדר להשאלה של יחידות קיבולת לא פעילות ממקומות שמורים אחרים, מערכת BigQuery תנסה להגדיל את הקיבולת. אחרת, צריך להשתמש בכל משבצות הבסיס לפני שמגדילים את מספר המשבצות.
הזמנות משתמשות במשבצות זמן ומוסיפות אותן לפי סדר העדיפות הבא:
- משבצות זמן בסיסיות.
- שיתוף משבצות זמן פנויות (אם האפשרות מופעלת). אפשר לשתף בהזמנות רק משבצות בסיס לא פעילות או משבצות שנקבעו מראש מהזמנות אחרות שנוצרו באותו מהדורה ובאותו אזור.
- שינוי גודל אוטומטי של מיקומי מודעות.
בדוגמה הבאה, מספר המשבצות גדל בהתאם לכמות בסיסית שצוינה. ההזמנות של etl ושל dashboard כוללות נפח בסיסי של 700 ו-300 משבצות בהתאמה.
בדוגמה הזו, אפשר להגדיל את המקום השמור etl ל-1,300 יחידות קיבולת (700 יחידות קיבולת בסיסיות ועוד 600 יחידות קיבולת של התאמה אוטומטית לעומס). אם לא נעשה שימוש בהזמנה dashboard, ההזמנה etl יכולה להשתמש ב-300 המשבצות מההזמנה dashboard אם לא מופעלת שם אף משימה, וכך להגיע למקסימום של 1,600 משבצות אפשריות.
הזמנת dashboard יכולה להתרחב ל-1,100 יחידות קיבולת (300 יחידות קיבולת בסיסיות ועוד 800 יחידות קיבולת להתאמה אוטומטית לעומס). אם המקום השמור etl לא פעיל בכלל, אפשר להגדיל את המקום השמור dashboard עד למקסימום של 1,800 יחידות קיבולת (300 יחידות קיבולת בסיסיות, 800 יחידות קיבולת של התאמה אוטומטית לעומס ו-700 יחידות קיבולת לא פעילות במקום השמור etl).
אם etl ההזמנה דורשת יותר מ-700 משבצות בסיסיות, שתמיד זמינות, המערכת מנסה להוסיף משבצות באמצעות השיטות הבאות, לפי הסדר:
- 700 משבצות זמן בסיסיות.
- שיתוף יחידות קיבולת פנויות עם 300 יחידות הקיבולת הבסיסיות בהזמנת
dashboard. ההזמנה שלכם משתפת רק משבצות זמן פנויות בסיסיות עם הזמנות אחרות שנוצרו באותה מהדורה. - הגדלת מספר המקומות ב-600 נוספים עד לגודל ההזמנה המקסימלי.
שימוש בהתחייבויות ליחידות קיבולת
בדוגמה הבאה מוצגות יחידות קיבולת (Slots) בהתאמה אוטומטית לעומס (Autoscaling) באמצעות התחייבויות לקיבולת.
בדומה לנתוני הבסיס של הזמנות, התחייבויות למשבצות מאפשרות להקצות מספר קבוע של משבצות שזמינות לכל ההזמנות. בניגוד למשבצות בסיסיות, אי אפשר להקטין את המחויבות במהלך תקופת החוזה. התחייבויות לשימוש במשבצות הן אופציונליות, אבל הן יכולות לחסוך בעלויות אם נדרשות משבצות בסיסיות לתקופות ארוכות. התחייבויות ליחידות קיבולת (Slot) משמשות לכיסוי יחידות קיבולת בסיסיות להזמנות שלכם. אחרי כן, כל קיבולת של יחידות קיבולת שלא נעשה בהן שימוש תשותף כיחידות קיבולת פנויות בין שאר המקומות השמורים. התחייבויות ליחידות קיבולת לא חלות על יחידות קיבולת שניתנות להתאמה אוטומטית לעומס. כדי לוודא שתקבלו את המחיר המוזל על ההתחייבות לשימוש במשבצות, חשוב לוודא שההתחייבות לשימוש במשבצות מספיקה לכיסוי משבצות הבסיס.
בדוגמה הזו, אתם מחויבים בתעריף מוגדר מראש על משבצות הקיבולת שהתחייבתם להשתמש בהן. תחויבו לפי התעריף של ההתאמה האוטומטית לעומס על מספר יחידות הקיבולת (Slots) של ההתאמה האוטומטית לעומס אחרי שההתאמה האוטומטית לעומס מופעלת והמקומות השמורים נמצאים במצב של הרחבה. במקרה של קצב שינוי גודל אוטומטי, החיוב הוא על מספר המשבצות שהוגדלו, ולא על מספר המשבצות שהיו בשימוש.
בדוגמה הבאה מוצגות הזמנות כשמספר המשבצות הבסיסיות גדול ממספר המשבצות המוקצות.
בדוגמה הזו, יש סך של 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 יחידות קיבולת (Slot) להתאמה אוטומטית לעומס (automatic scaling)).
- 1,000 משבצות בסיסיות שהוקצו להזמנה
etl.
מספר יחידות הקיבולת המקסימלי שזמינות למקום השמור שווה למספר יחידות הקיבולת של Baseline (1,000) בתוספת מספר יחידות הקיבולת שאינן בשימוש שמוקצות למקום השמור ולא מוקצות ליחידות הקיבולת של Baseline (1,600 יחידות קיבולת שנתיות פחות 1,000 יחידות קיבולת של Baseline = 600) בתוספת מספר יחידות הקיבולת של ההתאמה האוטומטית לעומס (500). לכן, מספר המשבצות המקסימלי הפוטנציאלי בהזמנה הזו הוא 2,100. המשבצות שגודלן נקבע אוטומטית הן משבצות נוספות מעבר לקיבולת המובטחת.
שיטות מומלצות לשימוש בהתאמת קנה מידה אוטומטית
כשמשתמשים לראשונה בתכונה לשינוי גודל אוטומטי, צריך להגדיר את מספר המשבצות לשינוי גודל אוטומטי למספר משמעותי על סמך הביצועים הקודמים והצפויים. אחרי שיוצרים את המקום השמור, חשוב לעקוב באופן פעיל אחרי שיעור הכשלים, הביצועים והחיוב, ולשנות את מספר יחידות הקיבולת (Slots) של ההתאמה האוטומטית לעומס (automatic scaling) לפי הצורך.
למידרוג אוטומטי יש מינימום של דקה אחת לפני צמצום אנכית בהתאם לעומס, ולכן חשוב להגדיר את המספר המקסימלי של יחידות קיבולת שניתנות להתאמה אוטומטית לעומס כדי ליצור איזון בין הביצועים לעלות. אם מספר המשבצות המקסימלי של שינוי הגודל האוטומטי גדול מדי והעבודה יכולה להשתמש בכל המשבצות כדי להשלים עבודה תוך שניות, עדיין תחויבו על המשבצות המקסימליות למשך דקה שלמה. אם תורידו את מספר המשבצות המקסימלי למחצית מהמספר הנוכחי, ההזמנה תותאם למספר נמוך יותר והעבודה תוכל להשתמש ביותר
slot_secondsבמהלך אותה דקה, וכך תצמצמו את הבזבוז. כדי לקבל עזרה בקביעת הדרישות שלכם לגבי משבצות, אפשר לעיין במאמר בנושא מעקב אחרי ביצועי העבודות. דרך חלופית לקביעת הדרישות שלכם לגבי משבצות זמינות מפורטת במאמר הצגת המלצות לגבי משבצות זמינות במהדורה.השימוש במשבצות יכול לפעמים לחרוג מהסכום של משבצות הבסיס בתוספת המשבצות המותאמות. לא תחויבו על שימוש במשבצות שגדול יותר ממכסת הבסיס בתוספת המשבצות המותאמות.
הכלי לשינוי גודל אוטומטי יעיל במיוחד לעומסי עבודה כבדים שפועלים לאורך זמן, כמו עומסי עבודה עם כמה שאילתות מקבילות. מומלץ להימנע משליחת שאילתות אחת בכל פעם, כי כל שאילתה משנה את גודל ההזמנה, והיא תישאר בגודל הזה למשך דקה לפחות. אם אתם שולחים כל הזמן שאילתות שיוצרות עומס עבודה קבוע, הגדרת ערך בסיס ורכישת התחייבות יספקו לכם קיבולת קבועה במחיר מוזל.
השימוש בהגדלה אוטומטית של הקיבולת ב-BigQuery כפוף לזמינות הקיבולת. מערכת BigQuery מנסה לעמוד בביקוש של הלקוחות לקיבולת על סמך נתוני שימוש היסטוריים. כדי להשיג ערבויות לקיבולת, אפשר להגדיר בסיס אופציונלי למשבצת, שהוא מספר המשבצות המובטחות בהזמנה. כשמשתמשים בתוכנית הבסיסית, המשבצות זמינות באופן מיידי ומשלמים עליהן בין אם משתמשים בהן ובין אם לא. כדי לוודא שיש קיבולת זמינה לביקוש גדול ולא אורגני, כמו בחגים שבהם יש תנועה גבוהה, צריך לפנות אל צוות BigQuery כמה שבועות מראש.
תמיד יש חיוב על משבצות בסיסיות. אם התחייבות לקיבולת פגה, יכול להיות שתצטרכו לשנות ידנית את מספר המשבצות הבסיסיות בהזמנות כדי להימנע מחיובים לא רצויים. לדוגמה, נניח שיש לכם התחייבות לשנה עם 100 משבצות ושריינתם 100 משבצות בסיסיות. המחויבות מסתיימת ואין תוכנית חידוש. אחרי שתקופת ההתחייבות מסתיימת, אתם משלמים על 100 מקומות בסיסיים בתעריף תשלום לפי שימוש.
מעקב אחרי התאמה אוטומטית לעומס
מידע על מעקב אחרי השימוש ביחידות קיבולת (Slot) וביצועי העבודות באמצעות התאמה אוטומטית לעומס (automatic scaling) זמין במאמר מעקב אחרי התאמה אוטומטית לעומס (automatic scaling).
שימוש מופרז ביחידות קיבולת (Slot)
אם עבודה תופסת משבצות זמן יותר מדי זמן, היא עלולה לקבל נתח לא הוגן של משבצות זמן. כדי למנוע עיכובים, BigQuery מאפשר לעבודות אחרות לשאול משבצות נוספות, וכך נוצרים פרקי זמן שבהם השימוש הכולל במשבצות גבוה מהקיבולת שצוינה. כל שימוש עודף במשבצות מוקצה רק לעבודות שמקבלות יותר מהחלק ההוגן שלהן.
לא נחייב אתכם ישירות על החריגה ממספר המקומות. במקום זאת, העבודות ממשיכות לפעול ולצבור שימוש במשבצות בהתאם לחלק היחסי שלהן, עד שכל השימוש העודף שלהן מכוסה על ידי הקיבולת שהוקצתה. משבצות עודפות לא נכללות בשימוש במשבצות שמופיע בדוחות, למעט נתונים סטטיסטיים מפורטים מסוימים של ביצוע.
שימו לב: יכול להיות שיהיו מקרים שבהם המערכת תשאיל מראש משבצות זמן כדי להקטין את הסיכוי לעיכובים בעתיד, וכדי לספק יתרונות אחרים כמו הפחתת השונות בעלות של משבצות זמן והפחתת זמן האחזור של הזנב. ההשאלה של משבצות מוגבלת לחלק קטן מקיבולת המשבצות הכוללת.