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