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