הסבר על מיקומים

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

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

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

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

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

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

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

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

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

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

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

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

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

כלכלה של משאבי יחידות קיבולת

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

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

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

לדוגמה,

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 ולבקשות של קיבולת לפי דרישה, כי המערכת מקצה משאבים קודם למהדורות ברמה גבוהה יותר.

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

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

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

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

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

תזמון הוגן ב-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 יתווספו לתור עד שיהיו משבצות פנויות.

שליטה בשיתוף משבצות זמן פנויות והגבלת השיתוף

כדי למנוע ממקום שמור ספציפי לשאול יחידות קיבולת (Slot) בלי פעילות ממקומות שמורים אחרים, צריך להגדיר את המאפיין ignore_idle_slots שלה כ-TRUE. שימו לב שההגדרה הזו שולטת רק בהשאלה ולא בהלוואה. הזמנה עם הערך true בפרמטר ignore_idle_slots לא יכולה יותר לשאול קיבולת, אבל היא עדיין יכולה להשאיל את המשבצות הפנויות שלה להזמנות אחרות שזקוקות להן. כל עוד הערך של ignore_idle_slots הוא false, אפשר להגדיר את מספר המשבצות בהזמנה כ-0 ועדיין תהיה גישה למשבצות שלא נעשה בהן שימוש.

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

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

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

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

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

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

בשיטה 'הוגנות מבוססת-מקום שמור', מערכת 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) לעומס

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

שימוש בהזמנות עם שינוי גודל אוטומטי

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

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

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

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

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

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

שימוש בהזמנות עם משבצות זמן בסיסיות ומשבצות זמן שמתאימות את עצמן לעומס

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

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

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

שימוש בהתחייבויות ליחידות קיבולת

בדוגמה הבאה מוצגים משבצות להקצאה אוטומטית של משאבים באמצעות התחייבויות לקיבולת.

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

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

שיטות מומלצות לשימוש בהתאמת קנה מידה אוטומטית

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

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

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

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

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

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

ניראות (observability)

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