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