ממשק Google Drive API הוא שירות משותף, ולכן אנחנו מגבילים את השימוש בו כדי לוודא שכל המשתמשים משתמשים בו בצורה הוגנת, וכדי להגן על הביצועים הכוללים של מערכת Google Workspace.
ההגבלות מוגדרות במונחים של יחידות מכסה, יחידת מידה מופשטת שמייצגת את השימוש במשאבים ב-Google Drive.
מכסות ל-Drive API
יש שלושה סוגים של מכסות:
לדקה לכל פרויקט בענן: זהו מספר יחידות המכסה שפרויקט Google Cloud יכול להשתמש בהן בדקה אחת.
לדקה לכל משתמש לכל פרויקט: זהו מספר יחידות המכסה שכל משתמש יכול להשתמש בהן בפרויקט בענן. המגבלה הזו נועדה לעזור לכם לוודא שהשימוש יתחלק באופן הוגן בין המשתמשים.
בכל יום לכל פרויקט: הגדרה זו מגדירה את מספר הבייטים המקסימלי שפרויקט Google Cloud יכול להוציא בפרק זמן של 24 שעות לפני שמתחילים לחייב עליו.
בטבלה הבאה מפורטות המגבלות האלה:
| סוג מכסת השימוש | מגבלה |
|---|---|
| לדקה לכל פרויקט | 1,000,000 יחידות מכסה |
| לדקה, למשתמש, לפרויקט | 325,000 יחידות מכסה |
| לכל פרויקט ליום | 1TB |
אם תחרגו ממכסה, תקבלו קוד סטטוס 403: User rate limit
exceeded HTTP בתשובה. יכול להיות שגם בדיקות נוספות של מגבלת הקצב ב-Drive
יניבו תגובה מסוג 429: Rate limit
exceeded. במקרה כזה, צריך להשתמש באלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ולנסות שוב מאוחר יותר.
סף החיוב היומי
המגבלה הזו לכל פרויקט ביום מגדירה את המספר המקסימלי של יחידות מכסה שפרויקט Google Cloud יכול להשתמש בהן בפרק זמן של 24 שעות לפני שמתחילים לחייב עליו.
אם השימוש שלכם נמוך מהסף הזה, לא תחויבו בחשבון Google Cloud. פרטי החיוב המלאים ישותפו בהמשך בשנת 2026, לפחות 90 יום לפני ששינויים ייכנסו לתוקף.
אי אפשר לבקש להגדיל את המגבלה הזו של סף יומי.
בטבלה הבאה מפורטת המגבלה:
| סוג מגבלת הסף | מגבלה |
|---|---|
| לכל פרויקט ליום | 400,000,000 יחידות מכסה |
מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.
ניצול המכסה לכל שיטה
מספר יחידות המכסה שנצרכות לכל בקשה משתנה בהתאם לשיטה שנקראת. בטבלה הבאה מפורט השימוש ביחידות המכסה לכל שיטה:
| פעולה | יחידות מיכסה |
|---|---|
הקראת פריטים, כמו files.get |
5 |
פריטים ברשימה, כמו files.list |
100 |
הורדת פריטים, כמו files.download |
200 |
עריכת פריטים, כמו files.update |
50 |
פעולות אחרות, כמו files.generateIds |
5 |
מגבלות נוספות
כשעובדים עם Drive API, נאכפות המגבלות הבאות:
משתמשי Google Workspace יכולים להעלות רק 750GB ביום בין 'האחסון שלי' לבין כל תיקיות האחסון השיתופי. המגבלה הזו חלה גם על עותקים.
משתמשים שמגיעים למגבלה של 750GB או מעלים קובץ שגודלו גדול מ-750GB לא יכולים להעלות או להעתיק קבצים נוספים עד שיחלפו 24 שעות.
הגודל המקסימלי של קובץ שמשתמשים יכולים להעלות הוא 5TB. רק הקובץ הראשון שחורג מהמגבלה הזו יושלם. הגודל המקסימלי של הקובץ שמשתמשים יכולים להעתיק הוא 750GB.
התראות שנשלחות לכתובת שצוינה כשפותחים ערוץ התראות לא נספרות במכסת המגבלות. עם זאת, קריאות ל-methods
changes.watch,channels.stopו-files.watchנספרות במכסה.אם לא חורגים מהמכסות לדקה, אין מגבלה על מספר הבקשות שאפשר לשלוח ביום.
בהתאם לסוג החשבון שלכם ב-Google Workspace, יש מגבלות נוספות על נפח האחסון ב-Drive.
פתרון שגיאות שקשורות למכסת זמן
לגבי כל השגיאות שמבוססות על זמן (מקסימום N בקשות לכל X דקות), מומלץ שהקוד יזהה את החריג וישתמש בהשהיה מעריכית קטומה לפני ניסיון חוזר כדי לוודא שהמכשירים לא יוצרים עומס מוגזם.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff) היא אסטרטגיה סטנדרטית לטיפול בשגיאות באפליקציות רשת. אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באמצעות הגדלה אקספוננציאלית של זמני ההמתנה בין הבקשות, עד למשך ההשהיה המקסימלי. אם הבקשות עדיין לא מצליחות, חשוב שההשהיות בין הבקשות יגדלו עם הזמן עד שהבקשה תצליח.
אלגוריתם לדוגמה
אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באופן אקספוננציאלי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים עד למשך ההשהיה המקסימלי. לדוגמה:
- שליחת בקשה ל-Google Drive API.
- אם הבקשה נכשלת, צריך להמתין 1 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 2 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 4 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - וכך הלאה, עד
maximum_backoffפעמים. - ממשיכים להמתין ולנסות שוב עד שמגיעים למספר מקסימלי של ניסיונות חוזרים, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.
where:
- זמן ההמתנה הוא
min(((2^n)+random_number_milliseconds), maximum_backoff), שבוnגדל ב-1 בכל איטרציה (בקשה). -
random_number_millisecondsהוא מספר אקראי של אלפיות השנייה שקטן מ-1,000 או שווה לו. כך נמנעים ממקרים שבהם הרבה לקוחות מסונכרנים בגלל מצב מסוים וכולם מנסים שוב בו-זמנית, ושולחים בקשות בגל מסונכרן. הערך שלrandom_number_millisecondsמחושב מחדש אחרי כל בקשה לניסיון חוזר. - הערך של
maximum_backoffהוא בדרך כלל 32 או 64 שניות. הערך המתאים תלוי בתרחיש לדוגמה.
הלקוח יכול להמשיך לנסות שוב אחרי שהגיע לזמן maximum_backoff.
ניסיונות חוזרים אחרי השלב הזה לא צריכים להמשיך להגדיל את זמן ההשהיה. לדוגמה, אם לקוח משתמש בזמן maximum_backoff של 64 שניות, אחרי שהוא מגיע לערך הזה הוא יכול לנסות שוב כל 64 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלת זמן.
זמן ההמתנה בין ניסיונות חוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.
תמחור
כל השימוש הרגיל ב-Google Drive API זמין ללא עלות נוספת. אנחנו מתכננים לגבות תשלום על חריגה ממגבלות הבקשות של המכסה בחשבון לחיוב ב-Google Cloud בהמשך שנת 2026. מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace עבור כלי סוכנים וממשקי API.
איך מבקשים להגדיל את המכסות
יכול להיות שתרצו לבקש שינוי במכסות בהתאם לשימוש במשאבים בפרויקט. קריאות ל-API על ידי חשבון שירות נחשבות לשימוש בחשבון יחיד. הגשת בקשה להתאמת המכסה לא מבטיחה שהבקשה תאושר. יכול להיות שיחלפו כמה ימים עד שנאשר בקשות להתאמת מכסה שיובילו לעלייה משמעותית בערך המכסה.
המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם אתם צופים עלייה משמעותית בשימוש בקרוב, תוכלו לבקש התאמות של המכסות מראש בדף Quotas & System Limits (מכסות ומגבלות מערכת) במסוף Google Cloud.
מידע נוסף זמין במקורות המידע הבאים: