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