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