این سند را برای راهنمایی در مورد مقیاس گذاری برنامه بدون سرور خود فراتر از هزاران عملیات در ثانیه یا صدها هزار کاربر همزمان بخوانید. این سند شامل موضوعات پیشرفته برای کمک به درک عمیق سیستم است. اگر به تازگی با Cloud Firestore شروع کرده اید، به جای آن به راهنمای شروع سریع مراجعه کنید.
Cloud Firestore و SDKهای موبایل/وب Firebase یک مدل قدرتمند برای توسعه برنامه‌های بدون سرور ارائه می‌کنند که در آن کد سمت کلاینت مستقیماً به پایگاه داده دسترسی پیدا می‌کند. SDKها به مشتریان اجازه می‌دهند به‌روزرسانی‌های داده‌ها را در زمان واقعی گوش دهند. می‌توانید از به‌روزرسانی‌های بی‌درنگ برای ساخت برنامه‌های واکنش‌گرا که به زیرساخت سرور نیاز ندارند، استفاده کنید. اگرچه راه‌اندازی و اجرا کردن چیزی بسیار آسان است، اما به درک محدودیت‌های موجود در سیستم‌هایی که Cloud Firestore را تشکیل می‌دهند کمک می‌کند تا برنامه بدون سرور شما در زمان افزایش ترافیک، مقیاس‌پذیر شود و عملکرد خوبی داشته باشد.
برای مشاوره در مورد افزایش مقیاس برنامه خود به بخش های زیر مراجعه کنید.
یک مکان پایگاه داده نزدیک به کاربران خود انتخاب کنید
نمودار زیر معماری یک اپلیکیشن بلادرنگ را نشان می دهد:
هنگامی که برنامه‌ای که در دستگاه کاربر اجرا می‌شود (موبایل یا وب) با Cloud Firestore ارتباط برقرار می‌کند، اتصال به یک سرور frontend Cloud Firestore در همان منطقه ای که پایگاه داده شما در آن قرار دارد هدایت می‌شود. به عنوان مثال، اگر پایگاه داده شما در us-east1 باشد، اتصال به یک فرانت اند Cloud Firestore نیز در us-east1 می رود. این اتصالات عمر طولانی دارند و تا زمانی که برنامه به صراحت بسته نشود باز می مانند. قسمت جلویی داده ها را از سیستم های ذخیره سازی Cloud Firestore زیرین می خواند.
فاصله بین مکان فیزیکی کاربر و مکان پایگاه داده Cloud Firestore بر تأخیر تجربه شده توسط کاربر تأثیر می گذارد. برای مثال، کاربری در هند که برنامه‌اش با پایگاه داده‌ای در یک منطقه Google Cloud در آمریکای شمالی صحبت می‌کند، ممکن است تجربه کندتر و نرم‌افزار کمتری نسبت به زمانی که پایگاه داده نزدیک‌تر باشد، مثلاً در هند یا در بخشی دیگر از آسیا، تجربه کندتر و نرم‌افزار کمتری پیدا کند. .
طراحی برای قابلیت اطمینان
موضوعات زیر قابلیت اطمینان برنامه شما را بهبود می بخشد یا بر آن تأثیر می گذارد:
حالت آفلاین را فعال کنید
SDK های Firebase پایداری داده های آفلاین را ارائه می دهند. اگر برنامه موجود در دستگاه کاربر نتواند به Cloud Firestore متصل شود، برنامه با کار با داده‌های ذخیره‌شده محلی قابل استفاده باقی می‌ماند. این امر دسترسی به داده‌ها را تضمین می‌کند حتی زمانی که کاربران اتصالات اینترنتی ناقص را تجربه می‌کنند یا برای چندین ساعت یا چند روز به طور کامل دسترسی را از دست می‌دهند. برای جزئیات بیشتر در مورد حالت آفلاین، به فعال کردن داده آفلاین مراجعه کنید.
تلاش های مجدد خودکار را درک کنید
Firebase SDK از تلاش مجدد عملیات و برقراری مجدد اتصالات شکسته مراقبت می کند. این به رفع خطاهای گذرا ناشی از راه اندازی مجدد سرورها یا مشکلات شبکه بین مشتری و پایگاه داده کمک می کند.
بین مکان های منطقه ای و چند منطقه ای انتخاب کنید
هنگام انتخاب بین مکان های منطقه ای و چند منطقه ای چندین مبادله وجود دارد. تفاوت اصلی این است که چگونه داده ها تکرار می شوند. این باعث تضمین در دسترس بودن برنامه شما می شود. یک نمونه چند منطقه ای قابلیت اطمینان سرویس دهی قوی تری می دهد و ماندگاری داده های شما را افزایش می دهد، اما مبادله آن هزینه است.
سیستم پرس و جو بلادرنگ را درک کنید
پرس و جوهای بلادرنگ که شنونده عکس فوری نیز نامیده می شوند، به برنامه اجازه می دهند به تغییرات پایگاه داده گوش دهد و به محض تغییر داده ها اعلان هایی با تاخیر کم دریافت کند. یک برنامه می‌تواند با نظرسنجی دوره‌ای پایگاه داده برای به‌روزرسانی‌ها، همان نتیجه را بگیرد، اما اغلب کندتر، گران‌تر است و به کد بیشتری نیاز دارد. برای مثال‌هایی از نحوه راه‌اندازی و استفاده از جستارهای همزمان، به دریافت به‌روزرسانی‌های همزمان مراجعه کنید. بخش‌های زیر به جزئیات نحوه عملکرد شنوندگان عکس فوری می‌پردازند و برخی از بهترین روش‌ها را برای مقیاس‌بندی پرسش‌های بلادرنگ با حفظ عملکرد توصیف می‌کنند.
دو کاربر را تصور کنید که از طریق یک برنامه پیام رسانی ساخته شده با یکی از SDK های تلفن همراه به Cloud Firestore متصل می شوند.
کلاینت A برای افزودن و به روز رسانی اسناد در مجموعه ای به نام chatroom به پایگاه داده می نویسد:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
کلاینت B با استفاده از شنونده عکس فوری به به‌روزرسانی‌ها در همان مجموعه گوش می‌دهد. هر زمان که شخصی پیام جدیدی ایجاد کند، کلاینت B یک اعلان فوری دریافت می کند. نمودار زیر معماری پشت یک شنونده عکس فوری را نشان می دهد:
زمانی که Client B یک شنونده عکس فوری را به پایگاه داده متصل می کند، توالی رویدادهای زیر رخ می دهد:
- Client B یک اتصال به Cloud Firestore باز می کند و یک شنونده را با برقراری تماس با
onSnapshot(collection("chatroom"))از طریق Firebase SDK ثبت می کند. این شنونده می تواند ساعت ها فعال بماند. - فرانت‌اند Cloud Firestore از سیستم ذخیره‌سازی زیربنایی پرس و جو می‌کند تا مجموعه داده را بوت استرپ کند. کل مجموعه نتیجه اسناد تطبیق را بارگیری می کند. ما به این به عنوان یک پرسش نظرسنجی اشاره می کنیم. سپس سیستم قوانین امنیتی Firebase پایگاه داده را ارزیابی می کند تا تأیید کند که کاربر می تواند به این داده ها دسترسی داشته باشد. اگر کاربر مجاز باشد، پایگاه داده داده ها را به کاربر برمی گرداند.
- پرس و جو مشتری B سپس به حالت گوش دادن منتقل می شود. شنونده با یک کنترل کننده اشتراک ثبت نام می کند و منتظر به روز رسانی داده ها است.
- کلاینت A اکنون یک عملیات نوشتن برای تغییر یک سند ارسال می کند.
- پایگاه داده تغییر سند را به سیستم ذخیره سازی خود انجام می دهد.
- از نظر معاملاتی، سیستم همان به‌روزرسانی را به یک تغییرات داخلی متعهد می‌کند. تغییرات ثبت یک ترتیب دقیق از تغییرات به عنوان آنها ایجاد می کند.
- تغییرات به نوبه خود داده های به روز شده را به مجموعه ای از کنترل کننده های اشتراک ارسال می کند.
- یک تطبیق پرس و جو معکوس اجرا می شود تا ببیند آیا سند به روز شده با هر شنونده عکس فوری ثبت شده فعلی مطابقت دارد یا خیر. در این مثال، سند با شنونده عکس فوری Client B مطابقت دارد. همانطور که از نام آن پیداست، می توانید تطبیق پرس و جو معکوس را به عنوان یک پرس و جو پایگاه داده معمولی در نظر بگیرید اما به صورت معکوس انجام می شود. به جای جستجو در اسناد برای یافتن مواردی که با یک پرس و جو مطابقت دارند، به طور موثر در جستجوها جستجو می کند تا مواردی را که با یک سند ورودی مطابقت دارند را بیابد. پس از یافتن یک مطابقت، سیستم سند مورد نظر را به شنوندگان عکس فوری ارسال می کند. سپس سیستم قوانین امنیتی Firebase پایگاه داده را ارزیابی می کند تا مطمئن شود که فقط کاربران مجاز داده ها را دریافت می کنند.
- سیستم به روز رسانی سند را به SDK در دستگاه مشتری B ارسال می کند و پاسخ به تماس
onSnapshotفعال می شود. اگر تداوم محلی فعال باشد، SDK به‌روزرسانی را در حافظه پنهان محلی نیز اعمال می‌کند.
بخش مهمی از مقیاس پذیری Cloud Firestore به خروج از تغییرات ثبت شده به کنترل کننده های اشتراک و سرورهای فرانت اند بستگی دارد. فن خروجی به یک داده اجازه می دهد تا به طور موثر منتشر شود تا به میلیون ها پرس و جوی بلادرنگ و کاربران متصل ارائه شود. Cloud Firestore با اجرای کپی‌های بسیاری از همه این مؤلفه‌ها در چندین منطقه (یا چندین منطقه در مورد استقرار چند منطقه‌ای)، به دسترسی و مقیاس‌پذیری بالایی دست می‌یابد.
شایان ذکر است که تمام عملیات خواندن صادر شده از SDK های موبایل و وب از مدل بالا پیروی می کنند. آنها یک پرس و جوی نظرسنجی و به دنبال آن حالت گوش دادن برای حفظ ضمانت های سازگاری انجام می دهند. این همچنین برای شنوندگان بلادرنگ، تماس‌هایی که برای بازیابی یک سند و پرس‌وجوهای تک‌شات انجام می‌شود، صدق می‌کند. می‌توانید بازیابی سند تکی و پرس‌وجوهای تک‌شات را به‌عنوان شنوندگان عکس فوری کوتاه‌مدت در نظر بگیرید که با محدودیت‌های مشابهی در مورد عملکرد همراه هستند.
بهترین شیوه ها را برای مقیاس بندی پرس و جوهای بلادرنگ اعمال کنید
بهترین روش‌های زیر را برای طراحی پرسش‌های بلادرنگ مقیاس‌پذیر اعمال کنید.
ترافیک نوشتن بالا در سیستم را درک کنید
این بخش به شما کمک می کند تا بفهمید سیستم چگونه به تعداد فزاینده ای از درخواست های نوشتن پاسخ می دهد.
تغییرات Cloud Firestore که پرس و جوهای بلادرنگ را به طور خودکار به صورت افقی با افزایش ترافیک نوشتن هدایت می کند. از آنجایی که نرخ نوشتن برای یک پایگاه داده فراتر از آن چیزی است که یک سرور می تواند مدیریت کند، تغییرات ثبت شده در چندین سرور تقسیم می شود و پردازش پرس و جو شروع به مصرف داده ها از چندین کنترل کننده اشتراک به جای یک می کند. از دیدگاه کلاینت و SDK، همه اینها شفاف است و در صورت وقوع انشعاب، هیچ اقدامی از برنامه لازم نیست. نمودار زیر چگونگی مقیاس پرس و جوهای بلادرنگ را نشان می دهد:
مقیاس‌بندی خودکار به شما امکان می‌دهد ترافیک نوشتن خود را بدون محدودیت افزایش دهید، اما با افزایش ترافیک، پاسخ سیستم ممکن است کمی طول بکشد. توصیه های قانون 5-5-5 را دنبال کنید تا از ایجاد نقطه اتصال نوشتن اجتناب کنید. Key Visualizer یک ابزار مفید برای تجزیه و تحلیل نقاط مهم نوشتن است.
بسیاری از برنامه‌ها دارای رشد ارگانیک قابل پیش‌بینی هستند که Cloud Firestore می‌تواند بدون احتیاط از آن استفاده کند. با این حال، بارهای کاری دسته‌ای مانند وارد کردن یک مجموعه داده بزرگ، می‌تواند نوشتن را خیلی سریع افزایش دهد. همانطور که برنامه خود را طراحی می کنید، از اینکه ترافیک نوشتن شما از کجا می آید آگاه باشید.
نحوه تعامل نوشتن و خواندن را درک کنید
شما می توانید سیستم پرس و جوی بلادرنگ را به عنوان خط لوله ای که عملیات نوشتن را با خواننده ها متصل می کند، در نظر بگیرید. هر زمان که سندی ایجاد، به‌روزرسانی یا حذف می‌شود، این تغییر از سیستم ذخیره‌سازی به شنوندگان ثبت‌شده فعلی منتشر می‌شود. ساختار تغییرات Cloud Firestore یکپارچگی قوی را تضمین می‌کند، به این معنی که برنامه شما هرگز اعلان‌های به‌روزرسانی‌هایی را دریافت نمی‌کند که در مقایسه با زمانی که پایگاه داده تغییرات داده‌ها را انجام می‌دهد، نامرتب هستند. این امر توسعه برنامه را با حذف موارد لبه حول ثبات داده ها ساده می کند.
این خط لوله متصل به این معنی است که یک عملیات نوشتن که باعث ایجاد هات اسپات یا اختلاف قفل می شود می تواند بر عملیات خواندن تأثیر منفی بگذارد. هنگامی که عملیات نوشتن با شکست مواجه می‌شود یا کاهش می‌یابد، ممکن است خواندن در انتظار داده‌های ثابت از تغییرات ثبت شود. اگر این اتفاق در برنامه شما بیفتد، ممکن است هم عملیات نوشتن کند و هم زمان پاسخ آهسته مرتبط برای پرس و جوها را ببینید. اجتناب از نقاط مهم کلیدی برای فرار از این مشکل است.
اسناد را کوچک نگه دارید و عملیات بنویسید
هنگام ساختن برنامه‌ها با شنونده‌های عکس فوری، معمولاً می‌خواهید کاربران به سرعت از تغییرات داده‌ها مطلع شوند. برای رسیدن به این هدف، سعی کنید چیزها را کوچک نگه دارید. این سیستم می تواند اسناد کوچک با ده ها فیلد را خیلی سریع از طریق سیستم عبور دهد. پردازش اسناد بزرگتر با صدها فیلد و داده های بزرگ به زمان بیشتری نیاز دارد.
به همین ترتیب، از انجام عملیات کوتاه و سریع و نوشتن برای پایین نگه داشتن تاخیر استفاده کنید. دسته های بزرگ ممکن است از دیدگاه نویسنده به شما توان عملیاتی بالاتری بدهد، اما در واقع ممکن است زمان اعلان را برای شنوندگان عکس فوری افزایش دهد. این اغلب در مقایسه با استفاده از سایر سیستم های پایگاه داده که در آن شما ممکن است از دسته بندی برای بهبود عملکرد استفاده کنید، غیرمعمول است.
از شنوندگان کارآمد استفاده کنید
با افزایش نرخ نوشتن برای پایگاه داده شما، Cloud Firestore پردازش داده ها را در بسیاری از سرورها تقسیم می کند. الگوریتم اشتراک‌گذاری Cloud Firestore سعی می‌کند تا داده‌ها را از همان مجموعه یا گروه جمع‌آوری در همان سرور تغییرات ایجاد کند. این سیستم سعی می‌کند تا سرعت نوشتن ممکن را به حداکثر برساند و در عین حال تعداد سرورهای درگیر در پردازش یک پرس و جو را تا حد ممکن کم نگه دارد.
با این حال، برخی از الگوها ممکن است همچنان منجر به رفتار غیربهینه برای شنوندگان عکس فوری شود. به عنوان مثال، اگر برنامه شما بیشتر داده های خود را در یک مجموعه بزرگ ذخیره می کند، شنونده ممکن است برای دریافت تمام داده های مورد نیاز خود به سرورهای زیادی متصل شود. حتی اگر فیلتر پرس و جو را اعمال کنید، این موضوع صادق است. اتصال به بسیاری از سرورها خطر پاسخ های کندتر را افزایش می دهد.
برای جلوگیری از این پاسخ های کندتر، طرح و برنامه خود را طوری طراحی کنید که سیستم بتواند بدون مراجعه به سرورهای مختلف به شنوندگان خدمات ارائه دهد. ممکن است بهترین کار این باشد که داده های خود را به مجموعه های کوچکتر با نرخ نوشتن کمتر تقسیم کنید.
این شبیه به تفکر در مورد پرس و جوهای عملکرد در یک پایگاه داده رابطه ای است که به اسکن کامل جدول نیاز دارد. در یک پایگاه داده رابطه‌ای، پرس و جوی که به اسکن کامل جدول نیاز دارد، معادل یک شنونده عکس فوری است که مجموعه‌ای با شدت بالا را تماشا می‌کند. ممکن است در مقایسه با پرس و جوی که پایگاه داده می تواند با استفاده از یک نمایه خاص تر ارائه دهد کند عمل کند. یک پرس و جو با یک نمایه خاص تر مانند یک شنونده عکس فوری است که یک سند واحد یا مجموعه ای را که کمتر تغییر می کند تماشا می کند. برای درک بهتر رفتار و نیاز مورد استفاده خود، باید برنامه خود را آزمایش کنید.
به سوالات نظرسنجی سریع ادامه دهید
یکی دیگر از بخش‌های کلیدی پرس‌وجوهای بلادرنگ پاسخگو این است که مطمئن شوید که کوئری نظرسنجی برای راه‌اندازی داده‌ها سریع و کارآمد است. اولین باری که یک شنونده عکس فوری جدید متصل می شود، شنونده باید کل مجموعه نتیجه را بارگیری کند و آن را به دستگاه کاربر ارسال کند. پرس و جوهای آهسته باعث می شود برنامه شما کمتر پاسخگو باشد. این شامل، برای مثال، پرس و جوهایی است که سعی در خواندن بسیاری از اسناد دارند یا پرس و جوهایی که از نمایه های مناسب استفاده نمی کنند.
یک شنونده همچنین ممکن است تحت شرایطی از حالت گوش دادن به حالت نظرسنجی برگردد. این به طور خودکار اتفاق می افتد و برای SDK ها و برنامه شما شفاف است. شرایط زیر ممکن است باعث ایجاد وضعیت نظرسنجی شود:
- این سیستم به دلیل تغییرات بار ، یک Chanloglog را دوباره متعادل می کند .
- هات‌اسپات باعث نوشتن ناموفق یا تأخیر در پایگاه داده می‌شود.
- راه اندازی مجدد سرور موقت به طور موقت بر شنوندگان تأثیر می گذارد.
اگر درخواست های نظرسنجی شما به اندازه کافی سریع باشد، وضعیت نظرسنجی برای کاربران برنامه شما شفاف می شود.
از شنوندگان با عمر طولانی حمایت کنید
باز کردن و زنده نگه داشتن شنوندگان تا زمانی که ممکن است اغلب مقرون به صرفه ترین راه برای ساخت برنامه ای است که از Cloud Firestore استفاده می کند. هنگام استفاده از Cloud Firestore، برای اسنادی که به برنامه خود بازگردانده می شوند و نه برای حفظ یک اتصال باز، صورتحساب دریافت می کنید. یک شنونده عکس فوری با عمر طولانی فقط داده هایی را می خواند که برای ارائه پرس و جو در طول عمرش نیاز دارد. این شامل یک عملیات نظرسنجی اولیه و به دنبال آن اعلان هایی است که داده ها واقعاً تغییر می کنند. از سوی دیگر، کوئری‌های تک‌شات، داده‌هایی را که ممکن است از آخرین باری که برنامه درخواست را اجرا کرده است، تغییر نکرده باشد، دوباره می‌خوانند.
در مواردی که برنامه شما باید میزان بالایی از داده مصرف کند، شنوندگان عکس فوری ممکن است مناسب نباشند. به عنوان مثال، اگر مورد استفاده شما اسناد زیادی را در هر ثانیه از طریق یک اتصال برای مدت زمان طولانی منتقل می کند، ممکن است بهتر باشد پرس و جوهای تک شات که با فرکانس کمتر اجرا می شوند را انتخاب کنید.
چه خبر بعدی
- نحوه استفاده از شنوندگان عکس فوری را بیاموزید.
- درباره بهترین شیوه های بیشتر بخوانید.