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