מגבלות שימוש

ממשק Google Vault API הוא שירות משותף, ולכן אנחנו מגבילים את השימוש בו כדי לוודא שכל המשתמשים יוכלו להשתמש בו בצורה הוגנת, וכדי להגן על המערכת הכוללת של Google Workspace.

הגבלות על מוצרים

בארגון יכולים להיות עד 20 ייצואים בתהליך.

מכסות לבקשות API

כל ארגון יכול לבצע 600 קריאות של עניינים בדקה, בכל הפרויקטים והמשתמשים, כולל בקשות דרך Vault API ו-vault.google.com.

בטבלאות הבאות מפורטות מכסות הבקשות לדקה לכל פרויקט:

בקשות קריאה לדקה לכל פרויקט
ייצוא, עניין ושאילתה שמורה	120
השהיה	228
פעולה ממושכת	300

בקשות כתיבה לדקה לכל פרויקט
ייצוא	20
השהיה	60
הרשאות בתיק משפטי	30
תקן Matter	60
שאילתה שמורה	45

בקשות חיפוש (ספירה) לדקה לכל פרויקט
מספר החיפושים	20

ניצול המכסה לפי שיטה

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

שיטה	עלויות של מכסות
matters.close matters.create matters.delete matters.reopen matters.update matters.undelete	קריאה של עניין אחד כתיבה של עניין אחד
matters.count	יחידה אחת
matters.get	עניין אחד נקרא
matters.list	‫10 קריאות של עניינים
matters.addPermissions matters.removePermissions	1 matter read 1 matter write 1 matter permissions write
matters.exports.create	בוצעה קריאה של ייצוא אחד בוצעו 10 כתיבות של ייצוא
matters.exports.delete	פעולת כתיבה אחת של ייצוא
matters.exports.get	פעולת ייצוא אחת נקראה
matters.exports.list	‫5 קריאות של ייצוא
matters.holds.addHeldAccounts matters.holds.create matters.holds.delete matters.holds.removeHeldAccounts matters.holds.update	‫1 קריאה של עניין ‫1 כתיבה של עניין ‫1 קריאה של החזקה לצורך משפטי ‫1 כתיבה של החזקה לצורך משפטי
matters.holds.list	עניין אחד נקרא 3 קריאות של החזקה
matters.holds.accounts.create matters.holds.accounts.delete matters.holds.accounts.list	‫1 קריאה של עניין ‫1 כתיבה של עניין ‫1 קריאה של החזקה לצורך משפטי ‫1 כתיבה של החזקה לצורך משפטי
matters.savedQueries.create matters.savedQueries.delete	1 matter read 1 matter write 1 saved query read 1 saved query write
matters.savedQueries.get	עניין אחד נקרא שאילתה שמורה אחת נקראה
matters.savedQueries.list	עניין אחד נקרא 3 קריאות של שאילתות שמורות
operations.get	קריאה אחת של פעולה ממושכת

פתרון שגיאות שקשורות למכסת זמן

אם תחרגו ממכסה לדקה או ממכסה לארגון, בדרך כלל תקבלו תגובה עם קוד סטטוס 429: Too many requests‏ HTTP.

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

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

אלגוריתם לדוגמה

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

1. שליחת בקשה ל-Google Vault API.
2. אם הבקשה נכשלת, צריך להמתין ‎1 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
3. אם הבקשה נכשלת, צריך להמתין ‎2 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
4. אם הבקשה נכשלת, צריך להמתין ‎4 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
5. וכך הלאה, עד maximum_backoff פעמים.
6. ממשיכים להמתין ולנסות שוב עד שמגיעים למספר מקסימלי של ניסיונות חוזרים, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.

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

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

איך מבקשים להגדיל את המכסות

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

המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם אתם צופים עלייה משמעותית בשימוש בקרוב, תוכלו לבקש התאמות של המכסות מראש בדף Quotas & System Limits (מכסות ומגבלות מערכת) במסוף Google Cloud.

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

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

תמחור

כל השימוש ב-Vault API של Google זמין ללקוחות Google Workspace ללא עלות נוספת.