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

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

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

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

بخش‌های زیر را برای بهترین شیوه‌ها قبل از معماری برنامه‌تان ببینید.

اجزای سطح بالا را درک کنید

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

Cloud Firestore SDK و کتابخانه های سرویس گیرنده

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

Google Front End (GFE)

این یک سرویس زیرساخت مشترک برای همه سرویس های ابری گوگل است. GFE درخواست های دریافتی را می پذیرد و آنها را به سرویس مربوطه Google (سرویس 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 داده ها را به قطعات جداگانه تقسیم می کند که می توانند در چندین ماشین یا سرور ذخیره سازی ذخیره شوند و از آنها استفاده شود. این پارتیشن ها بر روی جداول پایگاه داده در بلوک هایی از محدوده های کلیدی به نام split ساخته می شوند.

همانندسازی همزمان

توجه به این نکته ضروری است که پایگاه داده همیشه به صورت خودکار و همزمان تکرار می شود. تقسیم‌بندی داده‌ها دارای کپی‌هایی در مناطق مختلف هستند تا حتی زمانی که یک منطقه غیرقابل دسترس می‌شود، در دسترس باقی بماند. تکرار مداوم به کپی های مختلف تقسیم توسط الگوریتم 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 سند موجود را می خواند و جهش هایی را که باید در داده های جدول اسناد ایجاد شود را تعیین می کند.

این همچنین شامل به‌روزرسانی‌های لازم در جدول Indexes به شرح زیر است:

• فیلدهایی که به اسناد اضافه می شوند نیاز به درج مربوطه در جدول Indexes دارند.
• فیلدهایی که از اسناد حذف می شوند نیاز به حذف مربوطه در جدول Indexes دارند.
• فیلدهایی که در اسناد در حال تغییر هستند، هم نیاز به حذف (برای مقادیر قدیمی) و هم درج (برای مقادیر جدید) در جدول Indexes دارند.

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

هنگامی که جهش ها محاسبه شدند، Cloud Firestore آنها را در داخل یک تراکنش جمع آوری می کند و سپس آن را انجام می دهد.

درک یک تراکنش نوشتن در لایه ذخیره سازی

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

در نمودار زیر، پایگاه داده Cloud Firestore دارای هشت تقسیم (با علامت 1-8) است که بر روی سه سرور ذخیره سازی مختلف در یک منطقه واحد میزبانی شده است، و هر تقسیم در 3 (یا بیشتر) منطقه مختلف تکرار می شود. هر تقسیم دارای یک رهبر Paxos است که ممکن است برای تقسیم های مختلف در منطقه متفاوتی باشد.

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

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

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

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

سرویس گیرنده ذخیره سازی در سرویس Cloud Firestore به دنبال تقسیم هایی است که دارای کلیدهای ردیف هایی است که باید تغییر کنند. بیایید موردی را در نظر بگیریم که در آن Split 3 به M1 خدمت می کند و Split 6 به M2-M5 خدمت می کند. یک تراکنش توزیع شده وجود دارد که شامل همه این تقسیم ها به عنوان شرکت کننده است . تقسیم‌های شرکت‌کننده ممکن است شامل هر تقسیم دیگری باشد که داده‌ها از آن زودتر به عنوان بخشی از تراکنش خواندن و نوشتن خوانده شده است.

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

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

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

در چند منطقه می نویسد

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

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

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

زندگی خواندن در Cloud Firestore را درک کنید

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

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

ممکن است پرس و جوهای خاصی در Cloud Firestore نیاز به پردازش کمتر یا پردازش بیشتری داشته باشند (مثلاً جستارهای IN).

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

یک تراکنش خوانده شده در لایه ذخیره سازی را درک کنید

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

خواندنی قوی

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

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

سرویس گیرنده ذخیره سازی در Cloud Firestore به دنبال شکاف هایی است که دارای کلیدهای ردیف هایی هستند که باید خوانده شوند. بیایید فرض کنیم که نیاز به خواندن از Split 3 از بخش قبلی دارد. مشتری برای کاهش تاخیر رفت و برگشت، درخواست خواندن را به نزدیکترین ماکت ارسال می کند.

در این مرحله، بسته به ماکت انتخابی، موارد زیر ممکن است رخ دهد:

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

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

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

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

استال می خواند

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

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

از نقاط داغ پرهیز کنید

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

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

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

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

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

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

عیب یابی

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

چه خبر بعدی

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