הסבר על משבצות זמן

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

תמחור על פי דרישה ותמחור מבוסס-קיבולת

כל השאילתות משתמשות ב-slots, אבל יש שתי אפשרויות לחיוב על השימוש: מודל תמחור על פי דרישה או מודל תמחור מבוסס-קיבולת.

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

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

איך להימנע מעלויות לא צפויות על פי דרישה

כדי למנוע מפרויקטים שלא הוקצו או שנוצרו לאחרונה להשתמש בתמחור על פי דרישה כברירת מחדל, אתם יכולים לנהל את ההזמנות ב-BigQuery באמצעותGoogle Cloud היררכיית המשאבים, לפי השיטות הבאות:

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

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

הרצת שאילתות באמצעות משבצות

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

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

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

חיסכון במשאבים של משבצות זמן

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

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

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

לדוגמה,

1. בשלב של השאילתה נשלחת בקשה ל-2,000 חריצים, אבל רק 1,000 זמינים.
2. ‫BigQuery צורך את כל 1,000 המשבצות ומכניס לתור את 1,000 המשבצות האחרות.
3. לאחר מכן, אם 100 משבצות מסיימות את העבודה שלהן, הן אוספות באופן דינמי 100 יחידות עבודה מתוך 1,000 יחידות העבודה בתור. נשארו 900 יחידות של עבודה בתור.
4. לאחר מכן, אם 500 משבצות מסיימות את העבודה שלהן, הן אוספות באופן דינמי 500 יחידות עבודה מתוך 900 יחידות העבודה בתור. נשארו 400 יחידות של עבודה בתור.

יחידות הקיבולת של BigQuery נכנסות לתור אם הביקוש עולה על הזמינות

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

תעדוף קיבולת

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

1. ‫Enterprise Plus ו-Enterprise: ערכי בסיס וקיבולת מחויבת.
2. קיבולת מותאמת לעומס ב-Enterprise Plus.
3. קיבולת מותאמת אוטומטית במהדורת Enterprise.
4. מהדורת Standard וקיבולת על פי דרישה.

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

תזמון הוגן ב-BigQuery

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

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

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

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

תזמון הוגן ב-BigQuery

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

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

כדוגמה לתזמון הוגן, נניח שיש לכם את הגדרת ההזמנה הבאה:

• הזמנה A, עם 1,000 משבצות בסיסיות ללא התאמה אוטומטית לעומס (autoscaling)
• פרויקט A ופרויקט B, שמוקצים למקום שהזמנתם

תרחיש 1: בפרויקט A אתם מריצים את השאילתה A (שאילתה אחת בו-זמנית) שדורשת שימוש גבוה ב-slots, ובפרויקט B אתם מריצים 20 שאילתות בו-זמנית. למרות שיש בסך הכול 21 שאילתות שמשתמשות במאגר A, חלוקת ה-slots היא:

• פרויקט A מקבל 500 משבצות, ושאילתה A פועלת עם 500 משבצות.
• פרויקט B מקבל 500 מיקומים שמשותפים בין 20 השאילתות שלו.

תרחיש 2: בפרויקט A אתם מריצים את השאילתה A (שאילתה אחת בו-זמנית) שדורשת 100 מיקומים להרצה, ובפרויקט B אתם מריצים 20 שאילתות בו-זמנית. מכיוון ששאילתה A לא דורשת 50% מההזמנה, חלוקת ה-slots היא:

• פרויקט A מקבל 100 מיקומים, והשאילתה A פועלת עם 100 מיקומים.
• פרויקט B מקבל 900 מיקומים שמשותפים בין 20 השאילתות שלו.

לעומת זאת, נבחן את הגדרת ההזמנה הבאה:

• הזמנה B, שכוללת 1,000 משבצות בסיסיות ללא התאמה אוטומטית לעומס.
• ‫10 פרויקטים, שכולם מוקצים להזמנה B.

נניח שב-10 הפרויקטים פועלות שאילתות עם ביקוש מספיק ל-slots, אז כל פרויקט מקבל 1/10 מסך ה-slots שהוקצו (או 100 slots), בלי קשר למספר השאילתות שפועלות בכל פרויקט.

מכסות ומגבלות של משבצות זמן

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

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

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

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

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

משבצות זמן פנויות

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

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

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

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

לדוגמה, נניח שהגדרתם את ההזמנה הבאה:

• ‫project_a מוקצה ל-reservation_a, שיש לו 500 משבצות בסיסיות ללא התאמה אוטומטית לעומס.
• ‫project_b מוקצה ל-reservation_b, שיש לו 100 משבצות בסיסיות ללא התאמה אוטומטית לעומס.
• שני המקומות השמורים נמצאים באותו אזור ובאותו פרויקט אדמיניסטרטיבי, ואין פרויקטים אחרים שמוקצים למקומות השמורים האלה.

אתם מפעילים את query_b בproject_b. אם לא פועלת שאילתה ב-project_a, ל-query_b יש גישה ל-500 ה-slots הפנויים מ-reservation_a. בזמן ש-query_b עדיין פועלת, היא יכולה להשתמש בעד 600 חריצי עיבוד: 100 חריצי עיבוד בסיסיים ו-500 חריצי עיבוד לא פעילים.

נניח שאתם מריצים את query_a ב-project_a, שיכול להשתמש ב-500 חריצים, בזמן ש-query_b פועל.

• מכיוון שיש לכם 500 משבצות בסיסיות ששמורות ל-project_a, query_a מתחיל מיד ומוקצות לו 500 משבצות.
• מספר ה-slots שהוקצו ל-query_b יורד במהירות ל-100 slots בסיסיים.
• שאילתות נוספות שמופעלות ב-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 ועדיין תהיה גישה למשבצות שלא נוצלו.

בנוסף ל-ignore_idle_slots, אתם יכולים להשתמש במנגנונים הבאים כדי לנהל ולשלוט בשיתוף של משבצות לא פעילות בעומסי העבודה שלכם:

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

יש שתי הגבלות עיקריות על שיתוף משבצות זמן לא פעילות:

• אי אפשר לשתף משבצות לא פעילות בין הזמנות של מהדורות שונות.
• הקצאות מסוג ML_EXTERNAL הן חריגות, כי אי אפשר להפסיק לפני הזמן את המשבצות שמשמשות למשימות של יצירת מודלים חיצוניים של BigQuery ML. המשבצות בהזמנה עם סוגי ההקצאה ML_EXTERNAL ו-QUERY זמינות למשימות שאילתה אחרות רק כשהמשבצות לא תפוסות על ידי משימות ML_EXTERNAL. בנוסף, במשימות האלה אי אפשר להשתמש במשבצות לא פעילות מהזמנות אחרות.

הוגנות מבוססת-הזמנה

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

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

בתרשים הבא מוצג איך משבצות לא פעילות מופצות בלי שהוגדרה הוגנות מבוססת-הזמנה:

בתרשים הזה, משבצות לא פעילות משותפות באופן שווה בין הפרויקטים.

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

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

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

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

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

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

התאמה אוטומטית לעומס (autoscaling) של משבצות

בקטע הבא נסביר על התאמה אוטומטית לעומס של יחידות קיבולת (slots) ואיך היא פועלת עם מקומות שמורים.

שימוש בהזמנות עם התאמה אוטומטית לעומס (autoscaling)

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

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

• המערכת של BigQuery משנה את קנה המידה של ההזמנות כמעט באופן מיידי, עד שהיא מגיעה למספר ה-slots שנדרש כדי להריץ את המשימות, או למספר המקסימלי של ה-slots שזמינים להזמנה. יחידות הקיבולת תמיד מתאימות אוטומטית לעומס בכפולות של 50.
• בניגוד ל-baseline slots, ב-BigQuery לא מוקצים מראש autoscaling slots. הקיבולת הזו, שמגשרת בין מספר ברירת המחדל של ה-slots לבין הגודל המקסימלי של ההזמנה, תלויה בזמינות הנוכחית של המערכת. בתקופות של ביקוש גבוה, מגבלות הקיבולת עלולות לעכב את ההרחבה.
• ההרחבה מבוססת על השימוש בפועל, ומעוגלת כלפי מעלה למרווח הקרוב ביותר של 50 משבצות.
• החיוב על משבצות שהותאמו אוטומטית מתבצע לפי תמחור של קיבולת המחשוב במהדורה המשויכת, בזמן ההרחבה. החיוב הוא על מספר ה-slots שהוגדלו, ולא על מספר ה-slots שנעשה בהם שימוש. החיוב הזה חל גם אם המשימה שגורמת ל-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 מסירה את משך הזמן המינימלי של דקה אחת שנדרש בהתאמה סטנדרטית לעומס, ומתאימה את קיבולת ה-slots משנייה לשנייה. התכונה הזו לא משנה את ההגדלה של המשבצות ב-50 יחידות.

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

הוראות להפעלת התכונה הזו מפורטות במאמר עדכון הזמנות.

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

כדי ללמוד איך לעבוד עם התאמה אוטומטית לעומס (autoscaling), ראו ניהול הקצאות של עומסי עבודה.

שימוש בהזמנות עם משבצות בסיסיות ומשבצות להתאמה לעומס (autoscaling)

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

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

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

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

ההזמנות משתמשות במיקומי מודעות בדף ומוסיפות אותן לפי סדר העדיפויות הבא:

1. משבצות בסיסיות.
2. שיתוף משבצות לא פעילות (אם האפשרות מופעלת). הזמנות יכולות לשתף רק משבצות בסיסיות או משבצות מחויבות לא פעילות מהזמנות אחרות שנוצרו באותה מהדורה ובאותו אזור.
3. התאמה אוטומטית של משבצות.

בדוגמה הבאה, מספר המשבצות משתנה בהתאם לכמות בסיסית שצוינה. ההזמנות 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 משבצות בסיסיות, שתמיד זמינות, המערכת מנסה להוסיף משבצות באמצעות השיטות הבאות, לפי הסדר:

1. ‫700 משבצות בסיסיות.
2. שיתוף משבצות לא פעילות עם 300 משבצות בסיס בהזמנה dashboard. ההזמנה שלכם משתפת רק משבצות בסיסיות לא פעילות עם הזמנות אחרות שנוצרו באותה מהדורה.
3. הרחבה של 600 משבצות נוספות לגודל המקסימלי של ההזמנה.

שימוש בהתחייבויות ל-slots

בדוגמה הבאה מוצג שימוש בהתחייבויות לשימוש כדי להגדיל אוטומטית את מספר יחידות הקיבולת (slots) באמצעות התאמה אוטומטית לעומס (autoscaling).

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

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

בדוגמה הבאה מוצגות הזמנות שבהן מספר משבצות הבסיס גדול ממספר המשבצות המחויבות.

בדוגמה הזו, יש בסך הכול 1,000 משבצות בסיס בין שתי ההזמנות, 500 מההזמנה etl ו-500 מההזמנה dashboard. עם זאת, ההתחייבות מכסה רק 800 חריצים. במקרה כזה, ה-slots העודפים מחויבים לפי תעריף תשלום לפי שימוש (PAYG).

מספר המקומות המקסימלי

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

• התחייבות לקיבולת של 1,000 חריצים בשנה. המשבצות האלה מוקצות כמשבצות בסיסיות בהזמנה etl ובהזמנה dashboard.
• 700 משבצות בסיסיות שהוקצו להזמנה etl.
• ‫300 משבצות בסיסיות שהוקצו להזמנה dashboard.
• התאמה אוטומטית לעומס של יחידות קיבולת ל-600 במקום השמור etl.
• התאמה אוטומטית של מספר ה-slots ל-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). לכן, מספר ה-slots המקסימלי האפשרי בהזמנה הזו הוא 2,100. ה-slots שנוספים בהתאמה אוטומטית הם slots נוספים מעבר להתחייבות לקיבולת.

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

שיטות מומלצות להתאמה אוטומטית לעומס (autoscaling)

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

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

• לפעמים השימוש ב-slots יכול לחרוג מסכום ה-slots הבסיסיים וה-slots שהוגדלו. לא תחויבו על שימוש ב-slots מעבר למספר ה-slots הבסיסי בתוספת ה-slots שהוגדלו.

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

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

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

ניראות (observability)

במאמר מעקב אחרי התאמה אוטומטית לעומס מוסבר איך לעקוב אחרי השימוש בחריצים ואחרי ביצועי המשימות באמצעות התאמה אוטומטית לעומס.