هنگام ساختن برنامه ای که از Cloud Firestore استفاده می کند، از بهترین شیوه های فهرست شده در اینجا به عنوان یک مرجع سریع استفاده کنید.
هنگامی که نمونه پایگاه داده خود را ایجاد می کنید، نزدیک ترین مکان پایگاه داده به کاربران خود را انتخاب کنید و منابع را محاسبه کنید. پرش های گسترده شبکه بیشتر مستعد خطا هستند و تاخیر پرس و جو را افزایش می دهند.
برای به حداکثر رساندن در دسترس بودن و دوام برنامه خود، یک مکان چند منطقه ای را انتخاب کنید و منابع محاسباتی مهم را حداقل در دو منطقه قرار دهید.
یک مکان منطقه‌ای را برای هزینه‌های کمتر، برای تأخیر نوشتن کمتر، اگر برنامه شما به تأخیر حساس است، یا برای هم‌مکانی با سایر منابع GCP انتخاب کنید.
- از شناسه های اسناد خودداری کنید
.و.. - از استفاده از اسلش
/رو به جلو در شناسه اسناد خودداری کنید. از شناسه‌های سند با افزایش یکنواخت مانند:
-
Customer1,Customer2,Customer3, ... -
Product 1,Product 2,Product 3, ...
چنین شناسه‌های متوالی می‌توانند به کانون‌هایی منجر شوند که بر تأخیر تأثیر می‌گذارند.
-
از کاراکترهای زیر در نام فیلدها اجتناب کنید زیرا به فرار اضافی نیاز دارند:
-
.دوره -
[براکت چپ -
]براکت سمت راست -
*ستاره -
`تیک
-
عامل اصلی تأخیر نوشتن ایندکس fanout است. بهترین روش ها برای کاهش fanout شاخص عبارتند از:
معافیت های شاخص سطح مجموعه را تنظیم کنید. یک پیش فرض آسان غیرفعال کردن نمایه سازی Descending & Array است. حذف مقادیر نمایه‌سازی نشده نیز هزینه‌های ذخیره‌سازی را کاهش می‌دهد.
تعداد اسناد در یک معامله را کاهش دهید. برای نوشتن تعداد زیادی سند، به جای نوشتن دسته ای اتمی، از یک رایتر انبوه استفاده کنید.
برای اکثر برنامه‌ها، می‌توانید برای مدیریت فهرست‌های خود به فهرست‌سازی خودکار و همچنین پیوندهای پیام خطا تکیه کنید. با این حال، ممکن است بخواهید در موارد زیر معافیت های تک فیلدی را اضافه کنید:
| مورد | توضیحات |
|---|---|
| فیلدهای رشته ای بزرگ | اگر یک فیلد رشته‌ای دارید که اغلب مقادیر رشته‌ای طولانی را در خود دارد که برای پرس‌وجو از آن استفاده نمی‌کنید، می‌توانید با معاف کردن فیلد از فهرست‌سازی، هزینه‌های ذخیره‌سازی را کاهش دهید. |
| نرخ بالای نوشتن در مجموعه ای حاوی اسناد با مقادیر متوالی | اگر فیلدی را نمایه کنید که به صورت متوالی بین اسناد یک مجموعه افزایش یا کاهش می‌یابد، مانند مهر زمانی، حداکثر سرعت نوشتن در مجموعه 500 نوشتن در ثانیه است. اگر بر اساس فیلد با مقادیر ترتیبی پرس و جو نمی کنید، می توانید برای دور زدن این محدودیت، فیلد را از نمایه سازی معاف کنید. به عنوان مثال، در یک مورد استفاده از اینترنت اشیا با نرخ نوشتن بالا، مجموعه‌ای حاوی اسناد با یک فیلد مهر زمانی ممکن است به محدودیت 500 نوشتن در ثانیه نزدیک شود. |
| فیلدهای TTL | اگر از خط‌مشی‌های TTL (زمان تا زندگی) استفاده می‌کنید، توجه داشته باشید که فیلد TTL باید مهر زمانی باشد. نمایه سازی در فیلدهای TTL به طور پیش فرض فعال است و می تواند بر عملکرد در نرخ ترافیک بالاتر تأثیر بگذارد. به عنوان بهترین روش، معافیت های تک فیلدی را برای فیلدهای TTL خود اضافه کنید. |
| آرایه های بزرگ یا فیلدهای نقشه | آرایه های بزرگ یا فیلدهای نقشه می توانند به محدودیت 40000 ورودی فهرست در هر سند نزدیک شوند. اگر بر اساس یک آرایه بزرگ یا فیلد نقشه پرس و جو نمی کنید، باید آن را از نمایه سازی معاف کنید. |
حداکثر نرخ دقیقی که یک برنامه می تواند یک سند واحد را به روز کند تا حد زیادی به حجم کاری بستگی دارد. برای اطلاعات بیشتر، به‌روزرسانی‌های یک سند را ببینید.
به جای تماس های همزمان، در صورت وجود از تماس های ناهمزمان استفاده کنید. تماس های ناهمزمان تأثیر تأخیر را به حداقل می رساند. به عنوان مثال، برنامه ای را در نظر بگیرید که قبل از ارائه پاسخ به نتیجه جستجوی سند و نتایج یک پرس و جو نیاز دارد. اگر جستجو و پرس و جو وابستگی داده ای ندارند، نیازی به صبر همزمان تا تکمیل جستجو قبل از شروع پرس و جو نیست.
از افست استفاده نکنید. در عوض، از نشانگر استفاده کنید. استفاده از افست تنها از بازگرداندن اسناد نادیده گرفته شده به برنامه شما جلوگیری می کند، اما این اسناد همچنان به صورت داخلی بازیابی می شوند. اسناد نادیده گرفته شده بر تأخیر پرس و جو تأثیر می گذارد و درخواست شما برای عملیات خواندن مورد نیاز برای بازیابی آنها صورتحساب دریافت می کند.
SDKهای Cloud Firestore و کتابخانه های سرویس گیرنده به طور خودکار تراکنش های ناموفق را برای مقابله با خطاهای گذرا دوباره امتحان می کنند. اگر برنامه شما مستقیماً به جای SDK از طریق REST یا RPC API به 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 ممکن است تا پایان عمر پروژه شما حفظ شود.
- به عنوان بهترین روش مطابقت با داده ها، توصیه می کنیم اطلاعات حساس را در نام اسناد و نام فیلدهای سند ذخیره نکنید.
با Cloud Firestore Security Rules از عملیات غیرمجاز در پایگاه داده خود جلوگیری کنید. برای مثال، استفاده از قوانین می‌تواند از سناریویی جلوگیری کند که در آن کاربر مخرب به طور مکرر کل پایگاه داده شما را دانلود می‌کند.
درباره استفاده از Cloud Firestore Security Rules بیشتر بیاموزید.