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