اقرأ هذا المستند للحصول على إرشادات حول توسيع نطاق تطبيقك بدون خادم بما يتجاوز آلاف العمليات في الثانية أو مئات الآلاف من المستخدمين المتزامنين. تتضمن هذه الوثيقة موضوعات متقدمة لمساعدتك على فهم النظام بعمق. إذا كنت قد بدأت للتو في استخدام Cloud Firestore، فراجع دليل البدء السريع بدلاً من ذلك.
يوفر Cloud Firestore وFirebase mobile/web SDK نموذجًا قويًا لتطوير التطبيقات بدون خادم حيث يصل الكود من جانب العميل إلى قاعدة البيانات مباشرة. تتيح مجموعات SDK للعملاء الاستماع إلى تحديثات البيانات في الوقت الفعلي. يمكنك استخدام التحديثات في الوقت الفعلي لإنشاء تطبيقات سريعة الاستجابة لا تتطلب بنية أساسية للخادم. على الرغم من أنه من السهل جدًا إعداد شيء ما وتشغيله، إلا أنه من المفيد فهم القيود الموجودة في الأنظمة التي تشكل Cloud Firestore بحيث يتوسع تطبيقك بدون خادم ويعمل بشكل جيد عند زيادة حركة المرور.
راجع الأقسام التالية للحصول على نصائح حول توسيع نطاق تطبيقك.
اختر موقع قاعدة بيانات قريب من المستخدمين لديك
يوضح الرسم البياني التالي بنية التطبيق في الوقت الفعلي:
عندما يقوم تطبيق يعمل على جهاز المستخدم (الجوال أو الويب) بإنشاء اتصال بـ Cloud Firestore، يتم توجيه الاتصال إلى خادم الواجهة الأمامية لـ Cloud Firestore في نفس المنطقة التي توجد بها قاعدة البيانات الخاصة بك. على سبيل المثال، إذا كانت قاعدة بياناتك موجودة في us-east1 ، فسينتقل الاتصال أيضًا إلى الواجهة الأمامية لـ Cloud Firestore أيضًا في us-east1 . هذه الاتصالات طويلة الأمد وتظل مفتوحة حتى يتم إغلاقها بشكل صريح بواسطة التطبيق. تقرأ الواجهة الأمامية البيانات من أنظمة تخزين Cloud Firestore الأساسية.
تؤثر المسافة بين الموقع الفعلي للمستخدم وموقع قاعدة بيانات Cloud Firestore على زمن الوصول الذي يواجهه المستخدم. على سبيل المثال، قد يجد المستخدم في الهند الذي يتصل تطبيقه بقاعدة بيانات في منطقة Google Cloud في أمريكا الشمالية أن التجربة أبطأ وأن التطبيق أقل سرعة مما لو كانت قاعدة البيانات موجودة في مكان أقرب بدلاً من ذلك، كما هو الحال في الهند أو في جزء آخر من آسيا .
تصميم للموثوقية
تعمل المواضيع التالية على تحسين موثوقية تطبيقك أو التأثير عليها:
تمكين وضع عدم الاتصال
توفر حزم Firebase SDK استمرارية البيانات في وضع عدم الاتصال. إذا لم يتمكن التطبيق الموجود على جهاز المستخدم من الاتصال بـ Cloud Firestore، فسيظل التطبيق قابلاً للاستخدام من خلال العمل مع البيانات المخزنة مؤقتًا محليًا. وهذا يضمن الوصول إلى البيانات حتى عندما يواجه المستخدمون اتصالات متقطعة بالإنترنت أو يفقدون الوصول تمامًا لعدة ساعات أو أيام. لمزيد من التفاصيل حول وضع عدم الاتصال، راجع تمكين البيانات دون اتصال .
فهم عمليات إعادة المحاولة التلقائية
تهتم حزم Firebase SDK بإعادة محاولة العمليات وإعادة إنشاء الاتصالات المعطلة. يساعد هذا في التغلب على الأخطاء العابرة الناتجة عن إعادة تشغيل الخوادم أو مشكلات الشبكة بين العميل وقاعدة البيانات.
اختر بين المواقع الإقليمية والمتعددة المناطق
هناك العديد من المقايضات عند الاختيار بين المواقع الإقليمية والمتعددة المناطق. والفرق الرئيسي هو كيفية نسخ البيانات. وهذا يقود إلى ضمانات توفر تطبيقك. يوفر المثيل متعدد المناطق موثوقية خدمة أقوى ويزيد من متانة بياناتك ولكن المقايضة لها تكلفة.
فهم نظام الاستعلام في الوقت الحقيقي
تتيح الاستعلامات في الوقت الفعلي، والتي تسمى أيضًا مستمعي اللقطات، للتطبيق الاستماع إلى التغييرات في قاعدة البيانات والحصول على إشعارات بزمن استجابة منخفض بمجرد تغيير البيانات. يمكن أن يحصل التطبيق على نفس النتيجة من خلال استطلاع قاعدة البيانات بشكل دوري بحثًا عن التحديثات، ولكنه غالبًا ما يكون أبطأ وأكثر تكلفة ويتطلب المزيد من التعليمات البرمجية. للحصول على أمثلة حول كيفية إعداد الاستعلامات في الوقت الفعلي واستخدامها، راجع الحصول على التحديثات في الوقت الفعلي . تتناول الأقسام التالية تفاصيل حول كيفية عمل مستمعي اللقطات وتصف بعضًا من أفضل الممارسات لتوسيع نطاق الاستعلامات في الوقت الفعلي مع الحفاظ على الأداء.
تخيل أن اثنين من المستخدمين يتصلان بـ Cloud Firestore من خلال تطبيق مراسلة تم إنشاؤه باستخدام إحدى مجموعات SDK للجوال.
يكتب العميل "أ" إلى قاعدة البيانات لإضافة المستندات وتحديثها في مجموعة تسمى chatroom :
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
يستمع العميل B إلى التحديثات في نفس المجموعة باستخدام مستمع اللقطات. يتلقى العميل "ب" إشعارًا فوريًا عندما يقوم شخص ما بإنشاء رسالة جديدة. يوضح الرسم البياني التالي البنية وراء مستمع اللقطة:
يحدث التسلسل التالي للأحداث عندما يقوم العميل B بتوصيل مستمع اللقطة إلى قاعدة البيانات:
- يفتح العميل B اتصالاً بـ Cloud Firestore ويسجل المستمع عن طريق إجراء مكالمة إلى
onSnapshot(collection("chatroom"))من خلال Firebase SDK. يمكن لهذا المستمع أن يظل نشطًا لساعات. - تستعلم الواجهة الأمامية لـ Cloud Firestore عن نظام التخزين الأساسي لتشغيل مجموعة البيانات. يقوم بتحميل مجموعة النتائج الكاملة للمستندات المطابقة. ونحن نشير إلى هذا باعتباره استعلام الاقتراع . يقوم النظام بعد ذلك بتقييم قواعد أمان Firebase لقاعدة البيانات للتحقق من إمكانية وصول المستخدم إلى هذه البيانات. إذا تم ترخيص المستخدم، تقوم قاعدة البيانات بإرجاع البيانات إلى المستخدم.
- ثم ينتقل استعلام العميل B إلى وضع الاستماع . يقوم المستمع بالتسجيل مع معالج الاشتراك وينتظر تحديثات البيانات.
- يرسل العميل A الآن عملية كتابة لتعديل مستند.
- تقوم قاعدة البيانات بتنفيذ تغيير المستند إلى نظام التخزين الخاص بها.
- ومن الناحية المعاملاتية، يقوم النظام بتنفيذ نفس التحديث لسجل التغيير الداخلي. ينشئ سجل التغيير ترتيبًا صارمًا للتغييرات عند حدوثها.
- يقوم سجل التغيير بدوره بنشر البيانات المحدثة إلى مجموعة من معالجات الاشتراك.
- يتم تنفيذ أداة مطابقة الاستعلام العكسي لمعرفة ما إذا كان المستند المحدث يطابق أي مستمعي لقطة مسجلين حاليًا. في هذا المثال، يتطابق المستند مع مستمع اللقطة الخاص بالعميل B. كما يوحي الاسم، يمكنك التفكير في مُطابق الاستعلام العكسي باعتباره استعلامًا عاديًا لقاعدة البيانات ولكن يتم إجراؤه بشكل عكسي. بدلاً من البحث في المستندات للعثور على تلك التي تطابق استعلامًا، فإنه يبحث بكفاءة من خلال الاستعلامات للعثور على تلك التي تطابق مستندًا واردًا. عند العثور على تطابق، يقوم النظام بإعادة توجيه المستند المعني إلى مستمعي اللقطة. ثم يقوم النظام بتقييم قواعد أمان 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، تتم محاسبتك على المستندات التي يتم إرجاعها إلى تطبيقك وليس مقابل الحفاظ على اتصال مفتوح. يقرأ مستمع اللقطات طويل الأمد فقط البيانات التي يحتاجها لخدمة الاستعلام طوال عمره. يتضمن ذلك عملية استقصاء أولية متبوعة بإشعارات عندما تتغير البيانات فعليًا. من ناحية أخرى، تعيد الاستعلامات أحادية اللقطة قراءة البيانات التي ربما لم تتغير منذ آخر مرة قام فيها التطبيق بتنفيذ الاستعلام.
في الحالات التي يجب أن يستهلك فيها تطبيقك معدلًا مرتفعًا من البيانات، قد لا يكون مستمعو اللقطات مناسبين. على سبيل المثال، إذا كانت حالة الاستخدام الخاصة بك تدفع العديد من المستندات في الثانية عبر اتصال لفترة زمنية ممتدة، فقد يكون من الأفضل اختيار الاستعلامات الفردية التي يتم تشغيلها بتردد أقل.
ماذا بعد
- تعرف على كيفية استخدام مستمعي اللقطات .
- اقرأ المزيد عن أفضل الممارسات .