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