يمكنك قراءة هذا المستند للحصول على إرشادات حول توسيع نطاق تطبيقك الذي يعمل بدون خادم ليتجاوز آلاف العمليات في الثانية أو مئات الآلاف من المستخدمين المتزامنين. يتضمن هذا المستند مواضيع متقدمة لمساعدتك في فهم النظام بعمق. إذا كنت قد بدأت للتو في استخدام Cloud Firestore، يمكنك الاطّلاع على دليل البدء السريع بدلاً من ذلك.
توفّر Cloud Firestore وحِزم تطوير البرامج (SDK) للأجهزة الجوّالة/الويب من Firebase نموذجًا فعّالاً لتطوير التطبيقات التي لا تتطلّب خادمًا، حيث يمكن للرمز البرمجي من جهة العميل الوصول مباشرةً إلى قاعدة البيانات. تتيح حِزم تطوير البرامج (SDK) للعملاء الاستماع إلى تعديلات البيانات في الوقت الفعلي. يمكنك استخدام التعديلات في الوقت الفعلي لإنشاء تطبيقات متجاوبة لا تتطلّب بنية أساسية للخادم. على الرغم من سهولة تشغيل التطبيقات، من المفيد فهم القيود في الأنظمة التي تشكّل Cloud Firestore لكي يتوسّع تطبيقك الذي يعتمد على الحوسبة بدون خادم ويعمل بشكل جيد عند زيادة عدد الزيارات.
يمكنك الاطّلاع على الأقسام التالية للحصول على نصائح حول توسيع نطاق تطبيقك.
اختيار موقع جغرافي لقاعدة البيانات قريب من المستخدمين
يوضّح المخطّط البياني التالي بنية تطبيق في الوقت الفعلي:
عندما ينشئ تطبيق قيد التشغيل على جهاز المستخدم (جهاز جوّال أو ويب) اتصالاً بـ Cloud Firestore، يتم توجيه الاتصال إلى خادم واجهة أمامية لـ Cloud Firestore في المنطقة نفسها التي توجد بها قاعدة بياناتك. على سبيل المثال، إذا كانت قاعدة بياناتك في us-east1، ينتقل الاتصال أيضًا إلى واجهة أمامية في Cloud Firestore في us-east1 أيضًا. هذه الاتصالات
طويلة الأمد وتظل مفتوحة حتى يتم إغلاقها صراحةً بواسطة التطبيق. تقرأ الواجهة الأمامية البيانات من أنظمة تخزين Cloud Firestore الأساسية.
تؤثر المسافة بين الموقع الجغرافي الفعلي للمستخدم وموقع قاعدة بيانات Cloud Firestore في وقت الاستجابة الذي يواجهه المستخدم. على سبيل المثال، قد يجد المستخدم في الهند الذي يتصل تطبيقه بقاعدة بيانات في منطقة Google Cloud في أمريكا الشمالية أنّ التجربة أبطأ والتطبيق أقل سرعة مما لو كانت قاعدة البيانات تقع في مكان أقرب، مثل الهند أو في جزء آخر من آسيا.
التصميم من أجل الموثوقية
تؤدي المواضيع التالية إلى تحسين موثوقية تطبيقك أو التأثير فيها:
تفعيل وضع عدم الاتصال بالإنترنت
توفّر حِزم تطوير البرامج (SDK) في Firebase إمكانية الاحتفاظ بالبيانات بلا إنترنت. إذا لم يتمكّن التطبيق على جهاز المستخدم من الاتصال بـ Cloud Firestore، سيظل التطبيق قابلاً للاستخدام من خلال العمل مع البيانات المخزَّنة مؤقتًا على الجهاز. يضمن ذلك الوصول إلى البيانات حتى عندما يواجه المستخدمون اتصالات إنترنت متقطعة أو يفقدون الوصول تمامًا لعدة ساعات أو أيام. لمزيد من التفاصيل حول وضع عدم الاتصال بالإنترنت، يُرجى الاطّلاع على مقالة تفعيل البيانات غير الإلكترونية.
فهم عمليات إعادة المحاولة التلقائية
تتولى حزم تطوير البرامج (SDK) لمنصة Firebase إعادة محاولة تنفيذ العمليات وإعادة إنشاء الاتصالات المقطوعة. يساعد ذلك في حلّ الأخطاء المؤقتة الناتجة عن إعادة تشغيل الخوادم أو مشاكل الشبكة بين العميل وقاعدة البيانات.
الاختيار بين المواقع الجغرافية الإقليمية والمتعددة المناطق
هناك العديد من المفاضلات عند الاختيار بين المواقع الإقليمية والمواقع متعددة المناطق. ويكمن الاختلاف الرئيسي في كيفية نسخ البيانات. يؤدي ذلك إلى زيادة ضمانات توفّر تطبيقك. يوفّر المثيل المتعدّد المناطق موثوقية أكبر في العرض ويزيد من متانة بياناتك، ولكنّ المقابل هو التكلفة.
فهم نظام طلبات البحث في الوقت الفعلي
تتيح طلبات البحث في الوقت الفعلي، والتي تُعرف أيضًا باسم أدوات الاستماع إلى اللقطات، للتطبيق الاستماع إلى التغييرات في قاعدة البيانات والحصول على إشعارات بزمن انتقال منخفض فور تغيير البيانات. يمكن للتطبيق الحصول على النتيجة نفسها من خلال الاستعلام عن قاعدة البيانات بشكل دوري بحثًا عن التحديثات، ولكن غالبًا ما يكون ذلك أبطأ وأكثر تكلفة ويتطلب المزيد من الرموز البرمجية. للاطّلاع على أمثلة على كيفية إعداد طلبات البحث في الوقت الفعلي واستخدامها، يُرجى مراجعة الحصول على تحديثات في الوقت الفعلي. تتناول الأقسام التالية تفاصيل آلية عمل مستمعي اللقطات وتوضّح بعض أفضل الممارسات لتوسيع نطاق طلبات البحث في الوقت الفعلي مع الحفاظ على الأداء.
لنفترض أنّ مستخدمَين يتواصلان مع Cloud Firestore من خلال تطبيق مراسلة تم إنشاؤه باستخدام إحدى حِزم تطوير البرامج (SDK) للأجهزة الجوّالة.
يكتب العميل "أ" في قاعدة البيانات لإضافة مستندات وتعديلها في مجموعة
اسمها chatroom:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
يستمع العميل "ب" إلى التعديلات في المجموعة نفسها باستخدام أداة استماع إلى اللقطات. يتلقّى العميل "ب" إشعارًا فوريًا عندما ينشئ مستخدم رسالة جديدة. يوضّح المخطّط البياني التالي البنية الأساسية لمستمع اللقطات:
يحدث التسلسل التالي للأحداث عندما يربط العميل "ب" مستمع اللقطة بقاعدة البيانات:
- يفتح العميل "ب" اتصالاً بـ Cloud Firestore ويسجّل
مستمعًا من خلال إجراء مكالمة مع
onSnapshot(collection("chatroom"))من خلال حزمة تطوير البرامج (SDK) لمنصة Firebase. يمكن أن يظل هذا المستمع نشطًا لساعات. - تُرسل واجهة Cloud Firestore طلبات بحث إلى نظام التخزين الأساسي لإعداد مجموعة البيانات. ويحمّل مجموعة النتائج الكاملة للمستندات المطابقة. ونشير إلى ذلك باسم طلب بحث الاستطلاع. بعد ذلك، يقيّم النظام قواعد أمان Firebase لقاعدة البيانات للتأكّد من أنّ المستخدم يمكنه الوصول إلى هذه البيانات. إذا كان المستخدم مصرحًا له، فستقوم قاعدة البيانات بإرجاع البيانات إلى المستخدم.
- بعد ذلك، ينتقل طلب بحث العميل "ب" إلى وضع الاستماع. يتم تسجيل المستمع باستخدام معالج اشتراك وينتظر تحديثات البيانات.
- يرسل العميل "أ" الآن عملية كتابة لتعديل مستند.
- تُنفّذ قاعدة البيانات تغيير المستند في نظام التخزين الخاص بها.
- من ناحية المعاملات، يلتزم النظام بالتعديل نفسه في سجلّ التغييرات الداخلي. يحدّد سجلّ التغييرات ترتيبًا صارمًا للتغييرات حسب حدوثها.
- بدوره، يوزّع سجلّ التغييرات البيانات المعدَّلة على مجموعة من معالِجات الاشتراكات.
- يتم تنفيذ أداة مطابقة طلبات البحث العكسية لمعرفة ما إذا كان المستند المعدَّل يتطابق مع أي من أدوات معالجة اللقطات المسجَّلة حاليًا. في هذا المثال، يتطابق المستند مع أداة الاستماع إلى اللقطات الخاصة بالعميل "ب". كما يشير الاسم، يمكنك اعتبار مطابِق طلبات البحث العكسي كطلب بحث عادي في قاعدة البيانات ولكن يتم إجراؤه بشكل عكسي. بدلاً من البحث في المستندات للعثور على المستندات التي تتطابق مع طلب بحث، يبحث بكفاءة في طلبات البحث للعثور على المستندات التي تتطابق مع مستند وارد. عند العثور على تطابق، يعيد النظام توجيه المستند المعني إلى أدوات معالجة اللقطات. بعد ذلك، يقيّم النظام قواعد أمان Firebase لقاعدة البيانات لضمان عدم تلقّي البيانات إلا من قِبل المستخدمين المصرَّح لهم.
- يعيد النظام توجيه تعديل المستند إلى حزمة SDK على جهاز العميل "ب"، ويتم تفعيل دالة الاستدعاء
onSnapshot. في حال تفعيل ميزة "الاحتفاظ بالبيانات على الجهاز"، تطبّق حزمة تطوير البرامج (SDK) التعديل على ذاكرة التخزين المؤقت على الجهاز أيضًا.
يعتمد جزء رئيسي من قابلية توسّع Cloud Firestore على التوزيع من سجلّ التغييرات إلى معالِجات الاشتراكات وخوادم الواجهة الأمامية. يتيح الانتشار المتعدد إمكانية نشر تغيير واحد في البيانات بكفاءة لخدمة ملايين طلبات البحث في الوقت الفعلي والمستخدمين المتصلين. من خلال تشغيل العديد من النُسخ المتماثلة لكل هذه المكوّنات في مناطق متعددة (أو مناطق متعددة في حالة النشر في مناطق متعددة)، يحقق Cloud Firestore مستوى عالٍ من التوفّر وقابلية التوسع.
تجدر الإشارة إلى أنّ جميع عمليات القراءة الصادرة من حِزم تطوير البرامج (SDK) للأجهزة الجوّالة والويب تتّبع النموذج أعلاه. وتنفّذ طلب بحث استطلاعيًا يتبعه وضع الاستماع للحفاظ على ضمانات الاتساق. ينطبق ذلك أيضًا على المستمعين في الوقت الفعلي، وطلبات استرداد مستند، وطلبات البحث لمرة واحدة. يمكنك اعتبار عمليات استرداد المستندات الفردية وطلبات البحث لمرة واحدة بمثابة مستمعين للّقطات قصيرة الأجل، مع قيود مماثلة حول الأداء.
تطبيق أفضل الممارسات لتوسيع نطاق طلبات البحث في الوقت الفعلي
يمكنك تطبيق أفضل الممارسات التالية لتصميم طلبات بحث قابلة للتوسّع في الوقت الفعلي.
فهم معدّل الزيارات المرتفع في النظام
يساعدك هذا القسم في فهم كيفية استجابة النظام لعدد متزايد من طلبات الكتابة.
تتم زيادة سعة سجلّات التغييرات في Cloud Firestore التي تستند إليها طلبات البحث في الوقت الفعلي أفقيًا بشكل تلقائي مع زيادة عدد عمليات الكتابة. مع زيادة معدّل الكتابة في قاعدة البيانات بما يتجاوز قدرة الخادم الواحد، يتم تقسيم سجلّ التغييرات على خوادم متعددة، وتبدأ معالجة طلبات البحث في استهلاك البيانات من معالِجات اشتراكات متعددة بدلاً من معالِج واحد. من منظور العميل وحزمة تطوير البرامج (SDK)، كل هذه العمليات شفافة ولا تتطلّب اتّخاذ أي إجراء من التطبيق عند حدوث عمليات التقسيم. يوضّح المخطّط البياني التالي كيفية توسيع نطاق طلبات البحث في الوقت الفعلي:
يتيح لك التدرّج التلقائي زيادة عدد زيارات الكتابة بدون قيد، ولكن مع زيادة عدد الزيارات، قد يستغرق النظام بعض الوقت للاستجابة. اتّبِع اقتراحات قاعدة 5-5-5 لتجنُّب إنشاء نقطة اتصال للكتابة. Key Visualizer هي أداة مفيدة لتحليل نقاط الوصول الساخنة للكتابة.
تحقّق العديد من التطبيقات نموًا مجانيًا يمكن توقّعه، ويمكن لخدمة Cloud Firestore استيعابه بدون اتخاذ أي احتياطات. ومع ذلك، يمكن أن تؤدي أعباء العمل المجمّعة، مثل استيراد مجموعة بيانات كبيرة، إلى زيادة عمليات الكتابة بسرعة كبيرة. أثناء تصميم تطبيقك، يجب أن تكون على دراية بمصدر زيارات الكتابة.
فهم كيفية تفاعل عمليات الكتابة والقراءة
يمكنك اعتبار نظام طلبات البحث في الوقت الفعلي بمثابة مسار يربط بين عمليات الكتابة والقرّاء. في أي وقت يتم فيه إنشاء مستند أو تحديثه أو حذفه، ينتشر التغيير من نظام التخزين إلى المستمعين المسجلين حاليًا. تضمن بنية سجلّ التغييرات في "Cloud Firestore" الاتساق القوي، ما يعني أنّ تطبيقك لن يتلقّى أبدًا إشعارات بشأن التعديلات غير المتسلسلة مقارنةً بالوقت الذي نفّذت فيه قاعدة البيانات تغييرات البيانات. يؤدي ذلك إلى تبسيط عملية تطوير التطبيقات من خلال إزالة الحالات الاستثنائية المتعلقة باتساق البيانات.
يعني هذا المسار المتصل أنّ عملية الكتابة التي تتسبب في حدوث نقاط فعالة أو تنازع على القفل يمكن أن تؤثر سلبًا في عمليات القراءة. عندما تفشل عمليات الكتابة أو تواجه تقييدًا، قد تتوقف عملية القراءة في انتظار بيانات متسقة من سجل التغييرات. إذا حدث ذلك في تطبيقك، قد تلاحظ بطء عمليات الكتابة وبطء أوقات الاستجابة المرتبطة بها لطلبات البحث. يُعد تجنب النقاط الفعالة هو المفتاح لتجنب هذه المشكلة.
الحفاظ على صغر حجم المستندات وعمليات الكتابة
عند إنشاء تطبيقات باستخدام أدوات معالجة اللقطات، من المفترض أن تتيح للمستخدمين معرفة التغييرات في البيانات بسرعة. لتحقيق ذلك، حاوِل أن تكون التغييرات بسيطة. يمكن للنظام دفع المستندات الصغيرة التي تحتوي على عشرات الحقول من خلال النظام بسرعة كبيرة. تستغرق المستندات الأكبر حجمًا التي تحتوي على مئات الحقول والبيانات الكبيرة وقتًا أطول في المعالجة.
وبالمثل، يُفضَّل استخدام عمليات الإرسال والكتابة القصيرة والسريعة للحفاظ على انخفاض وقت الاستجابة. قد تمنحك الدفعات الكبيرة معدّل نقل بيانات أعلى من منظور الكاتب، ولكنّها قد تزيد من وقت الإشعار لمستمعي اللقطات. غالبًا ما يكون هذا غير بديهي مقارنةً باستخدام أنظمة قواعد البيانات الأخرى حيث يمكنك استخدام الدفعات لتحسين الأداء.
استخدام أدوات استماع فعّالة
مع زيادة معدلات الكتابة في قاعدة البيانات، يقسم Cloud Firestore معالجة البيانات عبر العديد من الخوادم. تحاول خوارزمية التقسيم في "Cloud Firestore" تجميع البيانات من المجموعة نفسها أو مجموعة المجموعات نفسها على خادم سجلّ التغييرات نفسه. يحاول النظام زيادة معدل نقل البيانات الممكنة إلى أقصى حد مع الحفاظ على عدد الخوادم المشاركة في معالجة الاستعلام منخفضًا قدر الإمكان.
ومع ذلك، قد تؤدي بعض الأنماط إلى سلوك غير مثالي لمستمعي اللقطات. على سبيل المثال، إذا كان تطبيقك يخزّن معظم بياناته في مجموعة واحدة كبيرة، قد يحتاج المستمع إلى الاتصال بالعديد من الخوادم لتلقّي جميع البيانات التي يحتاج إليها. وينطبق ذلك حتى في حال تطبيق فلتر لطلبات البحث. ويؤدي الاتصال بالعديد من الخوادم إلى زيادة خطر بطء الاستجابة.
لتجنُّب هذه الردود البطيئة، صمِّم المخطط والتطبيق بحيث يتمكّن النظام من خدمة المستمعين بدون الانتقال إلى العديد من الخوادم المختلفة. قد يكون من الأفضل تقسيم بياناتك إلى مجموعات أصغر بمعدلات كتابة أصغر.
يشبه هذا التفكير في طلبات البحث عن الأداء في قاعدة بيانات ارتباطية تتطلب عمليات فحص كاملة للجدول. في قاعدة البيانات الارتباطية، الاستعلام الذي يتطلب فحصًا كاملاً للجدول يعادل مستمع اللقطة الذي يراقب مجموعة عالية التغيير. وقد يكون أداؤه بطيئًا مقارنةً بطلب بحث يمكن لقاعدة البيانات عرضه باستخدام فهرس أكثر تحديدًا. الطلب الذي يتضمّن فهرسًا أكثر تحديدًا يشبه مستمع اللقطات الذي يراقب مستندًا واحدًا أو مجموعة تتغيّر بمعدّل أقل. يجب إجراء اختبار تحميل لتطبيقك من أجل فهم سلوك حالة الاستخدام واحتياجاتها بشكل أفضل.
الحفاظ على سرعة طلبات البحث المتكررة
هناك جزء رئيسي آخر من طلبات البحث في الوقت الفعلي سريعة الاستجابة يتضمن التأكد من أن طلب البحث عن البيانات سريع وفعال. في المرة الأولى التي يتصل فيها مستمع جديد للّقطات، يجب أن يحمّل المستمع مجموعة النتائج بأكملها ويرسلها إلى جهاز المستخدم. تؤدي طلبات البحث البطيئة إلى جعل تطبيقك أقل استجابة. ويشمل ذلك، على سبيل المثال، طلبات البحث التي تحاول قراءة العديد من المستندات أو طلبات البحث التي لا تستخدم الفهارس المناسبة.
وقد يعود المستمع أيضًا من حالة الاستماع إلى حالة الاستطلاع في ظل بعض الظروف. يحدث ذلك تلقائيًا وبشكل شفاف بالنسبة إلى حِزم تطوير البرامج (SDK) وتطبيقك. قد تؤدي الشروط التالية إلى تفعيل حالة الاستطلاع:
- يعيد النظام موازنة سجلّ التغييرات بسبب التغييرات في التحميل.
- تتسبب النقاط الفعالة في فشل عمليات الكتابة في قاعدة البيانات أو تأخيرها.
- تؤثر عمليات إعادة تشغيل الخادم العابرة مؤقتًا في المستمعين.
إذا كانت طلبات البحث عن حالة الاستطلاع سريعة بما يكفي، ستظهر حالة الاستطلاع لمستخدمي تطبيقك.
تفضيل متتبِّعات الأحداث الطويلة الأمد
إنّ فتح المستمعين وإبقائهم نشطين لأطول فترة ممكنة هو غالبًا الطريقة الأكثر فعالية من حيث التكلفة لإنشاء تطبيق يستخدم Cloud Firestore. عند استخدام Cloud Firestore، يتم تحصيل رسوم منك مقابل المستندات التي يتم عرضها في تطبيقك وليس مقابل الحفاظ على اتصال مفتوح. يقرأ مستمع اللقطات الطويل الأمد البيانات التي يحتاجها فقط لعرض طلب البحث طوال مدة صلاحيته. ويشمل ذلك عملية استطلاع أولية تليها إشعارات عند تغيير البيانات فعليًا. من ناحية أخرى، تعيد طلبات البحث لمرة واحدة قراءة البيانات التي قد لا تكون قد تغيرت منذ آخر مرة نفذ فيها التطبيق طلب البحث.
في الحالات التي يستهلك فيها تطبيقك معدّل بيانات مرتفعًا، قد لا تكون أدوات الاستماع إلى اللقطات مناسبة. على سبيل المثال، إذا كانت حالة الاستخدام لديك تتطلّب إرسال العديد من المستندات في الثانية عبر اتصال لفترة طويلة، قد يكون من الأفضل اختيار طلبات البحث لمرة واحدة التي يتم تشغيلها بمعدّل أقل.