يمكنك الاطّلاع على هذا المستند للحصول على إرشادات حول توسيع نطاق تطبيقك الذي لا يحتاج إلى خادم ليتجاوز آلاف العمليات في الثانية أو مئات الآلاف من المستخدمين المتزامنين. يتضمّن هذا المستند مواضيع متقدّمة لمساعدتك في فهم النظام بشكل معمّق. إذا كنت في مرحلة بدء استخدام 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'
يستمع العميل (ب) إلى التعديلات في المجموعة نفسها باستخدام أداة معالجة اللقطات. يتلقّى العميل (ب) إشعارًا فوريًا عندما ينشئ أحد المستخدمين رسالة جديدة. يوضّح المخطّط التالي بنية أداة معالجة اللقطات:
يحدث تسلسل الأحداث التالي عندما يربط العميل B أداة معالجة لقطة بقاعدة البيانات:
- يفتح العميل (ب) اتصالاً بـ Cloud Firestore ويسجّل أداة معالجة من خلال إجراء طلب إلى
onSnapshot(collection("chatroom"))عبر حزمة تطوير البرامج (SDK) لمنصة Firebase. ويمكن أن يبقى هذا المستمع نشطًا لساعات. - يطلب Cloud Firestore الواجهة الأمامية من نظام التخزين الأساسي تهيئة مجموعة البيانات. ويحمّل مجموعة النتائج الكاملة للمستندات المطابقة. نشير إلى ذلك باسم طلب بحث استقصائي. بعد ذلك، يقيّم النظام قواعد أمان Firebase الخاصة بقاعدة البيانات للتأكّد من أنّ المستخدم يمكنه الوصول إلى هذه البيانات. إذا كان المستخدم مخوَّلاً، ستعيد قاعدة البيانات البيانات إلى المستخدم.
- بعد ذلك، ينتقل طلب العميل (ب) إلى وضع الاستماع، حيث يسجّل المستمع لدى معالج الاشتراكات وينتظر تلقّي آخر التعديلات على البيانات.
- يرسل جهاز العميل أ الآن عملية كتابة لتعديل مستند.
- تلتزم قاعدة البيانات بتغيير المستند في نظام التخزين.
- يُجري النظام بشكل متزامن التعديل نفسه على سجلّ تغييرات داخلي، ويفرض سجلّ التغييرات ترتيبًا صارمًا على التغييرات عند حدوثها.
- بدوره، يوزّع سجلّ التغيير البيانات المعدَّلة على مجموعة من معالِجات الاشتراكات.
- يتم تنفيذ أداة مطابقة طلب البحث العكسي لمعرفة ما إذا كان المستند المعدَّل يطابق أيًا من أدوات الاستماع إلى اللقطات المسجّلة حاليًا. في هذا المثال، يطابق المستند أداة الاستماع إلى اللقطات الخاصة بالعميل (ب). وكما يوحي الاسم، يمكنك اعتبار أداة مطابقة طلب البحث العكسي بمثابة طلب بحث عادي في قاعدة البيانات ولكن يتم تنفيذه بشكل عكسي. فبدلاً من البحث في المستندات للعثور على تلك التي تطابق طلب بحث، تبحث الأداة بكفاءة في طلبات البحث للعثور على تلك التي تطابق مستندًا واردًا. وعند العثور على تطابق، يرسل النظام المستند المعنيّ إلى أدوات الاستماع إلى اللقطات. ثم يقيّم النظام قواعد أمان 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 وتطبيقك. وقد تؤدي الشروط التالية إلى بدء حالة الاستطلاع:
- يعيد النظام موازنة سجلّ التغيير بسبب التغييرات في الحمل.
- تتسبّب نقاط الاتصال في تعذّر الكتابة في قاعدة البيانات أو تأخّرها.
- تؤثر عمليات إعادة تشغيل الخادم العابرة مؤقتًا في المستمعين.
إذا كانت طلبات البحث التي يتم إرسالها بشكل متكرر سريعة بما يكفي، سيصبح حالة طلب البحث المتكرر غير مرئية لمستخدمي تطبيقك.
تفضيل أدوات معالجة الأحداث التي تدوم طويلاً
إنّ فتح أدوات معالجة البيانات وإبقائها نشطة لأطول فترة ممكنة هو غالبًا الطريقة الأكثر فعالية من حيث التكلفة لإنشاء تطبيق يستخدم Cloud Firestore. عند استخدام Cloud Firestore، يتم تحصيل رسوم منك مقابل المستندات التي يتم إرجاعها إلى تطبيقك وليس مقابل الحفاظ على اتصال مفتوح. تقرأ أداة معالجة البيانات التي تعمل لفترة طويلة لقطة البيانات التي تحتاجها فقط للرد على طلب البحث طوال مدة نشاطها. ويشمل ذلك عملية الاقتراع الأولية متبوعة بإشعارات عند تغيير البيانات فعليًا. من ناحية أخرى، تعيد طلبات البحث لمرة واحدة قراءة البيانات التي ربما لم تتغير منذ أن نفّذ التطبيق طلب البحث آخر مرة.
في الحالات التي يجب أن يستهلك فيها تطبيقك معدّل بيانات مرتفعًا، قد لا تكون أدوات معالجة اللقطات مناسبة. على سبيل المثال، إذا كانت حالة الاستخدام تتطلّب إرسال العديد من المستندات في الثانية الواحدة عبر اتصال لفترة زمنية طويلة، قد يكون من الأفضل اختيار طلبات بحث لمرة واحدة يتم تنفيذها بوتيرة أقل.