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

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

محل پایگاه داده

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

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

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

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

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

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

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

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

نام فیلدها

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

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

شاخص‌ها

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

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

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

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

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

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

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

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

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

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

تکرار تراکنش‌ها

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

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

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

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

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

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

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

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

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

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

• اسناد جدید را با سرعت بسیار بالایی ایجاد می‌کند و شناسه‌های (ID) خود را که به طور یکنواخت افزایش می‌یابند، اختصاص می‌دهد.

  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 Firestore Security Rules از عملیات غیرمجاز روی پایگاه داده خود جلوگیری کنید. به عنوان مثال، استفاده از قوانین می‌تواند از سناریویی که در آن یک کاربر مخرب بارها و بارها کل پایگاه داده شما را دانلود می‌کند، جلوگیری کند.

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