ממשק 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) מבצע ניסיון חוזר של בקשות באופן אקספוננציאלי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים עד למשך ההשהיה המקסימלי. לדוגמה:
- שליחת בקשה ל-Google Vault 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 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלת זמן.
זמן ההמתנה בין ניסיונות חוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.
בקשה להגדלת מכסה
יכול להיות שתרצו לבקש התאמה של המכסות בהתאם לשימוש במשאבים בפרויקט. קריאות ל-API על ידי חשבון שירות נחשבות לשימוש בחשבון יחיד. הגשת בקשה למכסה מותאמת לא מבטיחה אישור. יכול להיות שיעבור יותר זמן עד שנאשר בקשות להתאמת מכסות שיובילו להגדלה משמעותית של ערך המכסה.
המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם אתם צופים עלייה משמעותית בשימוש בקרוב, תוכלו לבקש התאמות במכסות מראש בדף Quotas במסוף Google Cloud.
מידע נוסף זמין במשאבים הבאים:
תמחור
כל השימוש בממשק ה-API של Google Vault זמין ללקוחות Google Workspace ללא עלות נוספת.