הסבר על הזמנות

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

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

הזמנות של יחידות קיבולת (Slot)

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

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

הקצאות של הזמנות

כדי להשתמש במשבצות שהוקצו במאגר, צריך להקצות אותו לפרויקט, לתיקייה או לארגון אחד או יותר. כשמשימה בפרויקט פועלת, היא משתמשת ב-slots מההזמנה שהוקצתה לה. משאבים יכולים לרשת הקצאות מההורה שלהם בCloud de Confiance by S3NS היררכיית המשאבים. אם פרויקט לא מוקצה להזמנה, הוא מקבל בירושה את ההקצאה של תיקיית ההורה או של הארגון, אם הם קיימים.

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

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

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

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

• ‫QUERY: משתמשים בהזמנה הזו למשימות של שאילתות לא מתמשכות, כולל שאילתות SQL,‏ DDL,‏ DML ו-BigQuery ML (מודלים מובנים).

• ‫AUTOMATIC_MATERIALIZED_VIEW_REFRESH: שימוש במאגר הזה למשימות של רענון אוטומטי של תצוגות מהותיות.

• ‫BACKGROUND_CHANGE_DATA_CAPTURE: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי להריץ את משימות הרקע של הטמעת CDC ב-BigQuery. אי אפשר להזמין BACKGROUND_CHANGE_DATA_CAPTURE במהדורת Standard.

• ‫BACKGROUND_COLUMN_METADATA_INDEX: משתמשים בהזמנה הזו כשבוחרים להשתמש בהזמנה משלכם כדי להריץ את המשימות ברקע של שמירת המטא-נתונים של BigLake במטמון. אפשר להשתמש בהזמנה הזו גם כשמשכפלים מסדי נתונים של מקורות ל-BigQuery באמצעות פעולות החלה ברקע של Datastream. אי אפשר להזמין BACKGROUND_COLUMN_METADATA_INDEX במהדורת Standard.

• ‫BACKGROUND_SEARCH_INDEX_REFRESH: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי להריץ את משימות הרקע לניהול האינדקס של חיפוש ב-BigQuery. אי אפשר להזמין BACKGROUND_SEARCH_INDEX_REFRESH במהדורת Standard.

• ‫BACKGROUND: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי לשכפל מסדי נתונים של מקורות ל-BigQuery באמצעות פעולות החלה ברקע של Datastream. מקום שמור זה ישמש גם עבור העבודות המתוארות על ידי BACKGROUND_CHANGE_DATA_CAPTURE, ‏BACKGROUND_COLUMN_METADATA_INDEX ו-BACKGROUND_SEARCH_INDEX_REFRESH כחלופה, אם לא קיים מקום שמור ספציפי יותר עבור סוגי העבודות האלה. הזמנות של BACKGROUND לא זמינות במהדורת Standard.

• ‫CONTINUOUS: שימוש בהזמנה הזו למשימות של שאילתות מתמשכות.

• ‫ML_EXTERNAL: משתמשים במקום השמור הזה לשאילתות של BigQuery ML CREATE MODEL שמשתמשות בשירותים חיצוניים ל-BigQuery. מידע נוסף מופיע במאמר הקצאת חריצים לעומסי עבודה של BigQuery ML. הזמנות של ML_EXTERNAL לא זמינות במהדורת Standard.

• ‫PIPELINE: שימוש במאגר הזה למשימות טעינה וחילוץ.

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

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

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

הקצאת הזמנות בצורה גמישה

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

כדי להשתמש במאגר כשמריצים את השאילתה, צריך שתהיה לכם גישה למאגר.

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

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

שילוב של הזמנות עם חיוב על פי דרישה

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

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

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

ציון פרויקט ניהול

כשיוצרים התחייבויות והזמנות, הן משויכות לפרויקט ב- Cloud de Confiance by S3NS . הפרויקט הזה מנהל את משאבי ההזמנות ב-BigQuery, והוא המקור העיקרי לחיוב על המשאבים האלה. הפרויקט הזה לא חייב להיות אותו פרויקט שמכיל את המשימות או את מערכי הנתונים שלכם ב-BigQuery.

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

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

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

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

שימוש בכמה פרויקטים לניהול

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

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

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

בדף Workload management במסוף BigQuery Cloud de Confiance , אתם יכולים לראות את ההזמנות וההתחייבויות רק של הפרויקט האדמיניסטרטיבי שנבחר.

מכסות לפרויקטים וכללי מדיניות לתזמון

כדי לבקש תמיכה או לשלוח משוב על התכונה הזו, אפשר לפנות לכתובת bigquery-wlm-feedback@google.com.

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

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

אלה סוגי המכסות לפרויקטים שנתמכים:

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

• מקסימום בו-זמניות: מגביל את מספר השאילתות בו-זמנית שמותרות לפרויקט שהוקצה בתוך ההזמנה.

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

לשינוי ההגדרות האלה יש את המגבלות הבאות:

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

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

התאמת הגודל של הזמנות של יחידות קיבולת (Slot)

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

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

אתם יכולים להתנסות עם משבצות בסיסיות ומשבצות להתאמה לעומס (autoscaling) כדי לקבוע את ההגדרה הטובה ביותר של משבצות. לדוגמה, אתם יכולים לבדוק את עומס העבודה עם 500 משבצות בסיסיות, אחר כך עם 1,000, 1,500 ו-2,000, ולראות את ההשפעה על הביצועים.

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

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

אתם יכולים גם לבדוק את השימוש הנוכחי ב-slots בפרויקטים שלכם, יחד עם המחיר החודשי שבחרתם לשלם. לעומסי עבודה על פי דרישה יש מכסה גמישה של 2,000 חריצים, אבל חשוב לבדוק כמה חריצים נמצאים בשימוש בפועל בפרויקטים שלכם באמצעות תצוגות INFORMATION_SCHEMA.JOBS*, ‏Cloud Logging, ‏Jobs API או יומני הביקורת של BigQuery. מידע נוסף זמין במאמר מעקב אחרי הזמנות.

ניהול עומסי עבודה באמצעות הזמנות

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

לדוגמה, נניח שיש לכם קיבולת כוללת של 1,000 חריצים שרכשתם בהתחייבות, ושלושה סוגים של עומסי עבודה: מדעי הנתונים, ELT ו-BI.

• אתם יכולים ליצור הזמנה של ds עם 500 חריצים, ולהקצות את כל הפרויקטים הרלוונטיים של Cloud de Confiance להזמנה של ds.
• אתם יכולים ליצור הזמנה של elt עם 300 מיקומים, ולהקצות eltלה פרויקטים שאתם משתמשים בהם לעומסי עבודה של ELT.
• אתם יכולים ליצור הזמנה של bi עם 200 משבצות, ולהקצות לה bi פרויקטים שמחוברים לכלי ה-BI שלכם.

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

ניהול הזמנות באזורים שונים

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

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

ניהול הזמנות בארגונים מורכבים

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

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

אם אתם משתמשים בכמה ארגונים ב- Cloud de Confiance , אתם צריכים ליצור לפחות פרויקט ניהול אחד לכל ארגון, ואז לנהל את ההזמנות וההתחייבויות של כל ארגון בפרויקט הניהול שקשור אליו. אי אפשר לשתף קיבולת בין ארגונים.

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

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

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

למשתמשים צריכה להיות ההרשאה reservations.use כדי לשנות את ברירת המחדל של הקצאת המשאבים למשימה שלהם, או כדי לאלץ את המשימה לפעול על פי דרישה כשהקצאת המשאבים כבר קיימת בפרויקט. התפקידים roles/bigquery.resourceAdmin ו-roles/bigquery.resourceEditor כוללים את ההרשאה הזו. אתם יכולים לתת גישה למשתמשים, לקבוצות או לחשבונות שירות ספציפיים. אתם יכולים גם להגדיר כללי מדיניות על סמך מאפייני הזמנה כמו שם, כי תנאי IAM תומכים בבקרת גישה שמבוססת על מאפיינים.

כדי להעניק תנאי IAM על הזמנות, קראו את המאמר שליטה בגישה להזמנות.

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

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

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

• התחייבות ל-3 שנים. אתם רוכשים התחייבות לשלוש שנים. אחרי 3 שנים (1,095 ימים), אתם יכולים לבחור אם לחדש את התוכנית או לעבור לתוכנית התחייבות מסוג אחר.

בסוף תקופת ההתחייבות, ההתחייבות תתחדש בהתאם לתוכנית החידוש שנבחרה.

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

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

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

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

חידוש התחייבויות

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

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

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

לדוגמה, אם רכשתם התחייבות שנתית ב-5 באוקטובר 2019 בשעה 18:00, החיוב התחיל באותו רגע. אפשר למחוק או לחדש את ההתחייבות אחרי השעה 18:00 ב-4 באוקטובר 2020, בהתחשב בכך ששנת 2020 היא שנה מעוברת. אפשר לשנות את תוכניות החידוש לפני 4 באוקטובר 2020 בשעה 18:00, באופן הבא:

• אם בחרתם לחדש את ההתחייבות השנתית, ב-4 באוקטובר 2020 בשעה 18:00 ההתחייבות שלכם תתחדש לשנה נוספת.
• אם תבחרו לחדש את ההתחייבות לשלוש שנים, ב-4 באוקטובר 2020 בשעה 18:00 ההתחייבות תתחדש לשלוש שנים.

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

תפוגת ההתחייבות

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

אם רכשתם התחייבות בטעות או ביצעתם טעות בהגדרת ההתחייבות, תוכלו לבקש עזרה מCloud Customer Care.

מגבלות על הזמנות

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

יכולת חיזוי של הזמנות

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

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

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

הערך של ignore_idle_slots חייב להתאים למצב ההתאמה לעומס. אם מצב ההתאמה לעומס הוא ALL_SLOTS או IDLE_SLOTS_ONLY, הערך של ignore_idle_slots חייב להיות false. אם מצב ההתאמה לעומס הוא AUTOSCALE_ONLY, הערך של ignore_idle_slots חייב להיות true.

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

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

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

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

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

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

הדיאגרמה הבאה מציגה את אפשרויות ההגדרה השונות:

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

מגבלות

היכולת לחזות את ההזמנות כפופה למגבלות הבאות:

• האפשרות "חיזוי הזמנות" זמינה רק במהדורות Enterprise ו-Enterprise Plus, אלא אם בוחרים באפשרות AUTOSCALE_ONLY.

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

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

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

קבוצות של הזמנות

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

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

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

שיתוף של משבצות לא פעילות עם קבוצות של הזמנות

משבצות לא פעילות מחולקות באופן שווה בין הזמנות שלא מקובצות לבין קבוצות של הזמנות, ואז באופן שווה בתוך קבוצות של הזמנות.

בדוגמה הבאה יש שלוש הזמנות ו-1,200 משבצות לא פעילות. בלי קבוצות של הזמנות, לכל הזמנה יש חלק הוגן של 400 משבצות לא פעילות. כשמאגדים את הזמנות 1 ו-2, חלוקת המשבצות הלא פעילות משתנה. המשבצות הפנויות מחולקות קודם באופן שווה בין קבוצת ההזמנות לבין הזמנה 3 (600 משבצות פנויות לכל אחת). לאחר מכן, 600 המשבצות הלא פעילות של קבוצת ההזמנות מחולקות באופן שווה בין הזמנה 1 להזמנה 2.

מגבלות

קבוצות של הזמנות כפופות למגבלות הבאות:

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

• בפרויקט צריך להפעיל את האפשרות הוגנות מבוססת-הזמנה.

• לכל ההזמנות בקבוצה חייבת להיות אותה מהדורה.

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

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

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

פתרון בעיות שקשורות להזמנות

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

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

אם מופיעות שגיאות כמו Failed to allocate slots for reservation in the current system state או Failed to update reservation: Failed to allocate slots for reservation כשמנסים להוסיף עוד משבצות להזמנה, בדרך כלל מדובר בבעיה זמנית. כדי לפתור את הבעיה:

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

אם ניסיתם כמה פעמים וחיכיתם 30 דקות ועדיין מופיעה אותה הודעת שגיאה, פנו ל-Cloud Customer Care.

אין מספיק מכסה כדי להשלים את הבקשה הזו

אם הודעת השגיאה היא There is insufficient quota to complete this request, הבקשה חורגת ממגבלת המכסה שהוגדרה לפרויקט.

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

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

הזמנה שלא משמשת את BigQuery להרצת משימה

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

השאילתה וההזמנה נמצאות באזורים שונים

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

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

ההזמנה נוצרה, אבל הפרויקט לא הוקצה לה

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

אי-התאמה בסוג העבודה

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

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

שאילתות עם כמה הצהרות

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

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

אחזור תוצאות מהמטמון

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

פעולות לשינוי שורות של סימון נתונים שהשתנו (CDC)

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

זוהו בפרויקט הזמנות לא מזוהות

ל-BigQuery יש מקומות שמורים שמייצגים מאגר משותף של יחידות קיבולת בחינם לפעולות מסוימות ב-BigQuery.

default-pipeline

כברירת מחדל, טעינה או ייצוא של נתונים באצוות ב-BigQuery מתבצעים באמצעות מאגר משבצות משותף בחינם. כשבודקים את משימות הטעינה או החילוץ האלה, בשדה reservation מופיע הערך default-pipeline.

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