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