محدودیت های استفاده

از آنجایی که رابط برنامه‌نویسی کاربردی گوگل والت (Google Vault API) یک سرویس اشتراکی است، ما سهمیه‌ها و محدودیت‌هایی را اعمال می‌کنیم تا مطمئن شویم که همه کاربران به طور منصفانه از آن استفاده می‌کنند و از سلامت کلی سیستم Google Workspace محافظت کنیم.

محدودیت‌های محصول

شما نمی‌توانید بیش از ۲۰ صادرات در حال انجام در سراسر سازمان خود داشته باشید.

سهمیه درخواست API

هر سازمان مجاز به خواندن ۶۰۰ مطلب در دقیقه، در تمام پروژه‌ها و کاربران، از جمله درخواست‌ها از طریق Vault API و vault.google.com است.

جداول زیر محدودیت‌های درخواست در هر دقیقه برای هر پروژه را فهرست می‌کنند:

درخواست‌های خواندن در هر دقیقه برای هر پروژه
صادر کردن، موضوع‌بندی و پرس‌وجوی ذخیره‌شده ۱۲۰
نگه دارید ۲۲۸
عملیات طولانی مدت ۳۰۰
درخواست‌ها را در هر دقیقه برای هر پروژه بنویسید
صادرات ۲۰
نگه دارید ۶۰
مجوزهای مهم ۳۰
ماده ۶۰
پرس و جوی ذخیره شده ۴۵
جستجو (تعداد) درخواست در هر دقیقه برای هر پروژه
تعداد جستجوها ۲۰

استفاده از سهمیه بر اساس روش

سهمیه‌ای که توسط یک درخواست استفاده می‌شود به متد فراخوانی شده بستگی دارد. جدول زیر میزان استفاده از سهمیه به ازای هر متد را فهرست می‌کند:

روش هزینه‌های سهمیه‌بندی
matters.close
matters.create
matters.delete
matters.reopen
matters.update
matters.undelete		 ۱ مطلب خوانده شده
۱ مورد بنویسید
matters.count ۱ عدد
matters.get ۱ مطلب خوانده شده
matters.list ۱۰ مطلب خوانده شده
matters.addPermissions
matters.removePermissions		 ۱ مطلب خوانده شده
۱ مورد بنویسید
۱- مجوز نوشتن مهم است
matters.exports.create ۱ خروجی خواندنی
۱۰ نوشتن خروجی
matters.exports.delete ۱ خروجی نوشتن
matters.exports.get ۱ خروجی خواندنی
matters.exports.list ۵ خوانش خروجی
matters.holds.addHeldAccounts
matters.holds.create
matters.holds.delete
matters.holds.removeHeldAccounts
matters.holds.update		 ۱ مطلب خوانده شده
۱ مورد بنویسید
۱. نگه داشتن دکمه‌ی خواندن
۱ نگه داشتن نوشتن
matters.holds.list ۱ مطلب خوانده شده
۳ عدد نگه داشتن قرائت
matters.holds.accounts.create
matters.holds.accounts.delete
matters.holds.accounts.list		 ۱ مطلب خوانده شده
۱ مورد بنویسید
۱. نگه داشتن دکمه‌ی خواندن
۱ نگه داشتن نوشتن
matters.savedQueries.create
matters.savedQueries.delete		 ۱ مطلب خوانده شده
۱ مورد بنویسید
۱ پرس‌وجوی ذخیره‌شده خوانده شد
۱ نوشتن پرس‌وجوی ذخیره‌شده
matters.savedQueries.get ۱ مطلب خوانده شده
۱ پرس‌وجوی ذخیره‌شده خوانده شد
matters.savedQueries.list ۱ مطلب خوانده شده
۳ بار خواندن کوئری ذخیره شده
operations.get ۱ عملیات طولانی مدت خوانده شده

خطاهای سهمیه‌بندی مبتنی بر زمان را برطرف کنید

اگر از سهمیه تعیین‌شده در هر دقیقه یا هر سازمان تجاوز کنید، معمولاً با کد وضعیت HTTP 429: Too many requests مواجه می‌شوید.

برای همه خطاهای مبتنی بر زمان (حداکثر N درخواست در هر X دقیقه)، توصیه می‌کنیم کد شما استثنا را دریافت کند و از یک backoff نمایی کوتاه شده استفاده کند تا مطمئن شود دستگاه‌های شما بار اضافی تولید نمی‌کنند.

بازگشت نمایی یک استراتژی استاندارد مدیریت خطا برای برنامه‌های شبکه است. یک الگوریتم بازگشت نمایی، درخواست‌ها را با استفاده از زمان انتظار بین درخواست‌ها که به صورت نمایی افزایش می‌یابد، تا حداکثر زمان بازگشت، دوباره امتحان می‌کند. اگر درخواست‌ها همچنان ناموفق باشند، مهم است که تأخیر بین درخواست‌ها به مرور زمان افزایش یابد تا درخواست موفقیت‌آمیز شود.

الگوریتم مثال

یک الگوریتم بازگشت نمایی، درخواست‌ها را به صورت نمایی دوباره امتحان می‌کند و زمان انتظار بین تلاش‌های مجدد را تا حداکثر زمان بازگشت افزایش می‌دهد. برای مثال:

  1. درخواستی به API گوگل والت ارسال کنید.
  2. اگر درخواست با شکست مواجه شد، ۱ + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
  3. اگر درخواست با شکست مواجه شد، به مدت ۲ + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
  4. اگر درخواست با شکست مواجه شد، به مدت ۴ + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
  5. و به همین ترتیب، تا زمان maximum_backoff .
  6. تا حداکثر تعداد دفعات تلاش مجدد، به انتظار و تلاش مجدد ادامه دهید، اما مدت زمان انتظار بین تلاش‌ها را افزایش ندهید.

کجا:

  • زمان انتظار min(((2^n)+random_number_milliseconds), maximum_backoff) است، که در آن n برای هر تکرار (درخواست) 1 واحد افزایش می‌یابد.
  • random_number_milliseconds یک عدد تصادفی میلی‌ثانیه کمتر یا مساوی ۱۰۰۰ است. این به جلوگیری از مواردی که بسیاری از کلاینت‌ها به دلیل برخی شرایط همگام‌سازی می‌شوند و همه به طور همزمان تلاش مجدد می‌کنند و درخواست‌ها را در امواج هماهنگ ارسال می‌کنند، کمک می‌کند. مقدار random_number_milliseconds پس از هر درخواست تلاش مجدد دوباره محاسبه می‌شود.
  • maximum_backoff معمولاً ۳۲ یا ۶۴ ثانیه است. مقدار مناسب به مورد استفاده بستگی دارد.

کلاینت می‌تواند پس از رسیدن به زمان maximum_backoff به تلاش مجدد ادامه دهد. تلاش‌های مجدد پس از این نقطه نیازی به افزایش مداوم زمان backoff ندارند. برای مثال، اگر یک کلاینت از زمان maximum_backoff برابر با ۶۴ ثانیه استفاده کند، پس از رسیدن به این مقدار، کلاینت می‌تواند هر ۶۴ ثانیه دوباره تلاش کند. در مقطعی، کلاینت‌ها باید از تلاش مجدد نامحدود منع شوند.

زمان انتظار بین تلاش‌های مجدد و تعداد تلاش‌های مجدد به مورد استفاده شما و شرایط شبکه بستگی دارد.

درخواست افزایش سهمیه

بسته به میزان استفاده از منابع پروژه‌تان، ممکن است بخواهید درخواست تنظیم سهمیه بدهید. فراخوانی‌های API توسط یک حساب کاربری سرویس، به عنوان استفاده از یک حساب کاربری واحد در نظر گرفته می‌شوند. درخواست برای سهمیه تنظیم‌شده، تضمینی برای تأیید نیست. درخواست‌های تنظیم سهمیه که مقدار سهمیه را به میزان قابل توجهی افزایش می‌دهند، ممکن است مدت زمان بیشتری طول بکشد تا تأیید شوند.

همه پروژه‌ها سهمیه‌های یکسانی ندارند. با گذشت زمان و افزایش استفاده از گوگل کلود، ممکن است لازم باشد مقادیر سهمیه شما افزایش یابد. اگر انتظار افزایش قابل توجه استفاده در آینده را دارید، می‌توانید به صورت پیشگیرانه از صفحه سهمیه‌ها و محدودیت‌های سیستم در کنسول گوگل کلود، درخواست تنظیم سهمیه کنید .

برای مطالعه بیشتر، به منابع زیر مراجعه کنید:

قیمت‌گذاری

تمام موارد استفاده از Google Vault API بدون هیچ هزینه اضافی برای مشتریان Google Workspace در دسترس است.