מכסות ומגבלות

במאמר הזה מוסבר על מכסות ומגבלות המערכת של BigQuery.

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

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

מערכת המכסות ב-Cloud:

• עוקבת אחרי השימוש במוצרים ובשירותים של Google Cloud
• מגבילה את השימוש במשאבים האלה
• כוללת כלי שבאמצעותו אפשר לשלוח בקשות לשינוי המכסות ולשנות אותן אוטומטית

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

בדרך כלל, המכסות ב- Google Cloud הן ברמת הפרויקט. כלומר, השימוש במשאב מסוים בפרויקט כלשהו לא משפיע על המכסה שלכם בפרויקטים אחרים. ברמת הפרויקט ב- Google Cloud , המכסות משותפות לכל האפליקציות וכתובות ה-IP.

לסקירה כללית על מכסות ב-Cloud

למשאבי BigQuery יש גם מגבלות מערכת. שאי אפשר לשנות.

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

חישוב השימוש במכסת ה-slots

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

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

חידוש המכסה

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

שליחת בקשה להגדלת המכסה

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

כדי לקבל הדרכה מפורטת על תהליך הבקשה להגדלת המכסה במסוף Google Cloud , לחצו על תראו לי איך:

תראו לי איך

הגבלת השימוש במכסה

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

ההרשאות הנדרשות

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

פתרון בעיות

מידע על פתרון בעיות שקשורות למכסות ולמגבלות זמין במאמר פתרון בעיות שקשורות למכסות ב-BigQuery.

תעסוקה

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

משימות בהמתנה

ההגבלה הבאה חלה על משימות בהמתנה ב-BigQuery:

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

משימות של השאילתה

המכסות הבאות חלות על משימות שאילתה שנוצרות באופן אוטומטי על ידי הפעלת שאילתות אינטראקטיביות, שאילתות מתוזמנות ומשימות שנשלחות באמצעות ה-methods של ה-API‏ jobs.query ו-jobs.insert מסוג שאילתה.

למידע על פתרון בעיות, עיינו בדף פתרון הבעיות של BigQuery.

מכסה	ברירת מחדל	הערות
שימוש בשאילתות ביום	‫200 טבי-בייט (TiB)	המכסה הזו חלה רק על מודל התמחור של שאילתות על פי דרישה. בפרויקט שלכם אפשר להריץ שאילתות בנפח של עד 200TiB ביום. אפשר לשנות את המגבלה הזו בכל שלב. מידע נוסף על אמצעים לשליטה בעלויות זמין במאמר יצירת מכסות שאילתות בהתאמה אישית. הצגת המכסה במסוף Google Cloud
שימוש בשאילתות ביום לכל משתמש	ללא הגבלה	המכסה הזו חלה רק על מודל התמחור של שאילתות על פי דרישה. אין הגבלת ברירת מחדל על מספר ה-TiB בשאילתות שמשתמש יכול להריץ ביום. אפשר להגדיר את המגבלה בכל שלב. ללא קשר למגבלה לכל משתמש, סך השימוש של כל המשתמשים בפרויקט לא יכול לחרוג מהמגבלה היומית על השימוש בשאילתות. מידע נוסף על אמצעים לשליטה בעלויות זמין במאמר יצירת מכסות שאילתות בהתאמה אישית. הצגת המכסה במסוף Google Cloud
בייטים ליום של שאילתות לכמה מסדי נתונים ב-GoogleSQL בין אזורים	1TB	אם מיקום העיבוד של שאילתת BigQuery שונה ממיקום מופע Cloud SQL, השאילתה היא שאילתה חוצת-אזורים. הפרויקט יכול להריץ עד 1 TB של שאילתות חוצות-אזורים בכל יום. שאילתות מאוחדות ב-Cloud SQL הצגת המכסה ב Google Cloud מסוף
בייטים שהועברו ב-BigQuery Omni ביום	‫1 TB	אפשר להעביר עד 1 TB של נתונים ביום מקטגוריה של Amazon S3 או מ-Azure Blob Storage. הצגת המכסה ב Google Cloud מסוף
בייטים שהועברו ב-BigQuery Omni לכל משימה	‫60GB	גודל ההעברה המקסימלי לכל משימה הוא 60 GB כשמריצים הצהרות CREATE TABLE AS SELECT (CTAS) או INSERT INTO SELECT באזורי BigQuery Omni כדי לסנן נתונים במהלך העברה חוצת-עננים. המגבלה הזו חלה גם על צירופים ב-BigQuery Omni, שמריצים שאילתת Omni CTAS ברקע כדי להעביר נתונים לטבלה זמנית באזור שלכם ב-BigQuery. כדי לבקש הגדלה של המכסה, פנו לתמיכה. מידע נוסף זמין במאמר עלויות של צירוף ב-BigQuery Omni.
בייטים שהועברו על ידי שאילתות עם אחזור נתונים גלובלי ביום לכל זוג אזורים	180 TB	אפשר להעביר עד 180TB של נתונים ביום בין כל זוג אזורים באמצעות שאילתות עם אחזור נתונים גלובלי. כדי לבקש הגדלה של המכסות, פונים לתמיכה.
העתקת משימות של שאילתות עם אחזור נתונים גלובלי לכל פרויקט	10,000	אפשר להריץ עד 10,000 משימות העתקה בכל פרויקט כשמריצים שאילתות עם אחזור נתונים גלובלי שמעתיקות נתונים בין אזורים. שאילתה אחת עם אחזור נתונים גלובלי יכולה להפעיל כמה משימות העתקה. כדי לבקש הגדלה של המכסות צריך לפנות לתמיכה.
בייטים שהועברו על ידי משימת העתקה אחת בשאילתה עם אחזור נתונים גלובלי	100GB	כברירת מחדל, משימת העתקה אחת שהיא חלק משאילתה עם אחזור נתונים גלובלי יכולה להעביר עד 100GB. כדי לבקש הגדלה של המגבלה, פנו לתמיכה.
עדכונים של הגדרות כלליות ברמת הפרויקט	5	כשמריצים הצהרת DDL שמשנה אפשרויות הגדרה גלובליות, אפשר להריץ עד חמש הצהרות כל 10 שניות. המגבלה הזו חלה על הצהרות ה-DDL הבאות: ALTER PROJECT SET OPTIONS ALTER ORGANIZATION SET OPTIONS

המגבלות הבאות חלות על משימות שאילתה שנוצרות באופן אוטומטי על ידי הפעלת שאילתות אינטראקטיביות, שאילתות מתוזמנות ומשימות שנשלחות באמצעות ה-methods של ה-API‏ jobs.query ו-jobs.insert מסוג שאילתה:

הגבלה	ברירת מחדל	הערות
המספר המקסימלי של שאילתות אינטראקטיביות בתור	‫1,000 שאילתות	בפרויקט שלכם יכולות להיות עד 1,000 שאילתות אינטראקטיביות בתור. שאילתות אינטראקטיביות נוספות שיחרגו מהמגבלה הזו יחזירו שגיאת מכסה. כדי לפתור בעיות אלה, קראו את המאמר איך להימנע ממגבלות על שאילתות אינטראקטיביות בנפח גבוה.
המספר המקסימלי של שאילתות באצווה בתור	‫20,000 שאילתות	בפרויקט שלכם יכולות להיות עד 20,000 שאילתות באצווה בתור. שאילתות אצווה נוספות שחורגות מהמגבלה הזו מחזירות שגיאת מכסה.
המספר המקסימלי של שאילתות אינטראקטיביות בו-זמניות במקורות נתונים חיצוניים של Bigtable	‫16 שאילתות	בפרויקט אפשר להריץ עד 16 שאילתות בו-זמנית על מקור נתונים חיצוני ב-Bigtable.
המספר המקסימלי של שאילתות בו-זמניות שמכילות פונקציות מרוחקות	‫10 שאילתות	אפשר להריץ עד 10 שאילתות בו-זמנית עם פונקציות מרוחקות בכל פרויקט.
המספר המקסימלי של שאילתות בו-זמניות עם כמה הצהרות	‫1,000 שאילתות מרובות הצהרות	בפרויקט אפשר להריץ עד 1,000 שאילתות מרובות-הצהרות בו-זמנית. למכסות ולמגבלות אחרות שקשורות לשאילתות עם כמה הצהרות, ראו שאילתות עם כמה הצהרות.
המספר המקסימלי של שאילתות SQL מדור קודם בו-זמניות שמכילות פונקציות UDF	‫6 שאילתות	בפרויקט אפשר להריץ עד שש שאילתות SQL מדור קודם בו-זמנית עם פונקציות בהגדרת המשתמש (UDF). המגבלה הזו כוללת גם שאילתות אינטראקטיביות וגם שאילתות אצווה. שאילתות אינטראקטיביות שמכילות פונקציות UDF נכללות גם במגבלה על מספר השאילתות האינטראקטיביות שאפשר להריץ בו-זמנית. המגבלה הזו לא חלה על שאילתות GoogleSQL.
מגבלת הגודל היומית של השאילתות	ללא הגבלה	כברירת מחדל, אין מגבלה על גודל השאילתות היומי. עם זאת, אפשר להגביל את כמות הנתונים שהמשתמשים יכולים לשלוח לגביהם שאילתות. לשם כך, יוצרים מכסות בהתאמה אישית כדי לשלוט בשימוש בשאילתות ביום או בשימוש בשאילתות ביום לכל משתמש.
מגבלת עדכון יומית של טבלת היעד	למידע נוסף, ראו המספר המקסימלי של פעולות בטבלה ביום.	עדכונים של טבלאות יעד במשימת שאילתה נספרים במגבלה על המספר המקסימלי של פעולות בטבלה ליום בטבלאות היעד. עדכונים של טבלת היעד כוללים פעולות של הוספה ושכתוב שמבוצעות על ידי שאילתות שמופעלות באמצעות Google Cloud המסוף, באמצעות כלי שורת הפקודה bq או באמצעות קריאה לשיטות ה-API‏ jobs.query ו-jobs.insert מסוג שאילתה.
מגבלת זמן ההרצה של שאילתה או שאילתה עם כמה הצהרות	6 שעות	שאילתה או שאילתה עם כמה הצהרות יכולות לפעול למשך 6 שעות לכל היותר, ולאחר מכן הן נכשלות. עם זאת, יכול להיות ש-BigQuery ינסה שוב באופן פנימי לבצע משימת שאילתה בגלל בעיות זמניות, כמו הפעלה מחדש של השרת. מערכת BigQuery יכולה לנסות לבצע שאילתה עד שלוש פעמים, וכל ניסיון יכול להימשך עד 6 שעות. כתוצאה מכך, יכול להיות שזמן הריצה הכולל של שאילתה יהיה יותר מ-6 שעות (עד 18 שעות). כדי לבדוק אם בוצע ניסיון חוזר להפעיל משימה, אתם יכולים לחפש את האותות הבאים: מסוףGoogle Cloud : ב-Jobs Explorer, משווים בין שני משימות. בקטע Query level analysis, מסמנים את התיבה Retry בכרטיסייה Metrics. ‫INFORMATION_SCHEMA: בתצוגות INFORMATION_SCHEMA.JOBS, בודקים את העמודה final_execution_duration_ms. אם ההפרש בין start_time לבין end_time גדול משמעותית מ-final_execution_duration_ms, אז השאילתה נוסתה שוב. ‫BigQuery API: באובייקט JobStatistics, בודקים את השדה finalExecutionDurationMs. אם ההבדל בין startTime לבין endTime גדול משמעותית מ-finalExecutionDurationMs, המשמעות היא שהייתה ניסיון חוזר להפעלת השאילתה. למידע נוסף, קראו את הקטע משך הביצוע במסמכי התיעוד בנושא פתרון בעיות בשאילתות. זמן הקצוב לתפוגה של משימת CREATE MODEL הוא 24 שעות כברירת מחדל, למעט משימות של סדרות זמנים, AutoML וכוונון היפר-פרמטרים, שבהן הזמן הקצוב לתפוגה הוא 48 שעות.
המספר המקסימלי של מקורות מידע שמאוזכרים בכל שאילתה	‫1,000 משאבים	אחרי הרחבה מלאה,שאילתה יכולה להפנות ל-1, 000 טבלאות ייחודיות, תצוגות ייחודיות, פונקציות ייחודיות בהגדרת משתמש (UDF) ופונקציות ייחודיות של טבלאות. המגבלה הזו כוללת את הפריטים הבאים: טבלאות, תצוגות, UDF ופונקציות טבלה שמופנים אליהם ישירות בשאילתה. טבלאות, תצוגות, פונקציות UDF ופונקציות טבלה שאליהן מפנות תצוגות, פונקציות UDF ופונקציות טבלה אחרות שמופיעות בשאילתה.
אורך מקסימלי של שאילתת SQL בתווים	‫1,024k תווים	שאילתת SQL יכולה להכיל עד 1,024,000 תווים. המגבלה הזו כוללת הערות ותווים של רווח לבן. אם השאילתה ארוכה יותר, תופיע השגיאה הבאה: The query is too large.. כדי לא לחרוג מהמגבלה הזו, כדאי להחליף מערכים או רשימות גדולים בפרמטרים של שאילתה, ולפצל שאילתה ארוכה לכמה שאילתות בסשן.
האורך המקסימלי של שאילתת SQL מדור קודם שלא נפתרה	‫256KB	אורך שאילתת SQL מדור קודם שלא נפתרה יכול להיות עד 256KB. אם השאילתה ארוכה יותר, תתקבל השגיאה הבאה: The query is too large.. כדי לא לחרוג מהמגבלה, כדאי להחליף מערכים או רשימות גדולים בפרמטרים של שאילתה.
האורך המקסימלי של שאילתת GoogleSQL לא פתורה	‫1MB	אורך שאילתת GoogleSQL שלא נפתרה יכול להיות עד 1MB. אם השאילתה ארוכה יותר, מוצגת השגיאה הבאה: The query is too large. כדי לא לחרוג מהמגבלה הזו, כדאי להחליף מערכים או רשימות גדולים בפרמטרים של שאילתות.
האורך המקסימלי של שאילתות מדור קודם ו-GoogleSQL שנפתרו	‫12MB	המגבלה על אורך השאילתה אחרי הפתרון כוללת את האורך של כל התצוגות וטבלאות התווים הכלליים לחיפוש שהשאילתה מפנה אליהן.
המספר המקסימלי של פרמטרים של שאילתות GoogleSQL	‫10,000 פרמטרים	שאילתת GoogleSQL יכולה לכלול עד 10,000 פרמטרים.
גודל בקשה מקסימלי	‫10MB	גודל הבקשה יכול להיות עד 10MB, כולל מאפיינים נוספים כמו פרמטרים של שאילתה.
גודל התשובה המקסימלי	10GB דחוסים	הגדלים משתנים בהתאם ליחסי הדחיסה של הנתונים. גודל התגובה בפועל עשוי להיות גדול משמעותית מ-10GB. הגודל המקסימלי של התגובה הוא בלתי מוגבל כשכותבים תוצאות של שאילתות גדולות לטבלת יעד.
גודל שורה מקסימלי	‫100MB	הגודל המקסימלי של שורה הוא משוער, כי המגבלה מבוססת על הייצוג הפנימי של נתוני השורה. המגבלה על הגודל המקסימלי של שורה נאכפת בשלבים מסוימים של הרצת משימת השאילתה.
מספר העמודות המקסימלי בטבלה, בתוצאת שאילתה או בהגדרת תצוגה	‫10,000 עמודות	טבלה, תוצאת שאילתה או הגדרת תצוגה יכולות להכיל עד 10,000 עמודות. זה כולל עמודות מקוננות ועמודות חוזרות. עמודות שנמחקו יכולות להמשיך להיכלל במספר העמודות הכולל. אם מחקתם עמודות, יכול להיות שתקבלו שגיאות מכסה עד שהסכום הכולל יתאפס.
מספר מקסימלי של משבצות בו-זמניות לתמחור על פי דרישה	‫2,000 משבצות לכל פרויקט ‫20,000 משבצות לכל ארגון	במסגרת תמחור על פי דרישה, בפרויקט יכולים להיות עד 2,000 יחידות קיבולת בו-זמניות. בנוסף, יש מכסה של 20,000 משבצות בו-זמניות ברמת הארגון. אם הדרישה הכוללת של פרויקטים בארגון גבוהה מ-20,000 יחידות קיבולת (Slot), המערכת של BigQuery מנסה להקצות את יחידות הקיבולת (Slot) באופן הוגן בין הפרויקטים. יחידות הקיבולת של BigQuery משותפות לכל השאילתות בפרויקט אחד. יכול להיות ש-BigQuery יחרוג מהמגבלה הזו כדי להאיץ את השאילתות. הקיבולת כפופה לזמינות. כדי לבדוק כמה משבצות אתם משתמשים, אפשר לעיין במאמר בנושא מעקב אחרי BigQuery באמצעות Cloud Monitoring.
שימוש מקסימלי במעבד (CPU) לכל נתונים שנסרקו לתמחור על פי דרישה	‫256 שניות CPU לכל MiB שנסרק	בתמחור על פי דרישה, שאילתה יכולה להשתמש בעד כ-256 שניות CPU לכל MiB של נתונים שנסרקו. אם השאילתה דורשת יותר מדי משאבי מעבד (CPU) ביחס לכמות הנתונים שמעובדים, השאילתה נכשלת ומופיעה השגיאה billingTierLimitExceeded. מידע נוסף זמין במאמר בנושא הודעות שגיאה.
שינויים בטבלת עסקאות עם כמה דפי תדפיס	‫100 טבלאות	עסקה יכולה לשנות נתונים ב-100 טבלאות לכל היותר.
שינויים במחיצות של טרנזקציות עם כמה הצהרות	‫100,000 שינויים במחיצות	טרנזקציה יכולה לבצע עד 100,000 שינויים במחיצות.
הגודל המקסימלי של תוצאות שאילתות ב-BigQuery Omni	‫20GiB לא דחוסים	גודל התוצאה המקסימלי הוא 20GiB בייטים לוגיים כששולחים שאילתה לנתונים של Microsoft Azure או של AWS. אם תוצאת השאילתה גדולה מ-20 GiB, כדאי לייצא את התוצאות ל-Amazon S3 או ל-Blob Storage. מידע נוסף זמין במאמר בנושא מגבלות של BigQuery Omni.
הגודל הכולל של תוצאות השאילתות ב-BigQuery Omni ליום	1TB	הגודל הכולל של תוצאות השאילתות לפרויקט הוא 1TB ליום. מידע נוסף זמין במאמר המגבלות של BigQuery Omni.
גודל השורה המקסימלי ב-BigQuery Omni	‎10 MiB	גודל השורה המקסימלי הוא 10MiB כשמבצעים שאילתה על נתונים של Microsoft Azure או של AWS. למידע נוסף, קראו את המאמר המגבלות של BigQuery Omni.
העברה של שאילתות עם אחזור נתונים גלובלי	‫2GiB לשנייה	רוחב הפס של ההעברה שמשמש שאילתות עם אחזור נתונים גלובלי, לכל פרויקט, לכל צמד אזורים

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

חילוץ משרות

המגבלות הבאות חלות על משימות של חילוץ נתונים מ-BigQuery באמצעות כלי שורת הפקודה של BigQuery, מסוף Google Cloud או ה-API מסוג extract-type jobs.insert.

הגבלה	ברירת מחדל	הערות
מספר הבייטים המקסימלי שניתן לחלץ ביום	‫50TiB	המגבלה של 50TiB ליום (ExtractBytesPerDay) היא מגבלה למניעת ניצול לרעה, שחלה רק על משימות חילוץ שמשתמשות במאגר החינמי של משבצות משותפות. אתם יכולים לחלץ עד 50TiB של נתונים ביום מפרויקט ללא עלות באמצעות מאגר המשבצות המשותף. אתם יכולים להגדיר מדיניות התראות ב-Cloud Monitoring כדי לקבל התראה על מספר הבייטים שחולצו. משימות חילוץ פטורות מהמגבלה היומית של 50TiB ויכולות לחרוג ממנה אם מבצעים אחת מהפעולות הבאות: יוצרים הזמנה של משבצת זמן או משתמשים בהזמנה קיימת, ואז מקצים את הפרויקט להזמנה עם סוג העבודה PIPELINE. מכיוון שעבודות החילוץ משתמשות בקיבולת משבצות ייעודית או בקיבולת משבצות שניתנת להרחבה אוטומטית, במקום במאגר המשותף, הן לא כפופות למכסת 50 ה-TiB היומית. החיוב מתבצע לפי תמחור מבוסס-קיבולת. הצהרות EXPORT DATA לא נתמכות בהזמנות PIPELINE. משתמשים ב- EXPORT DATA הצהרת SQL. ההצהרה מופעלת כמשימת שאילתה באמצעות קיבולת שאילתה ולא מאגר החילוץ המשותף, ולכן היא פטורה ממכסת בייטים לחילוץ. החיוב מתבצע לפי תמחור על פי דרישה או לפי תמחור על בסיס קיבולת, בהתאם להגדרת הפרויקט. להשתמש ב-Storage Read API. מכיוון שקריאות בסטרימינג מתבצעות ישירות מהאחסון ב-BigQuery, הן עוקפות את המכסות של משימות החילוץ. החיוב מתבצע לפי המחיר של קריאות בסטרימינג. זמן התפוגה מובטח להיות לפחות 6 שעות מזמן יצירת הסשן.
מספר מקסימלי של משימות חילוץ ביום	‫100,000 משימות חילוץ	המגבלה של 100,000 משימות חילוץ ביום היא מגבלה למניעת ניצול לרעה שחלה רק על משימות חילוץ שמשתמשות במאגר המשבצות המשותף בחינם. אתם יכולים להריץ עד 100,000 משימות חילוץ ביום בפרויקט ללא עלות, באמצעות מאגר ה-slots המשותף. משימות חילוץ פטורות מהמגבלה של 100,000 משימות ביום, ואפשר לחרוג ממנה אם מבצעים אחת מהפעולות הבאות: יוצרים הזמנה של משבצת זמן או משתמשים בהזמנה קיימת, ואז מקצים את הפרויקט להזמנה עם סוג העבודה PIPELINE. מכיוון שעבודות החילוץ משתמשות בקיבולת ייעודית או בקיבולת שניתנת להתאמה אוטומטית במקום במאגר המשותף, הן עוקפות לחלוטין את המגבלה היומית על עבודות חילוץ. החיוב מתבצע לפי תמחור מבוסס-קיבולת. משתמשים בהצהרת ה-SQL‏ EXPORT DATA. הסיבה לכך היא שההצהרה מופעלת כמשימת שאילתה, ולכן היא לא כפופה למגבלות על משימות חילוץ יומיות. החיוב מתבצע לפי תמחור על פי דרישה או תמחור מבוסס-קיבולת, בהתאם להגדרות הפרויקט. להשתמש ב-Storage Read API. מכיוון שקריאות בסטרימינג מתבצעות ישירות מהאחסון ב-BigQuery, הן עוקפות את המכסות של משימות החילוץ. החיוב מתבצע לפי המחיר של קריאות סטרימינג. זמן התפוגה מובטח להיות לפחות 6 שעות מזמן יצירת הסשן.
גודל הטבלה המקסימלי שאפשר לחלץ לקובץ אחד	‎1GB	אפשר לחלץ עד 1GB של נתוני טבלה לקובץ אחד. כדי לחלץ יותר מ-1GB של נתונים, צריך להשתמש ב תו כללי כדי לחלץ את הנתונים לכמה קבצים. כשמחלצים נתונים לכמה קבצים, הגודל של הקבצים משתנה. במקרים מסוימים, גודל קובצי הפלט הוא יותר מ-1GB.
מזהי URI עם תווים כלליים לחיפוש לכל משימת חילוץ	‫500 מזהי URI	משימת חילוץ יכולה לכלול עד 500 מזהי URI עם תווים כלליים לחיפוש.

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

משימות טעינה

המגבלות הבאות חלות כשטוענים נתונים ל-BigQuery באמצעות מסוףGoogle Cloud , כלי שורת הפקודה של BigQuery או שיטת ה-API jobs.insert מסוג load.

הגבלה	ברירת מחדל	הערות
משימות טעינה לכל טבלה ביום	‫1,500 משרות	משימות טעינה, כולל משימות טעינה שנכשלו, נספרות במגבלה על מספר הפעולות בטבלה ליום בטבלת היעד. מידע על מגבלות מספר הפעולות בטבלה ליום בטבלאות רגילות ובטבלאות מחולקות למחיצות מופיע במאמר טבלאות.
משימות טעינה ביום	‫100,000 משימות	המכסה שלכם בפרויקט מתחדשת עד למקסימום של 100,000 משימות טעינה כל 24 שעות. משימות טעינה שנכשלו נכללות בחישוב במסגרת המגבלה הזו. במקרים מסוימים, אפשר להריץ יותר מ-100,000 עבודות טעינה ב-24 שעות אם לא נעשה שימוש מלא במכסת היומית הקודמת.
מספר העמודות המקסימלי בכל טבלה	‫10,000 עמודות	טבלה יכולה להכיל עד 10,000 עמודות. זה כולל עמודות מקוננות וחוזרות.
הגודל המקסימלי לכל משימת טעינה	‫15TB	הגודל הכולל של כל קובצי הקלט בפורמטים CSV,‏ JSON,‏ Avro,‏ Parquet ו-ORC יכול להיות עד 15TB. המגבלה הזו לא חלה על משימות עם הזמנה.
המספר המקסימלי של מזהי URI של מקורות בהגדרת המשימה	‫10,000 מזהי URI	בהגדרת משימה יכולים להיות עד 10,000 מזהי URI של מקורות.
מספר הקבצים המקסימלי לכל משימת טעינה	‫10,000,000 קבצים	עבודת טעינה יכולה לכלול עד 10 מיליון קבצים בסך הכול, כולל כל הקבצים שתואמים לכל ה-URI עם התווים הכלליים.
המספר המקסימלי של קבצים בקטגוריה של Cloud Storage המקורית	בערך 60,000,000 קבצים	עבודת טעינה יכולה לקרוא מקטגוריה של Cloud Storage שמכילה עד כ-60,000,000 קבצים.
מגבלת זמן הביצוע של משימת טעינה	6 שעות	אם עבודת טעינה נמשכת יותר משש שעות, היא נכשלת.
‫Avro: גודל מקסימלי של בלוקי נתונים של קבצים	16 MB	הגודל המקסימלי של בלוקי נתונים בקובץ Avro הוא 16MB.
‫CSV: גודל תא מקסימלי	‫100MB	הגודל של תאי CSV יכול להיות עד 100MB.
CSV: גודל שורה מקסימלי	‫100MB	הגודל של שורות בקובץ CSV יכול להיות עד 100MB.
‫CSV: גודל קובץ מקסימלי – דחוס	‫4GB	המגבלה לגודל של קובץ CSV דחוס היא 4GB.
‫CSV: גודל קובץ מקסימלי – לא דחוס	5TB	מגבלת הגודל לקובץ CSV לא דחוס היא 5TB.
‫JSON מופרד בתו שורה חדשה (ndJSON): גודל שורה מקסימלי	‫100MB	הגודל של שורות ndJSON יכול להיות עד 100MB.
‫ndJSON: גודל קובץ מקסימלי – דחוס	‫4GB	גודל הקובץ המקסימלי של קובץ ndJSON דחוס הוא 4GB.
‫ndJSON: גודל קובץ מקסימלי – לא דחוס	5TB	הגודל המקסימלי של קובץ ndJSON לא דחוס הוא 5TB.

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

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

שיקולים לגבי מכסות של משימות טעינה בשירות העברת הנתונים ל-BigQuery

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

אתם יכולים להשתמש במשוואה הבאה כדי להעריך כמה משימות טעינה נדרשות להעברות:

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

כאשר:

• ‫Number of transfers הוא מספר הגדרות ההעברה שהפעלתם בפרויקט.

• ‫Number of tables הוא מספר הטבלאות שנוצרו על ידי כל סוג העברה ספציפי. מספר הטבלאות משתנה בהתאם לסוג ההעברה:

  • העברות מ-Campaign Manager יוצרות בערך 25 טבלאות.
  • העברות מ-Google Ads יוצרות כ-60 טבלאות.
  • העברות מ-Google Ad Manager יוצרות כ-40 טבלאות.
  • העברות מ-Google Play יוצרות בערך 25 טבלאות.
  • העברות מ-Search Ads 360 יוצרות בערך 50 טבלאות.
  • העברות ב-YouTube יוצרות כ-50 טבלאות.

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

  • ‫Campaign Manager
  • Google Ads
  • Google Ad Manager
  • Google Merchant Center (בטא)
  • Google Play
  • Search Ads 360 (בטא)
  • ערוץ YouTube
  • בעלי התוכן ב-YouTube

• ‫Refresh window הוא מספר הימים שייכללו בהעברת הנתונים. אם מזינים 1, לא מתבצע מילוי יומי.

משימות העתקה

המגבלות הבאות חלות על משימות BigQuery של העתקת טבלאות, כולל משימות שיוצרות עותק, שיבוט או תמונת מצב של טבלה רגילה, שיבוט טבלה או תמונת מצב של טבלה. המגבלות חלות על משימות שנוצרו באמצעות מסוף Google Cloud , כלי שורת הפקודה של BigQuery או ה-method‏ jobs.insert שמציינת את השדה copy בהגדרת המשימה. משימות העתקה נכללות במגבלות האלה, גם אם הן מצליחות וגם אם הן נכשלות.

הגבלה	ברירת מחדל	הערות
העתקת משימות לכל טבלת יעד ביום		אפשר לעיין בפעולות בטבלה ליום.
מספר עבודות ההעתקה ביום	‫100,000 משימות	בפרויקט שלכם אפשר להריץ עד 100,000 משימות העתקה ביום.
משימות העתקה בין אזורים לכל טבלת יעד ביום	100 משרות	בפרויקט אפשר להריץ עד 100 משימות העתקה בין אזורים לטבלת יעד ביום.
משימות העתקה בין אזורים ביום	‫2,000 משימות	בכל יום אפשר להריץ עד 2,000 עבודות העתקה בין אזורים בפרויקט.
מספר טבלאות המקור להעתקה	‫1,200 טבלאות מקור	אפשר להעתיק מעד 1,200 טבלאות מקור בכל משימת העתקה.

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

המגבלות הבאות חלות על העתקת מערכי נתונים:

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

הזמנות

המכסות הבאות חלות על הזמנות:

מכסה	ברירת מחדל	הערות
מספר המשבצות הכולל באזור האיחוד האירופי	‫5,000 חריצים	מספר המקסימלי של יחידות קיבולת של BigQuery שאפשר לרכוש במספר אזורים באיחוד האירופי באמצעות מסוף Google Cloud . הצגת המכסות במסוף Google Cloud
מספר המשבצות הכולל באזור ארה"ב	‫10,000 משבצות	מספר המקסימלי של יחידות הקיבולת של BigQuery שאפשר לרכוש במספר אזורים בארה"ב באמצעות מסוף Google Cloud . הצגת מכסות במסוף Google Cloud
מספר המשבצות הכולל באזור us-east1	‫4,000 חריצים	המספר המקסימלי של יחידות קיבולת של BigQuery שאפשר לרכוש באזור שמופיע ברשימה באמצעות Google Cloud המסוף. הצגת המכסות במסוף Google Cloud
המספר הכולל של משבצות הפרסום באזורים הבאים: asia-south1 asia-southeast1 europe-west2 us-central1 us-west1	‫2,000 משבצות	המספר המקסימלי של יחידות קיבולת של BigQuery שאפשר לרכוש בכל אחד מהאזורים שמופיעים ברשימה באמצעות מסוף Google Cloud . הצגת מכסות במסוף Google Cloud
המספר הכולל של משבצות באזורים הבאים: asia-east1 asia-northeast1 asia-northeast3 asia-southeast2 australia-southeast1 europe-north1 europe-west1 europe-west3 europe-west4 northamerica-northeast1 us-east4 southamerica-east1	1,000 משבצות	המספר המקסימלי של יחידות קיבולת של BigQuery שאתם יכולים לרכוש בכל אחד מהאזורים שמופיעים ברשימה, באמצעות מסוף Google Cloud . הצגת מכסות במסוף Google Cloud
המספר הכולל של יחידות ה-slot באזורים של BigQuery Omni	‫100 משבצות	המספר המקסימלי של יחידות קיבולת של BigQuery שאפשר לרכוש באזורים של BigQuery Omni באמצעות מסוף Google Cloud . הצגת מכסות במסוף Google Cloud
המספר הכולל של משבצות לכל שאר האזורים	‫500 משבצות	המספר המקסימלי של יחידות קיבולת של BigQuery שאפשר לרכוש בכל אזור אחר באמצעות Google Cloud המסוף. הצגת המכסות במסוף Google Cloud

המגבלות הבאות חלות על הזמנות:

הגבלה	ערך	הערות
מספר הפרויקטים לניהול להזמנות של יחידות קיבולת	‫10 פרויקטים לכל ארגון	מספר הפרויקטים המקסימלי בארגון שיכולים להכיל הזמנה או התחייבות פעילה ל-slots במיקום או באזור נתון.
מספר מקסימלי של הזמנות במהדורה הרגילה	‫10 הזמנות לכל פרויקט	המספר המקסימלי של הזמנות במהדורת Standard לכל פרויקט ניהול בארגון, במיקום או באזור נתון.
מספר מקסימלי של הזמנות במהדורות Enterprise או Enterprise Plus	‫200 הזמנות לכל פרויקט	המספר המקסימלי של הזמנות למהדורת Enterprise או Enterprise Plus לכל פרויקט ניהול בארגון, במיקום או באזור נתון.
המספר המקסימלי של משבצות בהזמנה שמשויכת להקצאת הזמנה עם סוג העבודה CONTINUOUS.	‫500 משבצות	כשרוצים ליצור הקצאת הזמנה עם CONTINUOUS סוג עבודה, בהזמנה המשויכת לא יכולים להיות יותר מ-500 משבצות זמן.

מערכי נתונים

ההגבלות הבאות חלות על מערכי נתונים ב-BigQuery:

הגבלה	ברירת מחדל	הערות
מספר מקסימלי של קבוצות נתונים	ללא הגבלה	אין הגבלה על מספר מערכי הנתונים שיכולים להיות בפרויקט.
מספר הטבלאות בכל מערך נתונים	ללא הגבלה	כשמשתמשים בקריאה ל-API, ביצועי הספירה מואטים ככל שמתקרבים ל-50,000 טבלאות במערך נתונים. במסוף Google Cloud אפשר להציג עד 50,000 טבלאות לכל מערך נתונים.
מספר המשאבים המורשים ברשימת בקרת הגישה של מערך נתונים	‫2,500 משאבים	רשימת בקרת הגישה של מערך נתונים יכולה לכלול עד 2,500 משאבים מורשים, כולל תצוגות מורשות, מערכי נתונים מורשים ופונקציות מורשות. אם חורגים מהמגבלה הזו בגלל מספר גדול של תצוגות מפורטות עם הרשאה, כדאי לקבץ את התצוגות המפורטות במערכי נתונים עם הרשאה. כשיטה מומלצת, כדאי לקבץ תצוגות קשורות במערכי נתונים מורשים כשמעצבים ארכיטקטורות חדשות של BigQuery, במיוחד ארכיטקטורות מרובות דיירים.
מספר פעולות העדכון של מערך נתונים לכל מערך נתונים, בכל 10 שניות	‫5 פעולות	בכל 10 שניות, הפרויקט יכול לבצע עד חמש פעולות עדכון של קבוצות נתונים. מגבלת העדכון של מערך הנתונים כוללת את כל פעולות עדכון המטא-נתונים שבוצעו על ידי: מסוףGoogle Cloud כלי שורת הפקודה של BigQuery ספריות הלקוח של BigQuery השיטות הבאות ב-API: datasets.insert datasets.patch datasets.update datasets.delete datasets.undelete הצהרות ה-DDL הבאות: CREATE SCHEMA ALTER SCHEMA DROP SCHEMA UNDROP SCHEMA
אורך מקסימלי של תיאור קבוצת נתונים	‫16,384 תווים	כשמוסיפים תיאור למערך נתונים, הטקסט יכול להיות באורך של עד 16,384 תווים.

Tables

כל הטבלאות

המגבלות הבאות חלות על כל הטבלאות ב-BigQuery.

הגבלה	ברירת מחדל	הערות
האורך המקסימלי של שם עמודה	‫300 תווים	שם העמודה יכול להכיל עד 300 תווים.
האורך המקסימלי של תיאור עמודה	‫1,024 תווים	כשמוסיפים תיאור לעמודה, הטקסט יכול להכיל עד 1,024 תווים.
העומק המקסימלי של רשומות בתצוגת עץ	‫15 רמות	עמודות מסוג RECORD יכולות להכיל סוגי RECORD מקוננים, שנקראים גם רשומות צאצא. מגבלת עומק ההטמעה המקסימלית היא 15 רמות. המגבלה הזו לא תלויה בשאלה אם הרשומות הן סקלריות או מבוססות-מערך (חוזרות).
האורך המקסימלי של תיאור הטבלה	‫16,384 תווים	כשמוסיפים תיאור לטבלה, הטקסט יכול להיות באורך של עד 16,384 תווים.

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

טבלאות רגילות

ההגבלות הבאות חלות על טבלאות סטנדרטיות (מובנות) ב-BigQuery:

הגבלה	ברירת מחדל	הערות
שינויים בטבלה ליום	‫1,500 שינויים	בפרויקט אפשר לבצע עד 1,500 שינויים בטבלה לכל טבלה ביום. משימת טעינה, משימת העתקה או משימת שאילתה שמוסיפה נתונים לטבלה או מחליפה אותם, נחשבת לשינוי אחד בטבלה. אי אפשר לשנות את המגבלה הזו. המגבלה הזו נאכפת כמגבלת קצב של יצירת בקשות לאורך היום, ולא כמכסה אחת שמוקצית בבת אחת. המכסה הזמין ב-BigQuery מתעדכן באופן שוטף. פרצים של פעולות בתדירות גבוהה יכולים למצות את המכסה הזמינה, וכתוצאה מכך לגרום לשגיאות quotaExceeded גם אם הנפח היומי הכולל נמוך בהרבה מהמגבלה היומית של 1,500 שינויים. כדי לשפר את הטמעת הנתונים בתדירות גבוהה, כדאי להריץ את הפעולות באצווה, לפרוס את המשימות באופן שווה לאורך זמן או לעבור ל-BigQuery Storage Write API (gRPC)‎. פקודות DML לא נכללות ולא נספרות במספר השינויים בטבלה ביום. נתונים בסטרימינג לא נכללים ולא נספרים במספר השינויים בטבלה ביום.
הקצב המקסימלי של פעולות עדכון מטא-נתונים של טבלה לכל טבלה	5 פעולות לכל 10 שניות	בפרויקט אפשר לבצע עד חמש פעולות של עדכון מטא-נתונים של טבלה בכל 10 שניות לכל טבלה. המגבלה הזו חלה על כל פעולות העדכון של המטא-נתונים בטבלה, שמבוצעות על ידי: מסוףGoogle Cloud כלי שורת הפקודה של BigQuery ספריות הלקוח של BigQuery השיטות הבאות ב-API: tables.insert tables.patch tables.update הצהרות DDL בטבלאות המגבלה הזו כוללת גם את הסכום הכולל של כל משימות הטעינה, משימות ההעתקה ומשימות השאילתה שמצרפות נתונים לטבלת יעד או מחליפות אותה, או שמשתמשות בהצהרות DML‏ DELETE,‏ INSERT,‏ MERGE,‏ TRUNCATE TABLE או UPDATE כדי לכתוב נתונים בטבלה. שימו לב: אמנם הצהרות DML נספרות כחלק מהמגבלה הזו, אבל הן לא כפופות לה אם המגבלה מושגת. לפעולות DML יש מגבלות קצב ייעודיות. אם תחרגו מהמגבלה הזו, תקבלו הודעת שגיאה כמו Exceeded rate limits: too many table update operations for this table. זו שגיאה זמנית, ואפשר לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר. כדי לזהות את הפעולות שנכללות במגבלה הזו, אתם יכולים לבדוק את היומנים. הנחיות לאבחון ולפתרון השגיאה הזו מופיעות במאמר פתרון בעיות שקשורות למכסות.
מספר העמודות המקסימלי בכל טבלה	‫10,000 עמודות	כל טבלה, תוצאת שאילתה או הגדרת תצוגה יכולה להכיל עד 10,000 עמודות. הערך הזה כולל עמודות חוזרות ועמודות בתצוגת עץ.

טבלאות חיצוניות

המגבלות הבאות חלות על טבלאות BigQuery עם נתונים שמאוחסנים ב-Cloud Storage בפורמט Parquet,‏ ORC,‏ Avro,‏ CSV או JSON:

הגבלה	ברירת מחדל	הערות
המספר המקסימלי של מזהי URI של מקור לכל טבלה חיצונית	‫10,000 מזהי URI	לכל טבלה חיצונית יכולים להיות עד 10,000 מזהי URI של מקורות.
מספר הקבצים המקסימלי לכל טבלה חיצונית	‫10,000,000 קבצים	טבלה חיצונית יכולה להכיל עד 10 מיליון קבצים, כולל כל הקבצים שתואמים לכל מזהי ה-URI עם התווים הכלליים לחיפוש.
הגודל המקסימלי של נתונים שמאוחסנים ב-Cloud Storage לכל טבלה חיצונית	600 TB	טבלה חיצונית יכולה להכיל עד 600 טרה-בייט בכל קובצי הקלט. המגבלה הזו חלה על גודלי הקבצים שמאוחסנים ב-Cloud Storage. הגודל הזה לא זהה לגודל שמשמש בנוסחת התמחור של השאילתה. בטבלאות שחולקו למחיצות באופן חיצוני, המגבלה חלה אחרי גיזום המחיצות.
המספר המקסימלי של קבצים בקטגוריה של Cloud Storage המקורית	בערך 300,000,000 קבצים	טבלה חיצונית יכולה להפנות לקטגוריה של Cloud Storage שמכילה עד כ-300,000,000 קבצים. בטבלאות שמחולקות למחיצות באופן חיצוני, המגבלה הזו חלה לפני גיזום המחיצות.

טבלאות מחולקות למחיצות (Partitions)

המגבלות הבאות חלות על טבלאות מחולקות למחיצות ב-BigQuery.

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

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

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

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

הגבלה	ברירת מחדל	הערות
מספר המחיצות בכל טבלה מחולקת למחיצות	‫10,000 מחיצות	כל טבלה מחולקת למחיצות (Partitions) יכולה לכלול עד 10,000 מחיצות. אם חורגים מהמגבלה הזו, כדאי להשתמש ב אשכולות בנוסף לחלוקה למחיצות או במקומה.
מספר המחיצות ששונו על ידי משימה יחידה	‫4,000 מחיצות	כל פעולת משימה (שאילתה או טעינה) יכולה להשפיע על עד 4,000 מחיצות. מערכת BigQuery דוחה כל שאילתה או משימת טעינה שמנסה לשנות יותר מ-4,000 מחיצות.
מספר השינויים במחיצות בזמן הטמעת הנתונים לכל טבלה מחולקת למחיצות ביום	‫11,000 שינויים	בפרויקט אפשר לבצע עד 11,000 שינויים במחיצות ביום. שינוי מחיצה הוא פעולה שבה מוסיפים, מעדכנים, מוחקים או מקצרים נתונים בטבלה מחולקת למחיצות. כל סוג של שינוי נתונים שאתם מבצעים נספר כשינוי מחיצה. לדוגמה, מחיקה של שורה אחת נחשבת לשינוי אחד במחיצה, בדיוק כמו שמחיקה של מחיצה שלמה נחשבת לשינוי אחד. אם מוחקים שורה ממחיצה אחת ומכניסים אותה למחיצה אחרת, הפעולה נחשבת כשני שינויים במחיצה. שינויים באמצעות פקודות DML או Streaming API לא נספרים במספר השינויים במחיצות ליום.
מספר השינויים במחיצות לכל טבלה שמחולקת למחיצות לפי עמודות ביום	‫30,000 שינויים	בפרויקט אפשר לבצע עד 30,000 שינויים במחיצות ביום בטבלה עם מחיצות לפי עמודה. פקודות DML לא נספרות במספר השינויים במחיצות ביום. נתונים בסטרימינג לא נכללים במספר השינויים במחיצות ביום.
הקצב המקסימלי של פעולות עדכון מטא-נתונים של טבלה בכל טבלה מחולקת למחיצות (Partitions)	‫50 שינויים ב-10 שניות	בפרויקט אפשר לבצע עד 50 שינויים בכל טבלה מחולקת למחיצות, כל 10 שניות. המגבלה הזו חלה על כל פעולות העדכון של מטא-נתונים של טבלאות מחולקות למחיצות, שמבוצעות על ידי הפעולות הבאות: מסוףGoogle Cloud כלי שורת הפקודה של BigQuery ספריות הלקוח של BigQuery השיטות הבאות ב-API: tables.insert tables.patch tables.update הצהרות DDL בטבלאות המגבלה הזו כוללת גם את הסכום הכולל של כל משימות הטעינה, משימות ההעתקה ומשימות השאילתות שמצרפות נתונים לטבלת יעד או מחליפות אותה, או שמשתמשות בהצהרות DML מסוג DELETE,‏ INSERT,‏ MERGE,‏ TRUNCATE TABLE או UPDATE כדי לכתוב נתונים בטבלה. אם תחרגו מהמגבלה הזו, תקבלו הודעת שגיאה כמו Exceeded rate limits: too many partitioned table update operations for this table. זו שגיאה זמנית, ואפשר לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר. כדי לזהות את הפעולות שנכללות במגבלה הזו, אפשר לבדוק את היומנים.
מספר הטווחים האפשריים לחלוקה למחיצות לפי טווח	‫10,000 טווחים	טבלה שמחולקת לפי טווחים יכולה להכיל עד 10,000 טווחים אפשריים. המגבלה הזו חלה על מפרט המחיצה כשיוצרים את הטבלה. אחרי שיוצרים את הטבלה, המגבלה חלה גם על המספר בפועל של המחיצות.

שיבוטים של טבלאות

המגבלות הבאות חלות על שיבוטי טבלאות ב-BigQuery:

הגבלה	ברירת מחדל	הערות
מספר מקסימלי של שיבוטים ותמונות מצב בשרשרת	‫3 שיבוטים או תמונות מצב של טבלאות	השילוב של שיבוטים ותמונות מצב מוגבל לעומק של 3. כשמשכפלים מסד נתונים טבלאי או מצלמים תמונת מצב שלו, אפשר לשכפל את התוצאה או לצלם תמונת מצב שלה עוד פעמיים בלבד. ניסיון לשכפל את התוצאה או לצלם תמונת מצב שלה בפעם השלישית יגרום לשגיאה. לדוגמה, אפשר ליצור שיבוט A של מסד הנתונים הטבלאי, ליצור קובץ snapshot‏ B של שיבוט A וליצור שיבוט C של קובץ snapshot‏ B. כדי ליצור עותקים משוכפלים נוספים של תמונת המצב או השכפול ברמה השלישית, צריך להשתמש בפעולת העתקה.
מספר מקסימלי של שיבוטים ותמונות מצב של מסד נתונים טבלאי	‫1,000 שיבוטים או תמונות מצב של טבלאות	אי אפשר ליצור יותר מ-1,000 שיבוטים ותמונות מצב משולבים של מסד נתונים טבלאי נתון. לדוגמה, אם יש לכם 600 קובצי snapshot ו-400 שיבוטים, הגעתם למגבלה.

‫Snapshots של טבלאות

המגבלות הבאות חלות על תמונות מצב של טבלאות ב-BigQuery:

הגבלה	ברירת מחדל	הערות
המספר המקסימלי של משימות בו-זמניות של תמונות מצב של טבלאות	100 משרות	בפרויקט יכולות לפעול עד 100 משימות בו-זמניות של צילומי מצב של טבלאות.
מספר המשימות המקסימלי של תמונות מצב של טבלאות ביום	‫50,000 משימות	בכל יום אפשר להריץ עד 50,000 משימות של צילומי מצב של טבלאות בפרויקט.
מספר המשימות המקסימלי של קובצי snapshot לטבלה, לכל טבלה ביום	50 משרות	בכל יום אפשר להריץ עד 50 משימות של צילום מצב של טבלה לכל טבלה בפרויקט.
המספר המקסימלי של עדכוני מטא-נתונים לכל תמונת מצב של טבלה, בכל 10 שניות.	5 עדכונים	בפרויקט אפשר לעדכן את המטא-נתונים של תמונת מצב של טבלה עד חמש פעמים בכל 10 שניות.
מספר מקסימלי של שיבוטים ותמונות מצב בשרשרת	‫3 שיבוטים או תמונות מצב של טבלאות	השילוב של שיבוטים ותמונות מצב מוגבל לעומק של 3. כשמשכפלים מסד נתונים טבלאי או מצלמים תמונת מצב שלו, אפשר לשכפל את התוצאה או לצלם תמונת מצב שלה עוד פעמיים בלבד. ניסיון לשכפל את התוצאה או לצלם תמונת מצב שלה בפעם השלישית יגרום לשגיאה. לדוגמה, אפשר ליצור שיבוט A של מסד נתונים טבלאי, ליצור snapshot B של שיבוט A וליצור שיבוט C של snapshot B. כדי ליצור עותקים משוכפלים נוספים של השכפול או של תמונת המצב ברמה השלישית, צריך להשתמש בפעולת העתקה.
מספר מקסימלי של שיבוטים ותמונות מצב למסד נתונים טבלאי	‫1,000 שיבוטים או תמונות מצב של טבלאות	לא יכולים להיות יותר מ-1,000 שיבוטים וצילומים קיימים ביחד של מסד נתונים טבלאי נתון. לדוגמה, אם יש לכם 600 קובצי snapshot ו-400 שיבוטים, הגעתם למגבלה.

תצוגות

המכסות והמגבלות הבאות חלות על תצוגות ועל תצוגות חומריות.

תצוגות לוגיות

המגבלות הבאות חלות על תצוגות רגילות ב-BigQuery:

הגבלה	ברירת מחדל	הערות
מספר מקסימלי של רמות תצוגה מקוננות	‫16 רמות	‫BigQuery תומך בעד 16 רמות של תצוגות בתצוגות. אפשר ליצור תצוגות עד למגבלה הזו, אבל השאילתות מוגבלות ל-15 רמות. אם חורגים מהמגבלה, BigQuery מחזיר שגיאת INVALID_INPUT.
האורך המקסימלי של שאילתת GoogleSQL שמשמשת להגדרת תצוגה	‫256 אלף תווים	שאילתת GoogleSQL אחת שמגדירה תצוגה יכולה להיות באורך של עד 256,000 תווים. המגבלה הזו חלה על שאילתה אחת, והיא לא כוללת את אורך התצוגות שאליהן מפנה השאילתה.
מספר מקסימלי של תצוגות מורשות לכל מערך נתונים		למידע נוסף על מערכי נתונים
האורך המקסימלי של תיאור התצוגה	‫16,384 תווים	כשמוסיפים תיאור לתצוגה, הטקסט יכול להיות באורך של עד 16,384 תווים.

תצוגות מהותיות

המגבלות הבאות חלות על תצוגות חומריות ב-BigQuery:

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

אינדקסים של חיפוש

המגבלות הבאות חלות על אינדקסי החיפוש של BigQuery:

הגבלה	ברירת מחדל	הערות
מספר ההצהרות של CREATE INDEX או ALTER INDEX DDL לכל פרויקט לכל אזור ביום	‫500 פעולות	בפרויקט אפשר להנפיק עד 500 פעולות DDL של CREATE INDEX או ALTER INDEX בכל יום באזור מסוים.
מספר הצהרות DDL של אינדקס החיפוש לכל טבלה ביום	‫20 פעולות	בכל יום, הפרויקט יכול להנפיק עד 20 פעולות DDL‏ (CREATE INDEX, ‏ ALTER INDEX או DROP INDEX) לכל טבלה.
הגודל הכולל המקסימלי של נתוני טבלה לכל ארגון שמותר ליצירת אינדקס חיפוש שלא פועל בהזמנה	‫100TB במספר אזורים; 20TB בכל שאר האזורים	אפשר ליצור אינדקס חיפוש לטבלה אם הגודל הכולל של הטבלאות עם האינדקסים בארגון קטן מהמגבלה של האזור: 100TB באזורים במספר אזורים US ו-EU, ו-20TB בכל שאר האזורים. אם המשימות לניהול האינדקסים פועלות בהזמנה שלכם, המגבלה הזו לא חלה.
מספר העמודות שנוספו לאינדקס עם רמת פירוט של עמודה לכל טבלה	63 עמודות לכל טבלה	טבלה יכולה להכיל עד 63 עמודות עם index_granularity שמוגדר ל-COLUMN. העמודות שמוגדרות עם רמת פירוט COLUMN מהאפשרות default_index_column_granularity נכללות במגבלה הזו. אין הגבלה על מספר העמודות שמקבלות אינדוקס ברמת הגרנולריות GLOBAL. מידע נוסף מופיע במאמר אינדקס עם פירוט ברמת העמודה.

אינדקסים של וקטורים

המגבלות הבאות חלות על אינדקסים של וקטורים ב-BigQuery:

הגבלה	ברירת מחדל	הערות
מספר השורות המינימלי במסד נתונים טבלאי	‫5,000 שורות	כדי ליצור אינדקס וקטורי, בטבלה צריכות להיות לפחות 5,000 שורות.
מספר השורות המקסימלי במסד הנתונים הטבלאי לאינדקס מסוג IVF	‫10,000,000,000 שורות	בטבלה יכולות להיות עד 10,000,000,000 שורות כדי ליצור אינדקס וקטורי של IVF
מספר השורות המקסימלי במסד הנתונים הטבלאי לאינדקס מסוג TREE_AH	‫200,000,000 שורות	טבלה יכולה לכלול עד 200,000,000 שורות כדי ליצור אינדקס וקטורי TREE_AH
מספר השורות המקסימלי במסד נתונים טבלאי לאינדקס מסוג partitioned TREE_AH	‫10,000,000,000 שורות בסך הכול ‫200,000,000 שורות בכל מחיצה	כדי ליצור אינדקס וקטורי מחולק למחיצות ב-TREE_AH, בטבלה יכולות להיות עד 10,000,000,000 שורות, ובכל מחיצה יכולות להיות עד 200,000,000 שורות.
הגודל המקסימלי של המערך בעמודה שנוסף לה אינדקס	‫4,096 רכיבים	בעמודה שמוסיפים לאינדקס יכולים להיות עד 4,096 רכיבים במערך.
גודל הטבלה המינימלי לאכלוס אינדקס וקטורי	‫10MB	אם יוצרים אינדקס וקטורי בטבלה שהגודל שלה קטן מ-10MB, האינדקס לא יאוכלס. באופן דומה, אם מוחקים נתונים מטבלה עם אינדקס וקטורי כך שגודל הטבלה קטן מ-10MB, האינדקס הווקטורי מושבת באופן זמני. הפעולה הזו מתרחשת ללא קשר לשימוש בהזמנה שלכם למשימות של ניהול האינדקס. אם הגודל של טבלה עם אינדקס וקטורי חורג שוב מ-10MB, האינדקס שלה מתמלא אוטומטית.
מספר הצהרות ה-DDL של CREATE VECTOR INDEX לכל פרויקט, לכל אזור, לכל יום	‫500 פעולות	בכל פרויקט אפשר להנפיק עד 500 פעולות CREATE VECTOR INDEX ביום לכל אזור.
מספר הצהרות ה-DDL של אינדקס וקטורי לכל טבלה ביום	‫10 פעולות	אפשר להנפיק עד 10 פעולות של CREATE VECTOR INDEX או DROP VECTOR INDEX לכל טבלה ביום.
הגודל המקסימלי הכולל של נתוני הטבלה לכל ארגון שמותר ליצור אינדקס וקטורי שלא פועל בהזמנה	‫6TB	אפשר ליצור אינדקס וקטורי לטבלה אם הגודל הכולל של הטבלאות עם האינדקסים בארגון קטן מ-6TB. אם משימות ניהול האינדקס שלכם מופעלות בהזמנה משלכם, המגבלה הזו לא חלה עליכם.

תרחישים

המכסות והמגבלות הבאות חלות על שגרה.

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

המגבלות הבאות חלות על פונקציות זמניות ומתמידות בהגדרת המשתמש (UDF) בשאילתות GoogleSQL.

הגבלה	ברירת מחדל	הערות
הפלט המקסימלי לכל שורה	5 MB	כמות הנתונים המקסימלית שפונקציית ה-UDF ב-JavaScript יכולה להפיק כשמעבדים שורה אחת היא בערך 5MB.
מספר מקסימלי של שאילתות SQL מדור קודם שפועלות בו-זמנית עם פונקציות מוגדרות-משתמש (UDF) ב-JavaScript	‫6 שאילתות	בפרויקט יכולות להיות עד שש שאילתות SQL מדור קודם שמכילות פונקציות UDF ב-JavaScript. המגבלה הזו כוללת גם שאילתות אינטראקטיביות וגם שאילתות אצווה. המגבלה הזו לא חלה על שאילתות ב-GoogleSQL.
מספר מקסימלי של משאבי JavaScript UDF לכל שאילתה	‫50 משאבים	בכל עבודת שאילתה יכולים להיות עד 50 משאבי UDF של JavaScript, כמו blobs של קוד מוטבע או קבצים חיצוניים.
הגודל המקסימלי של blob של קוד בתוך השורה	32 KB	גודל ה-blob של קוד בתוך השורה ב-UDF יכול להיות עד 32KB.
הגודל המקסימלי של כל משאב קוד חיצוני	‫1MB	הגודל המקסימלי של כל משאב קוד JavaScript הוא 1MB.

המגבלות הבאות חלות על פונקציות מתמידות (UDF):

הגבלה	ברירת מחדל	הערות
האורך המקסימלי של שם פונקציה מוגדרת על ידי המשתמש	‫256 תווים	שם של פונקציה בהגדרת המשתמש יכול להכיל עד 256 תווים.
מספר הארגומנטים המקסימלי	‫256 ארגומנטים	פונקציה מוגדרת-משתמש יכולה לכלול עד 256 ארגומנטים.
האורך המקסימלי של שם ארגומנט	‫128 תווים	שם של ארגומנט בפונקציה מוגדרת-משתמש יכול להכיל עד 128 תווים.
העומק המקסימלי של שרשרת הפניות של UDF	‫16 מקורות	שרשרת הפניות של פונקציה בהתאמה אישית יכולה להכיל עד 16 הפניות.
העומק המקסימלי של ארגומנט או פלט מסוג STRUCT	‫15 רמות	ארגומנט או פלט של פונקציה מוגדרת על ידי המשתמש מסוג STRUCT יכולים להיות בעומק של עד 15 רמות.
מספר השדות המקסימלי בארגומנטים או בפלט מסוג STRUCT לכל פונקציה מוגדרת-משתמש (UDF)	‫1,024 שדות	פונקציה מוגדרת-משתמש יכולה להכיל עד 1,024 שדות בארגומנטים ובפלט מסוג STRUCT.
המספר המקסימלי של ספריות JavaScript בהצהרה CREATE FUNCTION	‫50 ספריות	הצהרת CREATE FUNCTION יכולה להכיל עד 50 ספריות JavaScript.
האורך המקסימלי של נתיבי ספריות JavaScript שכלולים	‫5,000 תווים	הנתיב של ספריית JavaScript שכלולה ב-UDF יכול להיות באורך של עד 5,000 תווים.
קצב העדכון המקסימלי לכל UDF לכל 10 שניות	‫5 עדכונים	בפרויקט אפשר לעדכן UDF עד חמש פעמים בכל 10 שניות.
המספר המקסימלי של פונקציות UDF מורשות לכל מערך נתונים		למידע נוסף על מערכי נתונים
פונקציות Python מוגדרות-משתמש: בייטים של אחסון תמונות לכל פרויקט בכל אזור	‎10 GiB	הגודל הכולל בבייטים של כל קובצי האימג' של הקונטיינרים שמשמשים פונקציות UDF ב-Python בפרויקט ובאזור ספציפיים.
פונקציות UDF ב-Python: מגבלת מוטציה	‫30 לדקה	אפשר ליצור או לעדכן פונקציות UDF ב-Python עד 30 פעמים בדקה לכל אזור בכל פרויקט.
פונקציות UDF של Python: מספר מקסימלי של פונקציות UDF בו-זמניות של Python	10	בכל פרויקט אפשר להריץ בו-זמנית עד 10 שאילתות שמפנות לפונקציות Python UDF.

פונקציות משירותים חיצוניים

המגבלות הבאות חלות על פונקציות מרוחקות ב-BigQuery.

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

הגבלה	ברירת מחדל	הערות
המספר המקסימלי של שאילתות בו-זמניות שמכילות פונקציות מרוחקות	‫10 שאילתות	אפשר להריץ עד עשר שאילתות בו-זמניות עם פונקציות מרוחקות לכל פרויקט.
גודל קלט מקסימלי	5 MB	הגודל הכולל המקסימלי של כל ארגומנטי הקלט משורה אחת הוא 5MB.
מגבלת גודל תגובת HTTP (פונקציות Cloud Run דור ראשון)	‎10MB	גוף התגובה של HTTP מפונקציית Cloud Run דור ראשון הוא עד 10MB. חריגה מהערך הזה גורמת לכשלים בשאילתות.
מגבלת הגודל של תגובת HTTP (פונקציות Cloud Run דור שני או Cloud Run)	‫15MB	גודל גוף תגובת HTTP מפונקציית Cloud Run מדור שני או מ-Cloud Run הוא עד 15MB. חריגה מהערך הזה גורמת לכשלים בשאילתות.
מגבלת הזמן המקסימלית להפעלת HTTP (פונקציות Cloud Run דור ראשון)	‫9 דקות	אתם יכולים להגדיר מגבלת זמן משלכם לפונקציית Cloud Run מהדור הראשון להפעלה ספציפית של HTTP, אבל מגבלת הזמן המקסימלית היא 9 דקות. חריגה ממגבלת הזמן שמוגדרת לפונקציית Cloud Run דור ראשון עלולה לגרום לכשלים בהפעלת HTTP ולכשלים בשאילתות.
מגבלת הזמן להפעלת HTTP (פונקציות Cloud Run מדור שני או Cloud Run)	20 דקות	מגבלת הזמן להפעלה ספציפית של HTTP בפונקציית Cloud Run (דור שני) או ב-Cloud Run. חריגה מהערך הזה עלולה לגרום לכשלים בהפעלת HTTP ולכשלים בשאילתות.
המספר המקסימלי של ניסיונות חוזרים להפעלת HTTP	20	מספר הניסיונות המקסימלי לביצוע חוזר של קריאת HTTP ספציפית לפונקציית Cloud Run דור ראשון, דור שני או Cloud Run. חריגה מהערך הזה עלולה לגרום לכשלים בהפעלת HTTP ולכשלים בשאילתות.

פונקציות טבלה

המגבלות הבאות חלות על פונקציות של טבלאות ב-BigQuery:

הגבלה	ברירת מחדל	הערות
האורך המקסימלי של שם פונקציית טבלה	‫256 תווים	השם של פונקציית טבלה יכול להכיל עד 256 תווים.
האורך המקסימלי של שם ארגומנט	‫128 תווים	האורך של שם ארגומנט של פונקציית טבלה יכול להיות עד 128 תווים.
מספר הארגומנטים המקסימלי	‫256 ארגומנטים	פונקציית טבלה יכולה להכיל עד 256 ארגומנטים.
העומק המקסימלי של שרשרת הפניות של פונקציית טבלה	‫16 קובצי עזר	שרשרת הפניות של פונקציות בטבלה יכולה לכלול עד 16 הפניות.
העומק המקסימלי של ארגומנט או פלט מהסוג STRUCT	‫15 רמות	ארגומנט STRUCT של פונקציית טבלה יכול להכיל עד 15 רמות. באופן דומה, רשומה STRUCT בפלט של פונקציית טבלה יכולה להיות בעומק של עד 15 רמות.
מספר השדות המקסימלי בארגומנט או בטבלת ההחזרה מסוג STRUCT לכל פונקציית טבלה	‫1,024 שדות	ארגומנט STRUCT של פונקציית טבלה יכול להכיל עד 1,024 שדות. באופן דומה, רשומה של STRUCT בפלט של פונקציית טבלה יכולה לכלול עד 1,024 שדות.
המספר המקסימלי של עמודות בטבלה שמוחזרת	‫1,024 עמודות	טבלה שמוחזרת על ידי פונקציית טבלה יכולה להכיל עד 1,024 עמודות.
האורך המקסימלי של שמות העמודות בטבלת ההחזרות	‫128 תווים	שמות העמודות בטבלאות שמוחזרות יכולים להיות באורך של עד 128 תווים.
מספר העדכונים המקסימלי לכל פונקציית טבלה בכל 10 שניות	5 עדכונים	בפרויקט אפשר לעדכן פונקציית טבלה עד חמש פעמים בכל 10 שניות.

פרוצדורות מאוחסנות ל-Apache Spark

המגבלות הבאות חלות על פרוצדורות מאוחסנות ב-BigQuery ל-Apache Spark:

מגבלה	ברירת מחדל	הערות
מספר מקסימלי של שאילתות בו-זמניות של תהליכים מאוחסנים	50	אפשר להריץ עד 50 שאילתות של פרוצדורות מאוחסנות בו-זמנית בכל פרויקט.
המספר המקסימלי של מעבדים בשימוש	12,000	אפשר להשתמש בעד 12,000 מעבדים לכל פרויקט. שאילתות שכבר עובדו לא נספרות במגבלה הזו. אפשר להשתמש בעד 2,400 מעבדים לכל מיקום בכל פרויקט, חוץ מהמיקומים הבאים: asia-south2 australia-southeast2 europe-central2 europe-west8 northamerica-northeast2 southamerica-west1 במיקומים האלה, אתם יכולים להשתמש בעד 500 מעבדים (CPU) לכל מיקום בכל פרויקט. אם מריצים שאילתות בו-זמנית במיקום במספר אזורים ובמיקום עם אזור אחד שנמצא באותו אזור גיאוגרפי, יכול להיות שהשאילתות יצרכו את אותה מכסת מעבד (CPU) בו-זמנית.
הגודל הכולל המקסימלי של דיסקים מתמידים סטנדרטיים שנמצאים בשימוש	‫204.8TB	אפשר להשתמש בדיסקים מתמידים סטנדרטיים בנפח של עד 204.8TB לכל מיקום בכל פרויקט. שאילתות שכבר עברו עיבוד לא נספרות במגבלה הזו. אם מריצים שאילתות בו-זמנית במיקום במספר אזורים ובמיקום עם אזור אחד שנמצא באותו אזור גיאוגרפי, יכול להיות שהשאילתות יצרכו את אותה מכסה של דיסק מתמיד סטנדרטי.

קובצי Notebook

כל המכסות והמגבלות של Dataform והמכסות והמגבלות של Colab Enterprise חלות על notebooks ב-BigQuery. המגבלות הבאות חלות גם:

מגבלה	ברירת מחדל	הערות
גודל ה-Notebook המקסימלי	20 MB	הגודל של מחברת הוא סכום הגודל של התוכן, המטא-נתונים והתקורה של הקידוד. כדי לראות את גודל התוכן של ה-Notebook, מרחיבים את הכותרת של ה-Notebook, לוחצים על תצוגה ואז על פרטי ה-Notebook.
המספר המקסימלי של בקשות לשנייה ל-Dataform	100	מחברות נוצרות ומנוהלות דרך Dataform. כל פעולה שיוצרת או משנה תיקיית Notebook נספרת במכסה הזו. המכסה הזו משותפת עם שאילתות שמורות. לדוגמה, אם מבצעים 50 שינויים ב-notebooks ו-50 שינויים בשאילתות שמורות בתוך שנייה אחת, מגיעים למכסה.

שאילתות שמורות

כל המכסות והמגבלות של Dataform חלות על שאילתות שמורות. בנוסף, חלות המגבלות הבאות:

מגבלה	ברירת מחדל	הערות
גודל מקסימלי של שאילתה שמורה	‎10MB
המספר המקסימלי של בקשות לשנייה ל-Dataform	100	השאילתות השמורות נוצרות ומנוהלות באמצעות Dataform. כל פעולה שיוצרת או משנה שאילתה שמורה נכללת במכסה הזו. המכסה הזו משותפת עם תיקיות Notebook. לדוגמה, אם מבצעים 50 שינויים ב-notebooks ו-50 שינויים בשאילתות שמורות תוך שנייה אחת, מגיעים למכסת השימוש.

שפת טיפול בנתונים (DML)

המגבלות הבאות חלות על הצהרות שפת הטיפול בנתונים (DML) ב-BigQuery:

הגבלה	ברירת מחדל	הערות
פקודות DML ביום	ללא הגבלה	מספר הצהרות ה-DML שאפשר להריץ בפרויקט ביום הוא בלתי מוגבל. הצהרות DML לא נספרות במסגרת מספר השינויים בטבלה ביום או מספר השינויים בטבלה מחולקת ביום עבור טבלאות מחולקות. חשוב לשים לב למגבלות הבאות שחלות על הצהרות DML.
‫INSERT פקודות DML בו-זמניות לכל טבלה ביום	‫1,500 הצהרות	‫1,500 ההצהרות הראשונות של INSERT מופעלות מיד אחרי שהן נשלחות. אחרי שמגיעים למגבלה הזו, מספר ההצהרות המקבילות של INSERT שכותבות לטבלה מוגבל ל-10. הצהרות INSERT נוספות מתווספות לתור PENDING. אפשר להוסיף לתור עד 100 הצהרות INSERT לכל טבלה בכל זמן נתון. כשהצהרת INSERT מסתיימת, הצהרת INSERT הבאה מוסרת מהתור ומופעלת. אם אתם צריכים להריץ הצהרות DML INSERT בתדירות גבוהה יותר, כדאי להשתמש ב-Storage Write API (gRPC) כדי להזרים נתונים לטבלה.
הצהרות DML לשינוי בו-זמני לכל טבלה	‫2 דוחות	ב-BigQuery מורצים עד שתי הצהרות DML משנות (UPDATE,‏ DELETE ו-MERGE) בו-זמנית לכל טבלה. פקודות DML נוספות לשינוי טבלה נכנסות לתור.
פקודות DML לשינוי נתונים בתור לכל טבלה	‫20 הצהרות	טבלה יכולה להכיל בתור עד 20 הצהרות DML לשינוי שממתינות להפעלה. אם שולחים פקודות DML נוספות לשינוי הטבלה, הפקודות האלה ייכשלו.
הזמן המקסימלי בתור לפקודת DML	‫7 שעות	פקודת DML אינטראקטיבית בעדיפות גבוהה יכולה להמתין בתור עד שבע שעות. אם ההצהרה לא הופעלה אחרי שבע שעות, היא נכשלת.
הקצב המקסימלי של פקודות DML לכל טבלה	‫25 הצהרות כל 10 שניות	בכל פרויקט אפשר להריץ עד 25 הצהרות DML כל 10 שניות לכל טבלה. גם INSERT וגם פקודות DML לשינוי נתונים נכללות במגבלה הזו.

מידע נוסף על שינוי של הצהרות DML זמין במאמרים בנושא INSERT בו-זמניות של DML וUPDATE, DELETE, MERGE בו-זמניות של DML.

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

המגבלות הבאות חלות על שאילתות עם כמה הצהרות ב-BigQuery.

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

ביטויי טבלה נפוצים (CTE) רקורסיביים בשאילתות

המגבלות הבאות חלות על ביטויי טבלה נפוצים (CTE) רקורסיביים ב-BigQuery.

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

אבטחה ברמת השורה

המגבלות הבאות חלות על כללי מדיניות הגישה ברמת השורה ב-BigQuery:

מגבלה	ברירת מחדל	הערות
מספר מקסימלי של כללי מדיניות גישה לשורות בכל טבלה	‫400 כללי מדיניות	טבלה יכולה לכלול עד 400 כללי מדיניות לגישה לשורות.
מספר מקסימלי של מדיניות גישה לשורות לכל שאילתה	6,000 כללי מדיניות	שאילתה יכולה לגשת ל-6,000 כללי מדיניות גישה לשורות לכל היותר.
מספר מקסימלי של הצהרות DDL ב-CREATE או ב-DROP לכל מדיניות, לכל 10 שניות	‫5 הצהרות	בכל 10 שניות, הפרויקט יכול ליצור עד חמש הצהרות CREATE או DROP לכל משאב של מדיניות גישה ברמת השורה.
‫DROP ALL ROW ACCESS POLICIES הצהרות לכל טבלה לכל 10 שניות	‫5 הצהרות	בפרויקט אפשר לבצע עד חמש הצהרות DROP ALL ROW ACCESS POLICIES לכל טבלה בכל 10 שניות.

מדיניות בנושא נתונים

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

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

BigQuery ML

המגבלות הבאות חלות על BigQuery ML.

משימות של השאילתה

כל המכסות וההגבלות של משימות שאילתה חלות על משימות שאילתה ב-GoogleSQL שמשתמשות בפונקציות ובהצהרות של BigQuery ML.

‫CREATE MODEL דפי חשבון

המגבלות הבאות חלות על משימות CREATE MODEL:

הגבלה	ברירת מחדל	הערות
CREATE MODEL שאילתות הצהרה לכל 48 שעות בכל פרויקט	‫20,000 שאילתות של הצהרות	חלק מהמודלים מאומנים באמצעות שירותי Vertex AI, שכוללים ניהול משאבים ומכסות משלהם.
מגבלת זמן הביצוע	24 שעות או 48 שעות	CREATE MODEL זמן הקצוב לתפוגה של משימה הוא 24 שעות, למעט משימות של סדרות זמן, AutoML וכוונון היפר-פרמטרים, שהזמן הקצוב לתפוגה שלהן הוא 48 שעות.

פונקציות AI גנרטיביות

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

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

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

תפקיד	דגם	אזור	בקשות לדקה	שורות לכל משימה
AI.GENERATE_TEXT ML.GENERATE_TEXT AI.GENERATE_TABLE AI.GENERATE AI.GENERATE_BOOL AI.GENERATE_DOUBLE AI.GENERATE_INT	gemini-2.0-flash-lite-001	‫US ו-EU במספר אזורים אזורים יחידים כפי שמתועד לגבי gemini-2.0-flash-lite-001 במיקומי נקודות הקצה של מודלים של Google	אין מכסה מוגדרת. המכסה נקבעת לפי מכסה דינמית משותפת (DSQ)‏1 והקצאת משאבים לפי התפוקה שנקבעה2	לא רלוונטי לרוחב פס מוקצה ‫10,500,000 ל-DSQ, לשיחה עם ממוצע של 500 טוקנים של קלט ו-50 טוקנים של פלט
	gemini-2.0-flash-001	US ו-EU (מספר אזורים) אזורים בודדים, כמו שמתועד לגבי gemini-2.0-flash-001 במאמר מיקומי נקודות הקצה של המודלים של Google		לא רלוונטי להקצאת משאבים לפי התפוקה שנקבעה ‫10,200,000 ל-DSQ, לקריאה עם ממוצע של 500 טוקנים של קלט ו-50 טוקנים של פלט
	gemini-2.5-flash	‫US ו-EU multi-regions אזורים יחידים כפי שמתועד לגבי gemini-2.5-flash במיקומי נקודות הקצה של מודלים של Google		לא רלוונטי להקצאת משאבים לפי התפוקה שנקבעה 9,300,000 ל-DSQ, לקריאה עם ממוצע של 500 טוקנים של קלט ו-50 טוקנים של פלט
	gemini-2.5-pro	‫US ו-EU במספר אזורים אזורים יחידים כפי שמתועד לגבי gemini-2.5-pro במיקומי נקודות הקצה של מודלים של Google		לא רלוונטי להקצאת משאבים לפי התפוקה שנקבעה 7,600,000 ל-DSQ, לקריאה עם ממוצע של 500 טוקנים של קלט ו-50 טוקנים של פלט
AI.IF AI.SCORE AI.CLASSIFY	מודלים שונים של gemini-2.5-*	US וEU מספר אזורים כל אזור יחיד שנתמך באחד מgemini-2.5-* models במיקומי נקודות הקצה של מודלים של Google	אין מכסה מוגדרת. המיכסה נקבעת לפי מיכסה משותפת דינמית (DSQ)1	‫10,000,000 לקריאה עם ממוצע של 500 טוקנים בכל שורת קלט ו-50 טוקנים של פלט.
AI.AGG	מודלים שונים של Gemini	מיקומים	אין מכסה מוגדרת. המכסה נקבעת לפי מכסה דינמית משותפת (DSQ)‏1.	20,000,000
AI.GENERATE_TEXT ML.GENERATE_TEXT	Anthropic Claude	מכסות לפי מודל ואזור	מכסות לפי מודל ואזור	הערך של בקשות לדקה * 60 * 6
	Llama	זמינות לפי אזור ומכסות של מודל Llama	זמינות לפי אזור ומכסות של מודל Llama
	Mistral AI	זמינות לפי אזור ומכסות של מודלי AI של Mistral	זמינות לפי אזור ומכסות של מודלי AI של Mistral
AI.GENERATE_EMBEDDING5 AI.EMBED AI.SIMILARITY AI.SEARCH VECTOR_SEARCH ML.GENERATE_EMBEDDING5	text-embedding text-multilingual-embedding	כל האזורים שבהם יש תמיכה במודלים מרוחקים	‫1,5003,4	‫80,000,000 לקריאה עם ממוצע של 50 אסימונים בכל שורת קלט ‫14,000,000 לקריאה עם ממוצע של 600 אסימונים בכל שורת קלט
	multimodalembedding	אזורים נתמכים באירופה	‫1203	43,200
		אזורים שאינם אזורים נתמכים באירופה	‫6003	216,000
	gemini-embedding-2	US, EU וגם global	אין מכסה מוגדרת. המכסה נקבעת לפי מכסה דינמית משותפת (DSQ)‏1.	לא רלוונטי

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

‫² הקצאת משאבים לפי התפוקה שנקבעה היא מינוי בעלות קבועה לתקופה קבועה, שזמין למספר תקופות. התכונה "הקצאת משאבים לפי התפוקה שנקבעה" מאפשרת לכם להקצות משאבים למודלים נתמכים של AI גנרטיבי ב-Agent Platform.

‫³ כדי להגדיל את המכסה, שולחים בקשה לשינוי מכסת ה-QPM ב-Agent Platform. צריך להמתין 30 דקות עד שהערך המוגדל של המכסה יתעדכן.

‫⁴ אפשר להגדיל את המכסה של מודלים של Agent Platform text-embedding ו-text-multilingual-embedding ל-10,000 RPM בלי אישור ידני. כתוצאה מכך, קצב העיבוד גדל ל-500,000,000 שורות לכל משימה או יותר, על סמך קריאה עם ממוצע של 50 אסימונים בכל שורת קלט.

‫⁵ הפונקציה הזו מוגבלת למקסימום של 5 משימות שפועלות בו-זמנית לכל פרויקט.

מידע נוסף על מגבלות המכסות של Agent Platform

מגבלות על מספר האסימונים בדקה

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

פונקציה	טוקנים לדקה	שורות לכל משימה	מספר המשימות שפועלות בו-זמנית
AI.GENERATE_EMBEDDING או ML.GENERATE_EMBEDDING כשמשתמשים במודל מרוחק על מודל gemini-embedding-001	‫10,000,000	‫12,000,000, לקריאה עם ממוצע של 300 טוקנים לכל שורה	5
AI.GENERATE_EMBEDDING או ML.GENERATE_EMBEDDING כשמשתמשים במודל מרוחק במודל gemini-embedding-2	‫5,000,000	1,440,000	5

מגבלות על מספר הטוקנים ביום

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

שם המכסה	מדד	היקף	ערך ברירת המחדל
טוקנים של קלט AI ביום	טוקנים של קלט שמשמשים את ה-LLM	ליום, לפרויקט	200,000,000,000
טוקנים של קלט AI ליום לכל משתמש	טוקנים של קלט שמשמשים את ה-LLM	ביום, בפרויקט, למשתמש	‫150,000,000,000
טוקנים של פלט מ-AI ביום	טוקנים של פלט ושל חשיבה שבהם משתמש מודל ה-LLM	לכל פרויקט, לכל יום	20,000,000,000
טוקנים של פלט AI ביום לכל משתמש	טוקנים של פלט ושל מחשבה שנעשה בהם שימוש על ידי מודל ה-LLM	ביום, בפרויקט, למשתמש	‫15,000,000,000

פונקציות של שירותי AI ב-Cloud

ההגבלות הבאות חלות על פונקציות שמשתמשות בשירותי AI ב-Cloud:

פונקציה	בקשות לדקה	שורות לכל משימה	מספר המשימות שפועלות בו-זמנית
ML.PROCESS_DOCUMENT עם מסמכים באורך ממוצע של חמישים עמודים	600	‫100,000 (על סמך ממוצע של 50 דפים בכל מסמך קלט)	5
ML.TRANSCRIBE	200	‫10,000 (על סמך אורך ממוצע של דקה אחת לכל קובץ אודיו קלט)	5
ML.ANNOTATE_IMAGE	1,800	648,000	5
ML.TRANSLATE	6,000	2,160,000	5
ML.UNDERSTAND_TEXT	600	‫21,600	5

מידע נוסף על מכסות לממשקי API של שירותי AI ב-Cloud מופיע במאמרים הבאים:

• מכסות ומגבלות של Cloud Translation API
• מכסות ומגבלות ב-Vision API
• מכסות ומגבלות של Natural Language API
• מכסות ומגבלות ב-Document AI
• מכסות ומגבלות של Speech-to-Text

הגדרות של מכסות לפונקציות

ברשימה הבאה מפורטות המכסות שחלות על פונקציות של AI גנרטיבי ושירותי Cloud AI:

• פונקציות שקוראות למודל של Agent Platform משתמשות במכסה אחת של Agent Platform, שהיא שאילתות לדקה (QPM). בהקשר הזה, השאילתות הן קריאות לבקשות מהפונקציה ל-API של המודל של Agent Platform. המכסה של QPM חלה על מודל בסיס ועל כל הגרסאות, המזהים והגרסאות המכווננות של המודל הזה. מגבלות המכסות של Agent Platform ל-AI גנרטיבי
• פונקציות שמבצעות קריאה לשירות AI ב-Cloud משתמשות במכסות הבקשות של שירות היעד. לפרטים, עיינו במאמר העזרה בנושא מכסות של שירות ה-AI ב-Cloud הרלוונטי.

• אלה המכסות של BigQuery ML:

  • בקשות לדקה. המכסה הזו היא המגבלה על מספר הקריאות לבקשות בדקה שהפונקציות יכולות לבצע לממשק ה-API של המודל של Agent Platform או של שירות ה-AI ב-Cloud. המגבלה הזו חלה על כל פרויקט, והיא משותפת לכל המשימות שמשתמשות באותה נקודת קצה של מודל.

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

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

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

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

    • בנקודת הקצה gemini-2.0-flash-lite-001, מספר השורות שאפשר לעבד באמצעות הפונקציה AI.GENERATE_TEXT או ML.GENERATE_TEXT תלוי במספר הטוקנים של הקלט והפלט. השירות יכול לעבד כ-7.6 מיליון שורות של קריאות עם מספר ממוצע של 2,000 אסימוני קלט ומספר מקסימלי של 50 אסימוני פלט. המספר הזה יורד לכמיליון שורות אם מספר הטוקנים הממוצע בקלט הוא 10,000 ומספר הטוקנים המקסימלי בפלט הוא 3,000.

      באופן דומה, נקודת הקצה gemini-2.0-flash-001 יכולה לעבד 4.4 מיליון שורות לקריאות עם מספר ממוצע של 2,000 אסימוני קלט ומספר מקסימלי של 50 אסימוני פלט, אבל רק כמיליון שורות לקריאות עם 10,000 אסימוני קלט ו-3,000 אסימוני פלט.

    • הפונקציה ML.PROCESS_DOCUMENT יכולה לעבד יותר שורות לכל משימה במסמכים קצרים לעומת מסמכים ארוכים.

    • הפונקציה ML.TRANSCRIBE יכולה לעבד יותר שורות לכל משימה עבור קטעי אודיו קצרים בהשוואה לקטעי אודיו ארוכים.

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

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

• יש לי מכסה של 1,000 שאילתות לדקה ב-Agent Platform, אז שאילתה עם 100,000 שורות אמורה להימשך כ-100 דקות. למה העבודה נמשכת יותר זמן?

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

• איך צריך לפרש את המכסה של שורות לכל משימה?

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

• מה קורה אם מריצים משימת הסקה באצווה בטבלה עם יותר שורות מהמכסה של שורות לכל משימה, למשל 10,000,000 שורות?

  ‫BigQuery מעבד רק את מספר השורות שצוין במכסת השורות לכל משימה. החיוב מתבצע רק על הקריאות ל-API שבוצעו בהצלחה למספר השורות הזה, ולא על כל 10,000,000 השורות בטבלה. לגבי שאר השורות, BigQuery מגיב לבקשה עם השגיאה A retryable error occurred: the maximum size quota per query has reached, שמוחזרת בעמודה status של התוצאה. אתם יכולים להשתמש בסקריפטים האלה של SQL או בחבילה הזו של Dataform כדי לחזור על קריאות להסקת מסקנות עד שכל השורות יעובדו בהצלחה.

• יש לי הרבה יותר שורות לעיבוד מאשר המכסה של שורות לכל משימה. האם פיצול השורות לכמה שאילתות והרצה שלהן בו-זמנית יעזרו?

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

BigQuery Graph

המגבלות הבאות חלות על BigQuery Graph:

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

BI Engine

המגבלות הבאות חלות על BigQuery BI Engine.

הגבלה	ברירת מחדל	הערות
גודל ההזמנה המקסימלי לכל פרויקט לכל מיקום (BigQuery BI Engine)	‫250GiB	‫250GiB הוא הגודל המקסימלי של הקצאת מקום לכל פרויקט בכל מיקום. אתם יכולים לבקש להגדיל את קיבולת ההזמנה המקסימלית של הפרויקטים שלכם. אפשר להגדיל את ההזמנות ברוב האזורים, והתהליך עשוי להימשך 3 ימי עסקים או יותר, בהתאם לגודל ההגדלה המבוקשת. במקרים דחופים, אפשר לפנות לנציג Google Cloud שלכם או ל-Cloud Customer Care.
מספר השורות המקסימלי לכל שאילתה	7 מיליארד	מספר השורות המקסימלי לכל שאילתה.

BigQuery sharing (לשעבר Analytics Hub)

המגבלות הבאות חלות על BigQuery sharing (לשעבר Analytics Hub):

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

גילוי אוטומטי של Knowledge Catalog

המגבלות הבאות חלות על גילוי אוטומטי של Knowledge Catalog:

הגבלה	ברירת מחדל	הערות
מספר מקסימלי של טבלאות BigQuery,‏ BigLake או טבלאות חיצוניות לכל קטגוריה של Cloud Storage שנתמכות בסריקת גילוי	‫1,000 טבלאות ב-BigQuery לכל דלי	אפשר ליצור עד 1,000 טבלאות ב-BigQuery לכל קטגוריה של Cloud Storage.

מכסות ומגבלות של ה-API

המכסות וההגבלות האלה חלות על בקשות של BigQuery API.

BigQuery API

המכסות הבאות חלות על בקשות של BigQuery API (ליבה):

מכסה	ברירת מחדל	הערות
בקשות ביום	ללא הגבלה	בפרויקט שלכם אפשר לשלוח מספר בלתי מוגבל של בקשות ל-BigQuery API ביום. הצגת המכסה במסוף Google Cloud
‫ tabledata.list בייטים לדקה לכל היותר	‫7.5GB במספר אזורים; 3.7GB בכל שאר האזורים	הפרויקט יכול להחזיר עד 7.5GB של נתוני שורות בטבלה לדקה באמצעות tabledata.list במספר אזורים us ו-eu, ועד 3.7GB של נתוני שורות בטבלה לדקה בכל שאר האזורים. המכסה הזו חלה על הפרויקט שמכיל את הטבלה שנקראת. גם ממשקי API אחרים, כולל jobs.getQueryResults וקבלת תוצאות מ- jobs.query ו- jobs.insert, יכולים לנצל את המכסה הזו. מידע על פתרון בעיות מופיע בדף פתרון בעיות. הצגת המכסה במסוף Google Cloud ‫BigQuery Storage Read API יכול לעמוד בקצב העברת נתונים גבוה משמעותית מ-tabledata.list. אם אתם צריכים קצב העברת נתונים גבוה יותר מהמותר במכסה הזו, כדאי להשתמש ב-BigQuery Storage Read API.

המגבלות הבאות חלות על בקשות של BigQuery API (ליבה):

הגבלה	ברירת מחדל	הערות
מספר מקסימלי של בקשות API לשנייה לכל משתמש לכל שיטה (method)	‫100 בקשות	משתמש יכול לשלוח עד 100 בקשות API בשנייה ל-method של API. אם משתמש שולח יותר מ-100 בקשות בשנייה ל-method, יכול להיות שתתרחש הגבלת קצב. המגבלה הזו לא חלה על הזנת זרם נתונים. מידע על פתרון בעיות מופיע בדף פתרון בעיות.
המספר המקסימלי של בקשות API בו-זמניות לכל משתמש	‫300 בקשות	אם משתמש שולח יותר מ-300 בקשות בו-זמנית, יכול להיות שהמערכת תגביל את קצב הבקשות. המגבלה הזו לא חלה על הזנות זרם נתונים.
הגודל המקסימלי של request header	‎16 KiB	בקשת BigQuery API יכולה להיות בגודל של עד 16KiB, כולל כתובת ה-URL של הבקשה וכל הכותרות. המגבלה הזו לא חלה על גוף הבקשה, למשל בבקשת POST.
מקסימום jobs.get בקשות לשנייה	‫1,000 בקשות	בפרויקט אפשר לשלוח עד 1,000 בקשות של jobs.get לשנייה.
גודל התגובה המקסימלי של jobs.query	20 MB	כברירת מחדל, אין מגבלה על מספר השורות של נתונים שמוחזרים על ידי jobs.query לכל דף תוצאות. עם זאת, יש מגבלה של 20MB על גודל התגובה המקסימלי. אפשר לשנות את מספר השורות שיוחזרו באמצעות הפרמטר maxResults.
גודל השורה המקסימלי ב- jobs.getQueryResults	20 MB	הגודל המקסימלי של השורה הוא משוער, כי המגבלה מבוססת על הייצוג הפנימי של נתוני השורה. המגבלה נאכפת במהלך המרת הקידוד.
מקסימום projects.list בקשות לשנייה	‫10 בקשות	משתמש יכול לשלוח עד 10 בקשות projects.list בשנייה.
המספר המקסימלי של בקשות tabledata.list לשנייה	‫1,000 בקשות	בפרויקט שלכם אפשר לשלוח עד 1,000 בקשות tabledata.list בשנייה.
מספר השורות המקסימלי בכל תשובה של tabledata.list	‫100,000 שורות	קריאה ל-tabledata.list יכולה להחזיר עד 100,000 שורות בטבלה. מידע נוסף זמין במאמר חומר עזר: מגבלות וקריטריונים של API.
גודל שורה מקסימלי tabledata.list	‫100MB	הגודל המקסימלי של השורה הוא משוער, כי המגבלה מבוססת על הייצוג הפנימי של נתוני השורה. המגבלה נאכפת במהלך קידוד מחדש.
מקסימום tables.insert בקשות לשנייה	‫10 בקשות	משתמש יכול לשלוח עד 10 בקשות tables.insert בשנייה. ה-method‏ tables.insert יוצרת טבלה ריקה חדשה במערך נתונים.

BigQuery Connection API

המכסות הבאות חלות על בקשות ל-BigQuery Connection API:

מכסה	ברירת מחדל	הערות
בקשות קריאה לדקה	‫1,000 בקשות לדקה	בפרויקט שלכם אפשר לבצע עד 1,000 בקשות בדקה לשיטות של BigQuery Connection API שקוראות נתוני חיבור. הצגת המכסה במסוף Google Cloud
בקשות כתיבה לדקה	‫100 בקשות לדקה	בפרויקט שלכם אפשר לשלוח עד 100 בקשות בדקה ל-BigQuery Connection API, כדי ליצור או לעדכן חיבורים. הצגת המכסה במסוף Google Cloud
חיבורי BigQuery Omni שנוצרו בדקה	10 חיבורים שנוצרו בדקה	בכל דקה, אפשר ליצור בפרויקט עד 10 חיבורים ל-BigQuery Omni, בסך הכול ב-AWS וב-Azure.
שימושים בחיבור BigQuery Omni	‫500 שימושים בחיבור לדקה	בפרויקט שלכם אפשר להשתמש בחיבור של BigQuery Omni עד 500 פעמים בדקה. ההרשאות האלה חלות על פעולות שמשתמשות בחיבור כדי לגשת לחשבון AWS, כמו שליחת שאילתה לטבלה.

BigQuery Migration API

המגבלות הבאות חלות על BigQuery Migration API:

הגבלה	ברירת מחדל	הערות
גודל קובץ בודד לתרגום SQL באצווה	‫10MB	כל קובץ מקור וקובץ מטא-נתונים יכול להיות בגודל של עד 10MB. המגבלה הזו לא חלה על קובץ ה-ZIP של המטא-נתונים שנוצר על ידי כלי החילוץ dwh-migration-dumper משורת הפקודה.
הגודל הכולל של קובצי המקור לתרגום SQL באצווה	‎1GB	הגודל הכולל של כל קובצי הקלט שהועלו ל-Cloud Storage יכול להיות עד 1GB. זה כולל את כל קובצי המקור, ואת כל קובצי המטא-נתונים אם בחרתם לכלול אותם.
גודל מחרוזת הקלט לתרגום SQL אינטראקטיבי	‫1MB	המחרוזת שמזינים לתרגום אינטראקטיבי של SQL לא יכולה להיות גדולה מ-1MB. כשמריצים תרגומים אינטראקטיביים באמצעות Translation API, המגבלה הזו חלה על הגודל הכולל של כל הקלטים של המחרוזות.
גודל קובץ התצורה המקסימלי לתרגום SQL אינטראקטיבי	50MB	הגודל של קובצי מטא-נתונים בודדים (דחוסים) וקובצי תצורה של YAML ב-Cloud Storage לא יכול לחרוג מ-50MB. אם גודל הקובץ גדול מ-50MB, המתרגם האינטראקטיבי מדלג על קובץ התצורה הזה במהלך התרגום ומציג הודעת שגיאה. אחת הדרכים להקטין את הגודל של קובץ המטא-נתונים היא להשתמש בדגלים —database או –schema כדי לסנן מסדי נתונים כשיוצרים את המטא-נתונים.
המספר המקסימלי של הצעות מ-Gemini לשעה	‫1,000 (אפשר לצבור עד 10,000 אם לא משתמשים בהם)	במקרה הצורך, תוכלו לבקש הגדלה של המכסה באמצעות פנייה אל Cloud Customer Care.

המכסות הבאות חלות על BigQuery Migration API. ברוב המקרים, ערכי ברירת המחדל הבאים רלוונטיים. יכול להיות שברירות המחדל של הפרויקט שלכם שונות:

מכסה	ברירת מחדל	הערות
EDWMigration Service List Requests per minute מספר בקשות הרשימה של EDWMigration Service לדקה לכל משתמש	‫12,000 בקשות ‫2,500 בקשות	בכל פרויקט אפשר לשלוח עד 12,000 בקשות List ל-Migration API בדקה. כל משתמש יכול לשלוח עד 2,500 בקשות לרשימה של Migration API בדקה. הצגת המכסות במסוף Google Cloud
EDWMigration Service Get Requests per minute בקשות Get של EDWMigration Service לדקה לכל משתמש	‫25,000 בקשות ‫2,500 בקשות	בכל פרויקט אפשר לשלוח עד 25,000 בקשות Get ל-Migration API בדקה. כל משתמש יכול לשלוח עד 2,500 בקשות Get ל-Migration API בדקה. הצגת מכסות במסוף Google Cloud
EDWMigration Service Other Requests per minute EDWMigration Service Other Requests per minute per user	‫25 בקשות ‫5 בקשות	בכל דקה אפשר לשלוח מהפרויקט עד 25 בקשות API אחרות ל-Migration API. כל משתמש יכול לשלוח עד 5 בקשות API אחרות ל-Migration API בדקה. הצגת מכסות במסוף Google Cloud
בקשות לתרגום SQL אינטראקטיבי לדקה בקשות אינטראקטיביות לתרגום SQL לדקה לכל משתמש	‫200 בקשות ‫50 בקשות	בכל פרויקט אפשר לשלוח עד 200 בקשות לשירות תרגום SQL בכל דקה. כל משתמש יכול להגיש עד 50 בקשות אחרות לשירות תרגום SQL בדקה. הצגת מכסות במסוף Google Cloud

BigQuery Reservation API

המכסות הבאות חלות על בקשות של BigQuery Reservation API:

מכסה	ברירת מחדל	הערות
בקשות לדקה לכל אזור	‫100 בקשות	בכל פרויקט אפשר לבצע עד 100 קריאות לשיטות של BigQuery Reservation API בדקה לכל אזור. הצגת המכסות במסוף Google Cloud
מספר הקריאות ל-SearchAllAssignments לדקה בכל אזור	‫100 בקשות	בכל פרויקט אפשר לשלוח עד 100 קריאות ל-method‏ SearchAllAssignments בדקה לכל אזור. הצגת מכסות במסוף Google Cloud
בקשות ל-SearchAllAssignments לדקה לכל אזור לכל משתמש	‫10 בקשות	כל משתמש יכול לבצע עד 10 קריאות ל-method‏ SearchAllAssignments לדקה בכל אזור. הצגת מכסות ב Google Cloud מסוף (בתוצאות החיפוש ב Google Cloud מסוף, מחפשים per user).

BigQuery Data Policy API

המגבלות הבאות חלות על Data Policy API (תצוגה מקדימה):

הגבלה	ברירת מחדל	הערות
מספר השיחות המקסימלי של dataPolicies.list	‫400 בקשות לדקה לכל פרויקט ‫600 בקשות לדקה לכל ארגון
מספר השיחות המקסימלי ב-dataPolicies.testIamPermissions.	‫400 בקשות לדקה לכל פרויקט ‫600 בקשות לדקה לכל ארגון
המספר המקסימלי של בקשות קריאה.	‫1,200 בקשות לדקה לכל פרויקט ‫1,800 בקשות לדקה לכל ארגון	זה כולל קריאות ל-dataPolicies.get ול-dataPolicies.getIamPolicy.
מספר בקשות הכתיבה המקסימלי.	‫600 בקשות לדקה לכל פרויקט 900 בקשות לדקה לכל ארגון	האיסור הזה כולל שיחות אל: dataPolicies.create dataPolicies.delete dataPolicies.setIamPolicy dataPolicies.patch

IAM API

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

מכסה	ברירת מחדל	הערות
‫IamPolicy בקשות לדקה לכל משתמש	‫1,500 בקשות לדקה לכל משתמש	כל משתמש יכול לשלוח עד 1,500 בקשות לדקה בכל פרויקט. הצגת המכסה ב Google Cloud מסוף
‫IamPolicy בקשות לדקה לכל פרויקט	‫3,000 בקשות לדקה לכל פרויקט	בפרויקט אפשר לשלוח עד 3,000 בקשות לדקה. הצגת המכסה ב Google Cloud מסוף
אזור יחיד SetIAMPolicy בקשות לדקה לכל פרויקט	‫1,000 בקשות לדקה לכל פרויקט	בפרויקט עם אזור יחיד אפשר לשלוח עד 1,000 בקשות לדקה. הצגת המכסה ב Google Cloud מסוף
במספר אזורים ‫SetIAMPolicy בקשות לדקה לכל פרויקט	‫2,000 בקשות לדקה לכל פרויקט	הפרויקט שלכם במספר אזורים יכול לשלוח עד 2,000 בקשות לדקה. הצגת המכסה במסוף Google Cloud
בקשות לכל האזורים SetIAMPolicy לדקה לכל פרויקט	‫200 בקשות לדקה לכל פרויקט	בפרויקט Omni-region אפשר לשלוח עד 200 בקשות לדקה. הצגת המכסה במסוף Google Cloud

Storage Read API

המכסות הבאות חלות על בקשות של BigQuery Storage Read API:

מכסה	ברירת מחדל	הערות
קריאת בקשות של מישור הנתונים לדקה לכל משתמש	‫25,000 בקשות	כל משתמש יכול לבצע עד 25,000 קריאות ל-ReadRows לדקה בכל פרויקט. הצגת המכסה במסוף Google Cloud
מספר מקסימלי של חיבורי קריאה בו-זמניים	‫2,000 במספר אזורים, 400 באזורים	מספר מקסימלי של חיבורים בו-זמניים ל-ReadRows לכל פרויקט. ברירת המחדל היא 2,000 חיבורים ב-us וב-eu במספר אזורים, ו-400 חיבורים באזורים אחרים. הזמינות בפועל של החיבור יכולה להשתנות בהתאם לעומס הכולל על השירות ולביקוש באזור. ההתאמה הדינמית הזו מבטיחה חלוקה הוגנת של המשאבים ושמירה על יציבות השירות לכל המשתמשים. כשהשידור נסגר כדי לשמור על הוגנות או כשמגיעים למגבלת החיבורים, מקבלים את השגיאה RESOURCE_EXHAUSTED ‏ (HTTP 429). הבקשות להגדלת המכסות (QIR) נבדקות על סמך דפוסי השימוש הקודמים בפרויקט והזמינות הכללית של המשאבים באזור. הצגת המכסה במסוף Google Cloud
קריאת בקשות של מישור הבקרה לדקה לכל משתמש	‫5,000 בקשות	כל משתמש יכול לבצע עד 5,000 קריאות לפעולות של מטא-נתונים ב-Storage Read API לדקה בכל פרויקט. הקריאות למטא-נתונים כוללות את השיטות CreateReadSession ו-SplitReadStream. הצגת המכסה במסוף Google Cloud

המגבלות הבאות חלות על בקשות של BigQuery Storage Read API:

הגבלה	ברירת מחדל	הערות
אורך מקסימלי של שורה או מסנן	‫1MB	כשמשתמשים בקריאה ל-Storage Read API CreateReadSession, יש מגבלה של אורך מקסימלי של 1MB לכל שורה או מסנן.
גודל מקסימלי של נתונים שעברו סריאליזציה	‫128MB	כשמשתמשים בקריאה ל-Storage Read API ReadRows, הייצוג הסדרתי של הנתונים בהודעה ReadRowsResponse לא יכול להיות גדול מ-128MB.
השימוש המקסימלי בזיכרון לכל זרם	1.5 GB	הזיכרון המקסימלי לכל סטרימינג הוא משוער, כי המגבלה מבוססת על הייצוג הפנימי של נתוני השורות. יכול להיות ששידורים שמשתמשים ביותר מ-1.5GB זיכרון לשורה אחת ייכשלו. מידע נוסף זמין במאמר פתרון בעיות שקשורות לחריגה ממגבלות המשאבים.

Storage Write API ‏ (gRPC)

המכסות הבאות חלות על בקשות של Storage Write API (gRPC). אפשר להחיל את המכסות הבאות ברמת התיקייה. המכסות האלה מצטברות ומשותפות בין כל פרויקטי הבת. כדי להפעיל את ההגדרה הזו, צריך לפנות ל-Cloud Customer Care.

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

מכסה	ברירת מחדל	הערות
חיבורי כתיבה בו-זמניים	‫5,000 באזור; 20,000 במספר אזורים	המכסה של חיבורים בו-זמניים מבוססת על פרויקט הלקוח שיוזם את הבקשה ל-Storage Write API‏ (gRPC), ולא על הפרויקט שמכיל את משאב מערך הנתונים ב-BigQuery. הפרויקט שממנו נשלחה הבקשה הוא הפרויקט שמשויך למפתח ה-API או לחשבון השירות. הפרויקט יכול לפעול עם 5,000 חיבורים בו-זמניים באזור אחד, או עם 20,000 חיבורים בו-זמניים באזורים מרובים US ו-EU. החיבור צריך להיות ארוך טווח, וצריך להשתמש בו כדי לשלוח כמה שיותר בקשות. לא מומלץ להשתמש בחיבורים לזמן קצר, והשימוש בהם עלול לגרום לניצול מוגזם של מכסת החיבורים בו-זמנית. למטרות חישוב מכסות, מומלץ שמשך החיבור יהיה כמה דקות לפחות. כשמשתמשים בסטרימינג שמוגדר כברירת מחדל ב-Java או ב-Go, מומלץ להשתמש בריבוב של Storage Write API (gRPC)‎ כדי לכתוב לכמה טבלאות יעד עם חיבורים משותפים, וכך לצמצם את מספר החיבורים הכולל שנדרש. אם אתם משתמשים במחבר Beam עם סמנטיקה של at-least-once, אתם יכולים להגדיר את UseStorageApiConnectionPool לערך TRUE כדי להפעיל מולטיפלקסינג. צפייה במכסה במסוף Google Cloud ב-Cloud Monitoring אפשר לראות את מדדי המכסות והמגבלות של השימוש בפרויקטים. בוחרים את השם של מגבלת החיבורים בו-זמנית בהתאם לאזור שלכם. האפשרויות הן ConcurrentWriteConnectionsPerProject,‏ ConcurrentWriteConnectionsPerProjectEU ו-ConcurrentWriteConnectionsPerProjectRegion עבור us,‏ eu ואזורים אחרים, בהתאמה. מומלץ מאוד להגדיר התראות כדי לעקוב אחרי ניצול המכסות והמגבלות. בנוסף, אם דפוסי התנועה שלכם כוללים קפיצות חדות או צמיחה אורגנית קבועה, כדאי להגדיל את המכסה ב-25% עד 50% כדי להתמודד עם ביקוש לא צפוי.
תפוקה	תפוקה של 3GB לשנייה במספר אזורים, 300MB לשנייה באזורים	אפשר להעביר בסטרימינג עד ‎3 GBps באזורים us ו-eu, ועד ‎300 MBps באזורים אחרים לכל פרויקט. הצגת המכסה במסוף Google Cloud ב-Cloud Monitoring אפשר לראות את מדדי המכסות והמגבלות של השימוש בפרויקטים. בוחרים את שם מגבלת ה-throughput בהתאם לאזור. האפשרויות הן AppendBytesThroughputPerProject,‏ AppendBytesThroughputPerProjectEU ו-AppendBytesThroughputPerProjectRegion לאזורים us,‏ eu ואזורים אחרים, בהתאמה. מכסת קצב העברת הנתונים בכתיבה נמדדת על סמך הפרויקט שבו נמצאת קבוצת הנתונים של היעד, ולא על סמך פרויקט הלקוח. מומלץ מאוד להגדיר התראות כדי לעקוב אחרי השימוש במכסות ובמגבלות. בנוסף, אם יש עלייה חדה בדפוסי התנועה או צמיחה אורגנית קבועה, כדאי להגדיל את המכסה ב-25% עד 50% כדי להתמודד עם ביקוש לא צפוי.
‫CreateWriteStream בקשות	‫10,000 שידורים בכל שעה, לכל פרויקט בכל אזור	אפשר לקרוא ל-CreateWriteStream עד 10,000 פעמים בשעה לכל פרויקט בכל אזור. מומלץ להשתמש בשידור ברירת המחדל אם לא נדרשת סמנטיקה של בדיוק פעם אחת. המכסה הזו היא לשעה, אבל המדד שמוצג במסוף Google Cloud הוא לדקה.
בייטים של סטרימינג בהמתנה	‫10TB במספר אזורים, 1TB באזורים	לכל פעולת Commit שמפעילים, אפשר לבצע Commit של עד 10 TB באזורים הגיאוגרפיים us ו-eu, ושל 1 TB באזורים אחרים. אין דיווח מכסות על המכסה הזו.

המגבלות הבאות חלות על בקשות של Storage Write API (gRPC):

הגבלה	ברירת מחדל	הערות
שמירת שינויים באצווה	‫10,000 מקורות נתונים לכל טבלה	אפשר להעביר עד 10,000 סטרימים בכל קריאה ל-BatchCommitWriteStream.
AppendRows גודל הבקשה	20 MB	גודל הבקשה המקסימלי הוא 20MB.

הזנת זרם נתונים

המכסות וההגבלות הבאות חלות כשמעבירים נתונים ל-BigQuery באמצעות BigQuery Storage Write API (REST). במאמר פתרון בעיות שקשורות למכסות מוסבר איך לא לחרוג מהמגבלות האלה. אם תחרגו מהמכסות האלה, מערכת BigQuery תחזיר שגיאה quotaExceeded. יכול להיות שמכסת המשאבים שהוקצו לכם ב-BigQuery תצומצם אם לא נעשה בה שימוש משמעותי במשך יותר משנה.

הגבלה	ברירת מחדל	הערות
מספר הבייטים המקסימלי לשנייה בכל פרויקט באזורים us ו-eu	‫1GB לשנייה	הפרויקט יכול להעביר בסטרימינג עד 1GB לשנייה. המכסה הזה הוא מצטבר במספר אזורים נתון. במילים אחרות, סכום הבייטים לשנייה שמועברים בסטרימינג לכל הטבלאות בפרויקט נתון במספר אזורים מוגבל ל-1GB. חריגה מהמגבלה הזו גורמת לשגיאות quotaExceeded. במקרה הצורך, אפשר לפנות אל Cloud Customer Care כדי לבקש הגדלה של המכסה. כדאי לבקש הגדלה מוקדם ככל האפשר, לפחות שבועיים לפני שצריך אותה. לוקח זמן עד שהגדלת המכסה נכנסת לתוקף, במיוחד אם מדובר בהגדלה משמעותית.
מספר הבייטים המקסימלי לשנייה בכל פרויקט בכל המיקומים האחרים	‫300MB לשנייה	הפרויקט יכול להעביר בסטרימינג עד 300MB לשנייה בכל המיקומים, חוץ מהאזורים הגיאוגרפיים us ו-eu שכוללים מספר אזורים. המכסה הזו מצטברת במספר אזורים נתון. במילים אחרות, סכום הבייטים לשנייה שמועברים בסטרימינג לכל הטבלאות בפרויקט נתון באזור מסוים מוגבל ל-300MB. חריגה מהמגבלה הזו גורמת לשגיאות מסוג quotaExceeded. במקרה הצורך, תוכלו לבקש הגדלה של המכסה באמצעות פנייה אל Cloud Customer Care. כדאי לשלוח את הבקשה להגדלת המכסה מוקדם ככל האפשר, ולפחות שבועיים לפני שתזדקקו לה. לוקח זמן עד שהגדלת המכסה נכנסת לתוקף, במיוחד אם מדובר בהגדלה משמעותית.
גודל שורה מקסימלי	‎10MB	חריגה מהערך הזה גורמת לשגיאות מסוג invalid.
מגבלת הגודל של בקשות HTTP	‎10MB	חריגה מהערך הזה גורמת לשגיאות מסוג invalid. באופן פנימי, הבקשה מתורגמת מ-HTTP JSON למבנה נתונים פנימי. למבנה הנתונים המתורגם יש מגבלת גודל משלו. קשה לחזות את הגודל של מבנה הנתונים הפנימי שנוצר, אבל אם בקשות ה-HTTP יהיו בגודל של עד 10MB, הסיכוי להגיע למגבלה הפנימית נמוך.
מספר השורות המקסימלי לכל בקשה	‫50,000 שורות	מומלץ להוסיף עד 500 שורות. הוספה של בקשות לאצווה יכולה לשפר את הביצועים ואת קצב העברת הנתונים עד לנקודה מסוימת, אבל זה בא על חשבון זמן האחזור לכל בקשה. אם יש מעט מדי שורות בכל בקשה, התקורה של כל בקשה עלולה להפוך את ההטמעה ללא יעילה. יותר מדי שורות לכל בקשה, וקצב העברת הנתונים עלול לרדת. כדאי לבצע ניסוי עם נתונים מייצגים (סכימה וגדלי נתונים) כדי לקבוע את גודל האצווה האידיאלי לנתונים שלכם.
אורך השדה: insertId	‫128 תווים	חריגה מהערך הזה גורמת לשגיאות מסוג invalid.

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

רוחב פס

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

מכסה	ברירת מחדל	הערות
רוחב הפס המקסימלי של השלמת חוסר בנתונים (data backfill) בשכפול של מערכי נתונים באזורים שונים, לכל אזור שבו יש תעבורת נתונים יוצאת (egress) של נתונים באזורים שונים מהרפליקה הראשית לרפליקות המשניות.	‫10 GiBps פיזיים לכל אזור לכל ארגון
רוחב פס מקסימלי של שכפול שוטף של מערכי נתונים בין אזורים לכל אזור שבו יש תעבורת נתונים יוצאת (egress) בין אזורים מהרפליקה הראשית לרפליקות המשניות.	‫5‎ GiBps פיזיים לכל אזור בכל ארגון
רוחב הפס המקסימלי של רפליקציית טורבו של מערכי נתונים באזורים שונים, לכל אזור שבו יש תעבורת נתונים יוצאת (egress) בין אזורים מהרפליקה הראשית לרפליקות המשניות.	‫‎5 physical GiBps לכל אזור בכל ארגון	מכסת רוחב הפס של רפליקציית טורבו של קבוצת נתונים בין אזורים לא חלה על פעולת מילוי החוסרים הראשונית.

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

המכסות הבאות חלות על רוחב הפס להעתקת טבלאות בין אזורים:

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