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