درک خواندن و نوشتن در مقیاس بزرگ

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

‫Cloud Firestore یک پایگاه داده انعطاف‌پذیر و مقیاس‌پذیر برای توسعه دستگاه همراه، وب، و سرور از Firebase و Google Cloud است. شروع کار با Cloud Firestore و نوشتن برنامه‌های غنی و قدرتمند بسیار آسان است.

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

پیش‌از طراحی معماری برنامه‌تان، بخش‌های زیر را برای روال‌های مطلوب ببینید.

آشنایی با مؤلفه‌های سطح بالا

نمودار زیر مؤلفه‌های سطح بالایی را نشان می‌دهد که در درخواست میانای برنامه‌سازی کاربردی Cloud Firestore دخیل هستند.

Cloud Firestore کیت توسعه نرم‌افزار و کتابخانه‌های کارخواه

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

Google Front End (GFE)

این سرویس زیرساختی برای همه سرویس‌های ابری Google مشترک است. GFE درخواست‌های ورودی را می‌پذیرد و آن‌ها را به سرویس Google مربوطه (سرویس Cloud Firestore در این زمینه) بازارسال می‌کند. این سرویس همچنین قابلیت‌های مهم دیگری ازجمله محافظت دربرابر حملات «منع سرویس» ارائه می‌دهد.

Cloud Firestore سرویس

سرویس Cloud Firestore بررسی‌هایی را روی درخواست API انجام می‌دهد که شامل اصالت‌سنجی، صدور مجوز، بررسی سهمیه، و قوانین امنیتی است و همچنین تراکنش‌ها را مدیریت می‌کند. این سرویس Cloud Firestore شامل یک کارخواه فضای ذخیره‌سازی است که با لایه فضای ذخیره‌سازی برای خواندن و نوشتن داده‌ها تعامل دارد.

‫Cloud Firestore لایه ذخیره‌سازی

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

محدوده‌ها و تقسیم‌های کلیدی

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

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

تکرار همگام

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

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

چیدمان داده‌ها

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

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

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

تک‌منطقه‌ای درمقابل چندمنطقه‌ای

وقتی پایگاه داده ایجاد می‌کنید، باید منطقه یا چندمنطقه انتخاب کنید.

مکان منطقه‌ای واحد یک مکان جغرافیایی خاص است، مثل us-west1. همان‌طور که قبلاً توضیح داده شد، بخش‌های داده پایگاه داده Cloud Firestore در مناطق مختلف در ناحیه انتخاب‌شده تکرار می‌شوند.

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

برای اطلاعات بیشتر درباره مکان‌های یک منطقه، به مکان‌های Cloud Firestore مراجعه کنید.

آشنایی با عمر نوشتن در Cloud Firestore

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

برای انواع نوشتن‌ها، Cloud Firestore ویژگی‌های ACID (اتمی بودن، سازگاری، جداسازی، و ماندگاری) پایگاه‌های داده رابطه‌ای را ارائه می‌دهد. ‫Cloud Firestore همچنین سریال‌سازی را ارائه می‌دهد، به این معنی که همه تراکنش‌ها به‌گونه‌ای ظاهر می‌شوند که گویی به ترتیب سریال اجرا شده‌اند.

مراحل سطح بالا در تراکنش نوشتن

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

به‌عنوان اولین مرحله از تراکنش، Cloud Firestore سند موجود را می‌خواند و جهش‌هایی را که باید در داده‌های جدول «اسناد» ایجاد شود تعیین می‌کند.

این شامل به‌روزرسانی‌های لازم در جدول «نمایه‌ها» به‌شرح زیر نیز می‌شود:

• فیلدهایی که به اسناد اضافه می‌شوند باید درج‌های متناظر در جدول «نمایه‌ها» داشته باشند.
• فیلدهایی که از اسناد برداشته می‌شوند باید در جدول «نمایه‌ها» حذف شوند.
• فیلدهایی که در اسناد اصلاح می‌شوند، هم به حذف (برای مقادیر قدیمی) و هم به درج (برای مقادیر جدید) در جدول «نمایه‌ها» نیاز دارند.

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

پس‌از محاسبه جهش‌ها، Cloud Firestore آن‌ها را در یک تراکنش جمع‌آوری می‌کند و سپس آن را ثبت می‌کند.

آشنایی با تراکنش نوشتن در لایه فضای ذخیره‌سازی

همان‌طور که قبلاً بحث شد، نوشتن در Cloud Firestore شامل تراکنش خواندن-نوشتن در لایه فضای ذخیره‌سازی است. بسته به چیدمان داده‌ها، نوشتن ممکن است شامل یک یا چند تقسیم باشد، همان‌طور که در چیدمان داده‌ها دیده می‌شود.

در نمودار زیر، پایگاه داده Cloud Firestore دارای هشت بخش (با علامت ۱ تا ۸) است که در سه سرور ذخیره‌سازی مختلف در یک منطقه میزبانی می‌شوند و هر بخش در ۳(یا بیشتر) منطقه مختلف تکرار می‌شود. هر بخش یک رهبر Paxos دارد که ممکن است برای بخش‌های مختلف در منطقه متفاوتی باشد.

تقسیم پایگاه داده Cloud Firestore">

پایگاه داده Cloud Firestore را درنظر بگیرید که مجموعه Restaurants را به‌صورت زیر دارد:

کارخواه Cloud Firestore با به‌روزرسانی مقدار فیلد priceCategory، تغییر زیر را برای سندی در مجموعه Restaurant درخواست می‌کند.

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

1. تراکنش خواندن-نوشتن ایجاد کنید.
2. سند restaurant1 را در مجموعه Restaurants از جدول اسناد از لایه فضای ذخیره‌سازی بخوانید.
3. نمایه‌های سند را از جدول نمایه‌ها بخوانید.
4. جهش‌هایی را که باید در داده‌ها ایجاد شود محاسبه کنید. در این مورد، پنج جهش وجود دارد:
   • M1: ردیف مربوط به restaurant1 را در جدول اسناد به‌روز کنید تا تغییر مقدار فیلد priceCategory اعمال شود.
   • M2 و M3: ردیف‌های مربوط به مقدار قدیمی priceCategory را در جدول نمایه‌ها برای نمایه‌های نزولی و صعودی حذف کنید.
   • M4 و M5: ردیف‌های مربوط به مقدار جدید priceCategory را در جدول نمایه‌ها برای نمایه‌های نزولی و صعودی درج کنید.
5. این جهش‌ها را ثبت کنید.

کارخواه فضای ذخیره‌سازی در سرویس Cloud Firestore بخش‌هایی را که مالک کلیدهای ردیف‌های قابل‌تغییر هستند جستجو می‌کند. موردی را درنظر بگیرید که در آن «بخش ۳» به M1 و «بخش ۶» به M2-M5 خدمات ارائه می‌دهد. تراکنش توزیع‌شده‌ای وجود دارد که همه این تقسیم‌ها را به‌عنوان شرکت‌کننده دربرمی‌گیرد. بخش‌های شرکت‌کننده ممکن است شامل هر بخش دیگری نیز باشد که داده‌ها قبلاً به‌عنوان بخشی از تراکنش خواندن-نوشتن از آن خوانده شده است.

مراحل زیر آنچه را که به‌عنوان بخشی از ثبت اتفاق می‌افتد شرح می‌دهد:

1. کارخواه فضای ذخیره‌سازی یک commit صادر می‌کند. این ثبت حاوی جهش‌های M1-M5 است.
2. بخش‌های ۳ و ۶ شرکت‌کنندگان در این تراکنش هستند. یکی از شرکت‌کنندگان به‌عنوان هماهنگ‌کننده انتخاب می‌شود، مثلاً Split 3. وظیفه هماهنگ‌کننده این است که مطمئن شود تراکنش به‌صورت اتمی در همه شرکت‌کنندگان انجام می‌شود یا لغو می‌شود.
   • نسخه‌های رهبر این تقسیم‌ها مسئول کارهای انجام‌شده توسط شرکت‌کنندگان و هماهنگ‌کنندگان هستند.
3. هر شرکت‌کننده و هماهنگ‌کننده یک الگوریتم Paxos را با نسخه‌های تکراری مربوطه خود اجرا می‌کند.
   • رهبر الگوریتم Paxos را با نسخه‌های تکراری اجرا می‌کند. اگر اکثر نسخه‌های تکراری با پاسخ ok to commit به رهبر پاسخ دهند، حد نصاب حاصل می‌شود.
   • سپس هر شرکت‌کننده وقتی آماده شد به هماهنگ‌کننده اطلاع می‌دهد (فاز اول از فاز دو مرحله‌ای). اگر هریک از شرکت‌کنندگان نتواند تراکنش را انجام دهد، کل تراکنش aborts.
4. وقتی هماهنگ‌کننده متوجه شد که همه شرکت‌کنندگان، ازجمله خودش، آماده هستند، نتیجه تراکنش accept را به همه شرکت‌کنندگان اعلام می‌کند (فاز دوم از تعهد دومرحله‌ای). در این مرحله، هر شرکت‌کننده تصمیم ثبت را در فضای ذخیره‌سازی پایدار ثبت می‌کند و تراکنش ثبت می‌شود.
5. هماهنگ‌کننده در Cloud Firestore به کارخواه فضای ذخیره‌سازی پاسخ می‌دهد که تراکنش انجام شده است. به‌طور موازی، هماهنگ‌کننده و همه شرکت‌کنندگان جهش‌ها را روی داده‌ها اعمال می‌کنند.

وقتی پایگاه داده Cloud Firestore کوچک باشد، ممکن است یک تقسیم واحد مالک همه کلیدها در جهش‌های M1-M5 باشد. در چنین موردی، فقط یک شرکت‌کننده در تراکنش وجود دارد و به ثبت دو مرحله‌ای که قبلاً ذکر شد نیازی نیست، بنابراین نوشتن سریع‌تر انجام می‌شود.

نوشتن در چندمنطقه‌ای

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

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

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

آشنایی با عمر خواندن به Cloud Firestore

این بخش به خواندن‌های مستقل و غیرهم‌زمان در Cloud Firestore می‌پردازد. در داخل، سرور Cloud Firestore اکثر این پُرسمان‌ها را در دو مرحله اصلی مدیریت می‌کند:

1. یک اسکن گستره تکی روی جدول نمایه‌ها
2. جستجوی نقطه‌ای در جدول اسناد براساس نتیجه اسکن قبلی

ممکن است برخی پرسمان‌ها به پردازش کمتر یا پردازش بیشتر (برای مثال، پرسمان‌های IN) در Cloud Firestore نیاز داشته باشند.

داده‌های خوانده‌شده از لایه ذخیره‌سازی به‌طور داخلی بااستفاده از تراکنش پایگاه داده انجام می‌شود تا خواندن‌های سازگار تضمین شود. اما برخلاف تراکنش‌های مورداستفاده برای نوشتن، این تراکنش‌ها قفل نمی‌شوند. درعوض، آن‌ها با انتخاب مُهر زمان و سپس اجرای همه خواندن‌ها در آن مُهر زمان کار می‌کنند. ازآنجایی‌که این تراکنش‌ها قفل نمی‌شوند، تراکنش‌های خواندن-نوشتن هم‌زمان را مسدود نمی‌کنند. برای اجرای این تراکنش، کلاینت فضای ذخیره‌سازی در Cloud Firestore یک محدوده مُهر زمان را مشخص می‌کند که به لایه فضای ذخیره‌سازی می‌گوید چگونه مُهر زمان خواندن را انتخاب کند. نوع حد مُهر زمان انتخاب‌شده توسط کارخواه فضای ذخیره‌سازی در Cloud Firestore با گزینه‌های خواندن برای درخواست «خواندن» تعیین می‌شود.

آشنایی با تراکنش خواندن در لایه فضای ذخیره‌سازی

این بخش انواع خواندن‌ها و نحوه پردازش آن‌ها را در لایه ذخیره‌سازی در Cloud Firestore شرح می‌دهد.

مطالب خواندنی قوی

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

خواندن تقسیم تکی

کارخواه فضای ذخیره‌سازی در Cloud Firestore بخش‌هایی را که کلیدهای ردیف‌های خواندنی را دارند جستجو می‌کند. فرض کنیم که باید از «بخش ۳» در بخش قبلی خوانده شود. کارخواه درخواست خواندن را به نزدیک‌ترین نسخه مشابه ارسال می‌کند تا تأخیر رفت‌وبرگشت را کاهش دهد.

در این مرحله، بسته به نسخه کپی انتخاب‌شده، ممکن است موارد زیر اتفاق بیفتد:

• درخواست خواندن به نسخه رهبر (منطقه الف) می‌رود.
  • ازآنجایی‌که رهبر همیشه به‌روز است، خواندن می‌تواند مستقیماً ادامه یابد.
• درخواست خواندن به یک نسخه غیراصلی (مانند منطقه B) می‌رود
  • بخش ۳ ممکن است ازطریق وضعیت داخلی خود بداند که اطلاعات کافی برای ارائه خواندن را دارد و بخش این کار را انجام می‌دهد.
  • Split 3 مطمئن نیست که جدیدترین داده‌ها را دیده است یا نه. این روش پیامی به رهبر ارسال می‌کند تا مُهر زمان آخرین تراکنشی را که باید برای ارائه خواندن اعمال کند درخواست کند. وقتی آن تراکنش اعمال شد، خواندن می‌تواند ادامه یابد.

سپس Cloud Firestore پاسخ را به کارخواه خود برمی‌گرداند.

خواندن چندبخشی

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

خوانش‌های قدیمی

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

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

اجتناب از نقاط داغ

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

تقسیم فضای ذخیره‌سازی و بار زمان‌بر است و افزایش سریع ترافیک ممکن است باعث تأخیر زیاد یا خطاهای فراتر رفتن از مهلت شود که معمولاً به آن‌ها نقاط داغ می‌گویند، درحالی‌که سرویس تنظیم می‌شود. بهترین روش این است که عملیات را در سراسر محدوده کلید توزیع کنید و درعین‌حال ترافیک را در مجموعه‌ای در پایگاه داده با ۵۰۰ عملیات در ثانیه افزایش دهید. پس‌از این افزایش تدریجی، ترافیک را هر پنج دقیقه تا ۵۰٪ افزایش دهید. این فرایند قانون ۵۰۰/۵۰/۵ نامیده می‌شود و پایگاه داده را در موقعیتی قرار می‌دهد که به‌طور بهینه مقیاس‌بندی شود تا حجم کاری شما را برآورده کند.

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

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

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

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

عیب‌یابی

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

بعدی چیست؟

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