روال‌های مطلوب برای Cloud Firestore

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

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

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

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

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

شناسه‌های سند

• از شناسه‌های سند . و .. استفاده نکنید.
• از استفاده از / خط مورب در شناسه‌های سند خودداری کنید.

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

  • Customer1، Customer2، Customer3، …
  • Product 1، Product 2، Product 3، …

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

نام‌های فیلد

• از نویسه‌های زیر در نام فیلدها استفاده نکنید زیرا به گریز اضافی نیاز دارند:

  • دوره .
  • [ کروشه چپ
  • ] کروشه راست
  • * ستاره
  • ` بک‌تیک

شاخص‌ها

کاهش تأخیر نوشتن

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

• معافیت‌های نمایه سطح مجموعه را تنظیم کنید. یک پیش‌فرض آسان، غیرفعال کردن نمایه‌سازی نزولی و آرایه‌ای است. برداشتن مقادیر نمایه‌شده استفاده‌نشده هزینه‌های فضای ذخیره‌سازی را نیز کاهش می‌دهد.

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

معافیت‌های نمایه

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

جلد محافظ	شرح
فیلدهای رشته‌ای بزرگ	اگر فیلد رشته‌ای دارید که اغلب مقادیر رشته‌ای طولانی دارد که از آن‌ها برای پُرسمان استفاده نمی‌کنید، می‌توانید با معاف کردن فیلد از نمایه‌سازی، هزینه‌های فضای ذخیره‌سازی را کاهش دهید.
نرخ‌های نوشتن بالا در مجموعه‌ای که حاوی اسناد با مقادیر متوالی است	اگر فیلدی را نمایه کنید که به‌طور متوالی بین اسناد در یک مجموعه افزایش یا کاهش می‌یابد، مانند مُهر زمان، حداکثر نرخ نوشتن در مجموعه ۵۰۰ نوشتن در ثانیه است. اگر براساس فیلد دارای مقادیر متوالی پُرسمان نمی‌کنید، می‌توانید فیلد را از نمایه‌سازی معاف کنید تا این محدودیت را دور بزنید. برای مثال، در مورد کاربرد «اینترنت اشیاء» با نرخ نوشتن بالا، مجموعه‌ای که حاوی اسناد با فیلد مُهر زمان است ممکن است به حد ۵۰۰ نوشتن در ثانیه نزدیک شود.
فیلدهای TTL	اگر از خط‌مشی‌های TTL (زمان بقا) استفاده می‌کنید، توجه داشته باشید که فیلد TTL باید مُهر زمان باشد. نمایه‌سازی در فیلدهای TTL به‌طور پیش‌فرض فعال است و می‌تواند بر عملکرد در نرخ‌های ترافیک بالاتر تأثیر بگذارد. به‌عنوان روال مطلوب، معافیت‌های نمایه‌سازی خودکار را برای فیلدهای TTL خود اضافه کنید.
آرایه بزرگ یا فیلدهای نقشه	فیلدهای آرایه یا نقشه بزرگ می‌توانند به حد مجاز ۴۰٬۰۰۰ ورودی نمایه برای هر سند نزدیک شوند. اگر براساس آرایه بزرگ یا فیلد نقشه پُرسمان نمی‌کنید، باید آن را از نمایه‌سازی معاف کنید.

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

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

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

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

تلاش‌های مجدد تراکنش‌ها

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

به‌روزرسانی‌های هم‌زمان

برای روال‌های مطلوب مربوط به به‌روزرسانی‌های هم‌زمان، به درک پُرسمان‌های هم‌زمان در مقیاس مراجعه کنید.

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

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

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

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

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

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

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

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

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

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

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

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

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

از نادیده گرفتن داده‌های حذف‌شده اجتناب کنید

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

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

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 زمان کافی برای آماده‌سازی اسناد برای ترافیک افزایش‌یافته داشته باشد. توصیه می‌کنیم با حداکثر ۵۰۰ عملیات در ثانیه برای مجموعه جدید شروع کنید و سپس ترافیک را هر ۵ دقیقه ۵۰٪ افزایش دهید. به‌طور مشابه می‌توانید ترافیک نوشتن را افزایش دهید، اما Cloud Firestoreمحدودیت‌های استاندارد را درنظر داشته باشید. مطمئن شوید که عملیات‌ها به‌طور نسبتاً یکنواخت در سراسر محدوده کلید توزیع شده‌اند. به این قانون «۵۰۰/۵۰/۵» می‌گویند.

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

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

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

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

خوانش‌های موازی

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

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

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

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

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

حریم خصوصی

• از ذخیره کردن اطلاعات حساس در «شناسه پروژه Cloud» خودداری کنید. «شناسه پروژه Cloud» ممکن است پس‌از پایان عمر پروژه شما حفظ شود.
• به‌عنوان روال مطلوب رعایت مقررات داده، توصیه می‌کنیم اطلاعات حساس را در نام سند و نام فیلد سند ذخیره نکنید.

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

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

درباره استفاده از Cloud Firestore Security Rules بیشتر بدانید.