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

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

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

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

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

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

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

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

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

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

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

نام فیلدها

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

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

نمایه‌ها

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

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

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

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

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

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

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

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

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

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

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

Cloud Firestore کیت‌های توسعه نرم‌افزار و کتابخانه‌های کارخواه به‌طور خودکار تراکنش‌های ناموفق را دوباره امتحان می‌کنند تا خطاهای موقت را برطرف کنند. اگر برنامه شما به‌جای کیت توسعه نرم‌افزار، مستقیماً ازطریق REST یا RPC API به 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 بیشتر بدانید.