بهترین روش ها برای Cloud Firestore

هنگام ساختن برنامه ای که از Cloud Firestore استفاده می کند، از بهترین شیوه های فهرست شده در اینجا به عنوان یک مرجع سریع استفاده کنید.

مکان پایگاه داده

هنگامی که نمونه پایگاه داده خود را ایجاد می کنید، نزدیک ترین مکان پایگاه داده به کاربران خود را انتخاب کنید و منابع را محاسبه کنید. پرش های گسترده شبکه بیشتر مستعد خطا هستند و تاخیر پرس و جو را افزایش می دهند.

برای به حداکثر رساندن در دسترس بودن و دوام برنامه خود، یک مکان چند منطقه ای را انتخاب کنید و منابع محاسباتی مهم را حداقل در دو منطقه قرار دهید.

یک مکان منطقه‌ای را برای هزینه‌های کمتر، برای تأخیر نوشتن کمتر، اگر برنامه شما به تأخیر حساس است، یا برای هم‌مکانی با سایر منابع GCP انتخاب کنید.

شناسه های مدارک

• از شناسه های اسناد خودداری کنید . و ..
• از استفاده از اسلش / رو به جلو در شناسه اسناد خودداری کنید.

• از شناسه‌های سند با افزایش یکنواخت مانند:

  • Customer1 , Customer2 , Customer3 , ...
  • Product 1 , Product 2 , Product 3 , ...

  چنین شناسه‌های متوالی می‌توانند به کانون‌هایی منجر شوند که بر تأخیر تأثیر می‌گذارند.

نام فیلدها

• از کاراکترهای زیر در نام فیلدها اجتناب کنید زیرا به فرار اضافی نیاز دارند:

  • . دوره زمانی
  • [ براکت چپ
  • ] براکت سمت راست
  • * ستاره
  • ` تیک

شاخص ها

• از استفاده از شاخص های زیاد خودداری کنید. تعداد بیش از حد ایندکس ها می تواند تأخیر نوشتن را افزایش دهد و هزینه های ذخیره سازی برای ورودی های فهرست را افزایش دهد.

• توجه داشته باشید که نمایه سازی فیلدهایی با مقادیر یکنواخت در حال افزایش، مانند مهرهای زمانی، می تواند منجر به ایجاد نقاط مهمی شود که بر تأخیر برنامه هایی با نرخ خواندن و نوشتن بالا تأثیر می گذارد.

معافیت های شاخص

برای اکثر برنامه‌ها، می‌توانید برای مدیریت فهرست‌های خود به فهرست‌سازی خودکار و همچنین پیوندهای پیام خطا تکیه کنید. با این حال، ممکن است بخواهید در موارد زیر معافیت های تک فیلدی را اضافه کنید:

مورد	شرح
فیلدهای رشته ای بزرگ	اگر یک فیلد رشته‌ای دارید که اغلب مقادیر رشته‌ای طولانی را در خود دارد که برای پرس‌وجو از آن استفاده نمی‌کنید، می‌توانید با معاف کردن فیلد از فهرست‌سازی، هزینه‌های ذخیره‌سازی را کاهش دهید.
نرخ بالای نوشتن در مجموعه ای حاوی اسناد با مقادیر متوالی	اگر فیلدی را نمایه کنید که به صورت متوالی بین اسناد یک مجموعه افزایش یا کاهش می‌یابد، مانند مهر زمانی، حداکثر سرعت نوشتن در مجموعه 500 نوشتن در ثانیه است. اگر بر اساس فیلد با مقادیر ترتیبی پرس و جو نمی کنید، می توانید برای دور زدن این محدودیت، فیلد را از نمایه سازی معاف کنید. به عنوان مثال، در یک مورد استفاده از اینترنت اشیا با نرخ نوشتن بالا، مجموعه‌ای حاوی اسناد با یک فیلد مهر زمانی ممکن است به محدودیت 500 نوشتن در ثانیه نزدیک شود.
فیلدهای TTL	اگر از خط‌مشی‌های TTL (زمان تا زندگی) استفاده می‌کنید، توجه داشته باشید که فیلد TTL باید مهر زمانی باشد. نمایه سازی در فیلدهای TTL به طور پیش فرض فعال است و می تواند بر عملکرد در نرخ ترافیک بالاتر تأثیر بگذارد. به عنوان بهترین روش، معافیت های تک فیلدی را برای فیلدهای TTL خود اضافه کنید.
آرایه های بزرگ یا فیلدهای نقشه	آرایه های بزرگ یا فیلدهای نقشه می توانند به محدودیت 40000 ورودی فهرست در هر سند نزدیک شوند. اگر بر اساس یک آرایه بزرگ یا فیلد نقشه پرس و جو نمی کنید، باید آن را از نمایه سازی معاف کنید.

خواندن و نوشتن عملیات

• حداکثر نرخ دقیقی که یک برنامه می تواند یک سند واحد را به روز کند تا حد زیادی به حجم کاری بستگی دارد. برای اطلاعات بیشتر، به‌روزرسانی‌های یک سند را ببینید.

• به جای تماس های همزمان، در صورت وجود از تماس های ناهمزمان استفاده کنید. تماس های ناهمزمان تأثیر تأخیر را به حداقل می رساند. به عنوان مثال، برنامه ای را در نظر بگیرید که قبل از ارائه پاسخ به نتیجه جستجوی سند و نتایج یک پرس و جو نیاز دارد. اگر جستجو و پرس و جو وابستگی داده ای ندارند، نیازی به صبر همزمان تا تکمیل جستجو قبل از شروع پرس و جو نیست.

• از افست استفاده نکنید. در عوض، از نشانگر استفاده کنید. استفاده از افست تنها از بازگرداندن اسناد نادیده گرفته شده به برنامه شما جلوگیری می کند، اما این اسناد همچنان به صورت داخلی بازیابی می شوند. اسناد نادیده گرفته شده بر تأخیر پرس و جو تأثیر می گذارد و درخواست شما برای عملیات خواندن مورد نیاز برای بازیابی آنها صورتحساب دریافت می کند.

معاملات مجدد

SDKهای Cloud Firestore و کتابخانه های سرویس گیرنده به طور خودکار تراکنش های ناموفق را برای مقابله با خطاهای گذرا دوباره امتحان می کنند. اگر برنامه شما مستقیماً به جای SDK از طریق REST یا RPC API به Cloud Firestore دسترسی پیدا می کند، برنامه شما باید برای افزایش قابلیت اطمینان تراکنش های مجدد را اجرا کند.

به روز رسانی بیدرنگ

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

توصیه	جزئیات
نرخ ریزش شنونده عکس فوری را کاهش دهید	از تحریک مکرر شنوندگان خودداری کنید، به خصوص زمانی که پایگاه داده شما تحت بار نوشتن قابل توجهی است در حالت ایده آل، برنامه شما باید بلافاصله پس از باز کردن اتصال به Cloud Firestore، تمام شنوندگان عکس فوری مورد نیاز را راه اندازی کند. پس از تنظیم شنونده های اولیه عکس فوری، باید از افزودن یا حذف سریع شنوندگان عکس فوری در همان اتصال خودداری کنید. برای اطمینان از سازگاری داده‌ها، Cloud Firestore باید هر شنونده عکس فوری جدید را از داده‌های منبع خود پر کند و سپس تغییرات جدید را دنبال کند. بسته به نرخ نوشتن پایگاه داده شما، این می تواند یک عملیات گران قیمت باشد. اگر اغلب شنوندگان عکس فوری را به مراجع اضافه یا حذف کنید، شنوندگان عکس فوری شما می توانند تاخیر بیشتری را تجربه کنند. به طور کلی، شنونده ای که دائماً به آن متصل است، بهتر از اتصال و جدا کردن شنونده در آن مکان برای همان مقدار داده عمل می کند. برای بهترین عملکرد، شنوندگان عکس فوری باید طول عمر 30 ثانیه یا بیشتر داشته باشند. اگر در برنامه خود با مشکلات عملکرد شنونده مواجه شدید، سعی کنید شنیده ها و گوش نکردن های برنامه خود را ردیابی کنید تا مشخص کنید که آیا ممکن است به دفعات زیاد اتفاق بیفتند یا خیر.
محدود کردن شنوندگان عکس فوری به ازای هر مشتری	100 تعداد شنوندگان عکس فوری به ازای هر مشتری را زیر 100 نگه دارید.
نرخ نوشتن مجموعه را محدود کنید	1000 عملیات در ثانیه نرخ عملیات نوشتن را برای یک مجموعه فردی زیر 1000 عملیات در ثانیه نگه دارید.
نرخ فشار مشتری فردی را محدود کنید	1 سند در ثانیه نرخ اسنادی را که پایگاه داده به یک کلاینت فردی ارسال می کند کمتر از 1 سند در ثانیه نگه دارید.
نرخ فشار مشتری جهانی را محدود کنید	1,000,000 سند در ثانیه نرخ اسنادی را که پایگاه داده به همه مشتریان ارسال می کند کمتر از 1,000,000 سند در ثانیه نگه دارید. این یک حد نرم است. Cloud Firestore شما را از گذر از این آستانه باز نمی‌دارد، اما به شدت بر عملکرد تأثیر می‌گذارد.
محدود کردن بار اسناد فردی	10 کیلو بایت بر ثانیه حداکثر اندازه سند بارگیری شده توسط یک مشتری منفرد را زیر 10 کیلوبایت در ثانیه نگه دارید.
حجم بار سند جهانی را محدود کنید	1 گیگابایت در ثانیه حداکثر اندازه سند دانلود شده در همه کلاینت ها را زیر 1 گیگابایت در ثانیه نگه دارید.
تعداد فیلدها در هر سند را محدود کنید	100 مدارک شما باید کمتر از 100 فیلد داشته باشد.
محدودیت های استاندارد Cloud Firestore را درک کنید	محدودیت های استاندارد برای Cloud Firestore را در نظر داشته باشید. به محدودیت 1 نوشتن در ثانیه برای اسناد و محدودیت 1,000,000 اتصال همزمان در هر پایگاه داده توجه ویژه ای داشته باشید. اینها محدودیت های نرمی هستند که Cloud Firestore شما را از فراتر رفتن آنها باز نمی دارد. با این حال، فراتر از این محدودیت‌ها، بسته به میزان کل خواندن و نوشتن شما، ممکن است بر عملکرد تأثیر بگذارد.

طراحی برای مقیاس

بهترین روش‌های زیر نحوه اجتناب از موقعیت‌هایی را که باعث ایجاد مسائل اختلافی می‌شوند، شرح می‌دهند.

به روز رسانی به یک سند

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

یک عملیات نوشتن سند، سند و هر فهرست مرتبط را به روز می کند، و Cloud Firestore به طور همزمان عملیات نوشتن را در حد نصابی از کپی ها اعمال می کند. با نرخ نوشتن به اندازه کافی بالا، پایگاه داده شروع به برخورد با اختلاف، تاخیر بیشتر یا خطاهای دیگر می کند.

نرخ بالای خواندن، نوشتن و حذف در یک محدوده سند باریک

از نرخ بالای خواندن یا نوشتن برای بستن اسناد واژگانی خودداری کنید، در غیر این صورت برنامه شما با خطاهای بحث مواجه خواهد شد. این مشکل به عنوان هات اسپات شناخته می شود و برنامه شما در صورت انجام هر یک از موارد زیر می تواند نقطه اتصال را تجربه کند:

• اسناد جدید را با سرعت بسیار بالا ایجاد می کند و شناسه های یکنواخت خود را که افزایش می یابد اختصاص می دهد.

  Cloud Firestore شناسه‌های سند را با استفاده از الگوریتم scatter اختصاص می‌دهد. اگر اسناد جدیدی را با استفاده از شناسه اسناد خودکار ایجاد می کنید، نباید با نقطه اتصال در نوشتن مواجه شوید.

• اسناد جدید را با نرخ بالا در مجموعه ای با اسناد کم ایجاد می کند.

• اسناد جدیدی را با یک فیلد یکنواخت در حال افزایش، مانند مهر زمانی، با نرخ بسیار بالا ایجاد می کند.

• اسناد موجود در مجموعه را با سرعت بالایی حذف می کند.

• بدون افزایش تدریجی ترافیک، با سرعت بسیار بالایی در پایگاه داده می نویسد.

از رد شدن از روی داده های حذف شده خودداری کنید

از پرس و جوهایی که از داده های اخیراً حذف شده عبور می کنند اجتناب کنید. اگر نتایج پرس و جو اولیه اخیراً حذف شده باشد، ممکن است مجبور شود تعداد زیادی از ورودی های فهرست را نادیده بگیرد.

نمونه‌ای از حجم کاری که ممکن است مجبور باشد از روی بسیاری از داده‌های حذف شده رد شود، نمونه‌ای است که سعی می‌کند قدیمی‌ترین موارد کاری در صف را پیدا کند. پرس و جو ممکن است به این صورت باشد:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

هر بار که این پرس و جو اجرا می شود، ورودی های فهرست را برای فیلد created در اسنادی که اخیراً حذف شده اند اسکن می کند. این باعث کاهش سرعت جستجوها می شود.

برای بهبود عملکرد، از روش start_at برای پیدا کردن بهترین مکان برای شروع استفاده کنید. مثلا:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

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

افزایش ترافیک

باید به تدریج ترافیک را به مجموعه های جدید افزایش دهید یا اسناد واژگانی را ببندید تا به Cloud Firestore زمان کافی برای آماده سازی اسناد برای افزایش ترافیک بدهید. توصیه می کنیم با حداکثر 500 عملیات در ثانیه شروع به یک مجموعه جدید کنید و سپس هر 5 دقیقه ترافیک را 50 درصد افزایش دهید. شما می توانید به طور مشابه ترافیک نوشتن خود را افزایش دهید، اما محدودیت های استاندارد Cloud Firestore را در نظر داشته باشید. مطمئن شوید که عملیات به طور نسبتاً مساوی در سراسر محدوده کلید توزیع شده است. این قانون "500/50/5" نامیده می شود.

انتقال ترافیک به مجموعه جدید

اگر ترافیک برنامه را از یک مجموعه به مجموعه دیگر منتقل کنید، افزایش تدریجی آن بسیار مهم است. یک راه ساده برای مدیریت این مهاجرت خواندن از مجموعه قدیمی است و اگر سند وجود ندارد، از مجموعه جدید بخوانید. با این حال، این می تواند باعث افزایش ناگهانی ترافیک برای بستن اسناد واژگانی در مجموعه جدید شود. Cloud Firestore ممکن است نتواند به طور مؤثر مجموعه جدید را برای افزایش ترافیک آماده کند، به خصوص زمانی که حاوی اسناد کمی باشد.

اگر شناسه اسناد بسیاری از اسناد را در یک مجموعه تغییر دهید، مشکل مشابهی ممکن است رخ دهد.

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

موازی می خواند

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

یک استراتژی ممکن برای افزایش تدریجی خواندن یا نوشتن در یک مجموعه جدید، استفاده از هش قطعی شناسه کاربر برای انتخاب درصد تصادفی از کاربرانی است که سعی در نوشتن اسناد جدید دارند. اطمینان حاصل کنید که نتیجه هش شناسه کاربر نه با عملکرد شما و نه با رفتار کاربر منحرف نمی شود.

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

یکی از اصلاحات این استراتژی مهاجرت دسته های کوچکی از کاربران در یک زمان است. فیلدی را به سند کاربر اضافه کنید که وضعیت مهاجرت آن کاربر را ردیابی می کند. دسته ای از کاربران را برای مهاجرت بر اساس هش شناسه کاربر انتخاب کنید. از یک کار دسته ای برای انتقال اسناد برای آن دسته از کاربران استفاده کنید و از خواندن موازی برای کاربران در میانه مهاجرت استفاده کنید.

توجه داشته باشید که نمی‌توانید به راحتی به عقب برگردید، مگر اینکه نوشتن دوگانه موجودیت‌های قدیمی و جدید را در مرحله مهاجرت انجام دهید. این باعث افزایش هزینه های Cloud Firestore می شود.

جلوگیری از دسترسی غیرمجاز

با قوانین امنیتی Cloud Firestore از عملیات غیرمجاز در پایگاه داده خود جلوگیری کنید. برای مثال، استفاده از قوانین می‌تواند از سناریویی جلوگیری کند که در آن کاربر مخرب به طور مکرر کل پایگاه داده شما را دانلود می‌کند.

درباره استفاده از قوانین امنیتی Cloud Firestore بیشتر بیاموزید.