מגבלות שימוש

ממשק 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 במסוף Google Cloud.

מידע נוסף זמין במשאבים הבאים:

תמחור

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