فهم عمليات القراءة والكتابة على نطاق واسع

اقرأ هذا المستند لاتخاذ قرارات مستنيرة بشأن تصميم بنية تطبيقاتك للحصول على أداء عالي وموثوقية عالية. يتضمن هذا المستند مواضيع Cloud Firestore متقدمة. إذا كنت قد بدأت للتو في Cloud Firestore، يُرجى الاطّلاع على دليل البدء السريع بدلاً من ذلك.

Cloud Firestore هي قاعدة بيانات مرنة وقابلة للتوسّع وتطوير الأجهزة الجوّالة والويب والخوادم من Firebase وGoogle Cloud. من السهل جدًا بدء استخدام Cloud Firestore وكتابة تطبيقات غنية وفعّالة.

للتأكّد من أنّ أداء تطبيقاتك لا يزال جيدًا مثل حجم قاعدة البيانات وزيادة عدد الزيارات، يساعد ذلك في التعرّف على آليات عمليتي القراءة والكتابة في الواجهة الخلفية Cloud Firestore. يجب عليك أيضًا فهم تفاعل القراءة والكتابة مع طبقة التخزين والقيود الأساسية التي قد تؤثر على الأداء.

يمكنك الاطّلاع على الأقسام التالية لمعرفة أفضل الممارسات قبل تصميم بنية تطبيقك.

فهم المكونات عالية المستوى

يوضِّح المخطّط التالي المكوّنات عالية المستوى المضمَّنة في طلب البيانات من واجهة برمجة التطبيقات Cloud Firestore.

حزمتا تطوير البرامج (SDK) ومكتبتا البرامج (Cloud Firestore)

يتوافق "Cloud Firestore" مع حِزم تطوير البرامج (SDK) ومكتبات العملاء للأنظمة الأساسية المختلفة. على الرغم من أنّه يمكن للتطبيق إرسال طلبات HTTP وRPC مباشرةً إلى واجهة برمجة التطبيقات Cloud Firestore، إلا أنّ مكتبات العملاء توفر طبقة تجريد لتبسيط استخدام واجهة برمجة التطبيقات وتنفيذ أفضل الممارسات. وقد توفِّر أيضًا ميزات إضافية، مثل الوصول بلا إنترنت وذاكرات التخزين المؤقّت وما إلى ذلك.

واجهة Google الأمامية (GFE)

تعتبر هذه خدمة بنية أساسية مشتركة بين جميع خدمات السحابة الإلكترونية من Google. يقبل Google for Education الطلبات الواردة ويعيد توجيهها إلى خدمة Google ذات الصلة (خدمة Cloud Firestore في هذا السياق). ويوفر وظائف مهمة أخرى، بما في ذلك الحماية من هجمات الحرمان من الخدمة.

خدمة واحدة (Cloud Firestore)

تُجري خدمة Cloud Firestore عمليات تحقُّق على طلب البيانات من واجهة برمجة التطبيقات، وتتضمّن عمليات المصادقة والتفويض وعمليات التحقّق من الحصة وقواعد الأمان، وتدير أيضًا المعاملات. تتضمّن خدمة Cloud Firestore برنامج تخزين يتفاعل مع طبقة التخزين لعمليات قراءة البيانات وكتابتها.

طبقة تخزين واحدة (Cloud Firestore)

تكون طبقة التخزين Cloud Firestore مسؤولة عن تخزين كل من البيانات والبيانات الوصفية وميزات قاعدة البيانات المرتبطة التي يوفّرها Cloud Firestore. توضّح الأقسام التالية طريقة تنظيم البيانات في طبقة التخزين في Cloud Firestore وكيفية قياس النظام. يمكن أن يساعدك التعرّف على كيفية تنظيم البيانات في تصميم نموذج بيانات قابل للتوسّع وفهم أفضل الممارسات في Cloud Firestore بشكل أفضل.

النطاقات الرئيسية والتقسيمات

Cloud Firestore هي قاعدة بيانات NoSQL موجهة نحو المستندات. يمكنك تخزين البيانات في المستندات، والتي يتم تنظيمها في تدرّجات هرمية للمجموعات. تتم ترجمة التسلسل الهرمي للمجموعات ورقم تعريف المستند إلى مفتاح واحد لكل مستند. يتم تخزين المستندات وترتيبها منطقيًا من خلال هذا المفتاح الفردي. نستخدم مصطلح "نطاق مفاتيح" للإشارة إلى نطاق مفاتيح متجاورة من الناحية اللغوية.

قاعدة بيانات Cloud Firestore النموذجية كبيرة جدًا بحيث لا يمكن احتواؤها على جهاز فعلي واحد. هناك أيضًا سيناريوهات يكون فيها أعباء العمل على البيانات ثقيلًا جدًا بحيث لا يمكن لأحد الأجهزة التعامل معها. للتعامل مع أعباء العمل الكبيرة، يقسّم Cloud Firestore البيانات إلى أجزاء منفصلة يمكن تخزينها عليها وعرضها من أجهزة متعدّدة أو من خوادم تخزين. يتم إنشاء هذه الأقسام في جداول قاعدة البيانات على شكل كتل من النطاقات الرئيسية تُسمى التقسيمات.

نقطة رئيسية: من المهم فهم كيفية إدارة Cloud Firestore للنطاقات الرئيسية والأقسام لإنشاء نماذج بيانات قابلة للتوسّع.

النسخ المتزامن

من المهم ملاحظة أن قاعدة البيانات يتم دائمًا نسخها تلقائيًا وبشكل متزامن. تشتمل تقسيمات البيانات على نُسخ مكررة في مناطق مختلفة، ما يتيح لك الاحتفاظ بها حتى عندما يتعذّر الوصول إلى إحدى المناطق. تتم إدارة النسخ المتماثل للنُسخ المختلفة من التقسيم بواسطة خوارزمية Paxos للحصول على الإجماع. يتم اختيار نسخة واحدة طبق الأصل من كل قسم لتكون بمثابة قائد باكسوس، المسؤول عن التعامل مع عمليات الكتابة لهذا التقسيم. يتيح لك النسخ المتزامن قراءة أحدث نسخة من البيانات من Cloud Firestore بشكل دائم.

والنتيجة الإجمالية لهذا النظام هي استخدام نظام قابل للتطوير ومتاح بدرجة كبيرة ويوفر أوقات استجابة منخفضة لكلٍّ من عمليتَي القراءة والكتابة، بغض النظر عن أعباء العمل الثقيلة وعلى نطاق واسع جدًا.

نقطة رئيسية: من المهم فهم كيفية إدارة Cloud Firestore للنسخ المتماثل من أجل فهم اتّساق Cloud Firestore ومدى توفّره وموثوقيتها.

تخطيط البيانات

Cloud Firestore هي قاعدة بيانات لمستندات غير مخططة. ومع ذلك، فإنها تحدد البيانات داخليًا بشكل أساسي في جدولين مرتبطين بنمط قاعدة البيانات في طبقة التخزين الخاصة بها على النحو التالي:

• جدول المستندات: يتم تخزين المستندات في هذا الجدول.
• جدول الفهارس: يُخزّن هذا الجدول إدخالات الفهرس التي تتيح الحصول على النتائج بكفاءة ويتم ترتيبها حسب قيمة الفهرس.

يوضّح المخطّط التالي شكل الجداول في قاعدة بيانات Cloud Firestore باستخدام التقسيمات. يتم نسخ التقسيمات في ثلاث مناطق مختلفة، ولكل قسمة قائد باكسوس.

منطقة واحدة مقابل مناطق متعددة

عند إنشاء قاعدة بيانات، عليك اختيار منطقة أو مناطق متعددة.

الموقع الجغرافي الواحد هو موقع جغرافي محدّد، مثل us-west1. تشتمل تقسيمات بيانات قاعدة بيانات Cloud Firestore على نسخ مطابِقة في مناطق مختلفة داخل المنطقة المحددة، كما هو موضّح سابقًا.

يتكون الموقع المتعدد المناطق من مجموعة محددة من المناطق التي يتم فيها تخزين نُسخ مكررة من قاعدة البيانات. في عملية نشر Cloud Firestore على مستوى عدة مناطق، تمتلك اثنتان من المنطقتين نُسخًا مطابقة كاملة للبيانات الكاملة في قاعدة البيانات. تمتلك منطقة ثالثة نسخة طبق الأصل من شاهد لا تحتفظ بمجموعة كاملة من البيانات، ولكنّها تشارك في النسخ. من خلال تكرار البيانات بين مناطق متعددة، تتوفر البيانات لتتم كتابتها وقراءتها حتى في حال فقدان منطقة بأكملها.

لمزيد من المعلومات عن المواقع الجغرافية لمنطقة معيّنة، يُرجى الاطّلاع على Cloud Firestore موقع جغرافي.

نقطة رئيسية: يؤدي الاختيار بين إعدادات منطقة واحدة مقابل الإعدادات المتعددة المناطق إلى نتائج مقايضة بين مستوى الأداء ومدى التوفّر والتكلفة.

التعرّف على حياة الكتابة في Cloud Firestore

يمكن لبرنامج Cloud Firestore كتابة البيانات من خلال إنشاء مستند واحد أو تعديله أو حذفه. تتطلب الكتابة على مستند واحد تحديث كل من المستند وإدخالات الفهرس المرتبطة به بشكل ذري في طبقة التخزين. يتيح Cloud Firestore أيضًا العمليات الذرية التي تشمل عدة عمليات قراءة و/أو كتابة في مستند واحد أو أكثر.

بالنسبة إلى جميع أنواع عمليات الكتابة، يوفّر Cloud Firestore سمات ACID (الذرّية والاتساق والعزل والمتانة) لقواعد البيانات الارتباطية. يوفّر Cloud Firestore أيضًا قابلية التسلسل، ما يعني أن جميع المعاملات تظهر كما لو تم تنفيذها بترتيب تسلسلي.

خطوات عالية المستوى في معاملة كتابة

عندما يصدر عميل Cloud Firestore عملية كتابة أو تنفيذ معاملة باستخدام أي من الطرق المذكورة سابقًا، يتم تنفيذ ذلك داخليًا على أنّه معاملة قراءة وكتابة قاعدة بيانات في طبقة التخزين. تتيح هذه المعاملة لـ "Cloud Firestore" تقديم سمات ACID المذكورة سابقًا.

كخطوة أولى من المعاملة، يقرأ Cloud Firestore المستند الحالي ويحدّد التغييرات التي سيتم إجراؤها على البيانات في جدول "المستندات".

ويشمل ذلك أيضًا إجراء التعديلات اللازمة على جدول "المؤشرات" على النحو التالي:

• يجب إدراج الحقول التي تتم إضافتها إلى المستندات في جدول الفهارس.
• يجب حذف الحقول التي تتم إزالتها من المستندات في جدول "الفهرس".
• تحتاج الحقول التي يتم تعديلها في المستندات إلى عمليات الحذف (للقيم القديمة) والإدراجات (للقيم الجديدة) في جدول الفهارس.

لاحتساب التغييرات المذكورة سابقًا، يقرأ Cloud Firestore إعدادات الفهرسة للمشروع. تخزِّن إعدادات الفهرسة معلومات عن الفهارس الخاصة بمشروع معيّن. تستخدم Cloud Firestore نوعين من الفهارس: حقل واحد ومركّب. للحصول على معلومات تفصيلية عن الفهارس التي تم إنشاؤها في Cloud Firestore، يُرجى الاطّلاع على أنواع الفهارس في Cloud Firestore.

بعد احتساب التغييرات، يجمعها Cloud Firestore داخل معاملة، ثم ينفّذها.

نقطة رئيسية: Cloud Firestore يستخدم دومًا المعاملات داخليًا لتوفير خصائص ACID لعمليات الكتابة.

فهم معاملة الكتابة في طبقة التخزين

كما ناقشنا سابقًا، تتضمن الكتابة في Cloud Firestore معاملة قراءة وكتابة في طبقة التخزين. اعتمادًا على تنسيق البيانات، قد تتضمّن عملية الكتابة تقسيمًا واحدًا أو أكثر كما هو موضّح في تنسيق البيانات.

في المخطّط البياني التالي، تتضمّن قاعدة بيانات Cloud Firestore ثمانية أقسام (تم وضع علامة من 1 إلى 8) عليها على ثلاثة خوادم تخزين مختلفة في منطقة واحدة، ويتم نسخ كل قسم في 3 مناطق مختلفة. لكل قسمة قائد Paxos، والذي قد يكون في منطقة مختلفة لأقسام مختلفة.

تقسيم قاعدة بيانات Cloud Firestore">

يمكنك استخدام قاعدة بيانات Cloud Firestore تتضمّن المجموعة Restaurants على النحو التالي:

يطلب عميل Cloud Firestore إجراء التغيير التالي على مستند في مجموعة Restaurant من خلال تعديل قيمة الحقل priceCategory.

تصف الخطوات عالية المستوى التالية ما يحدث كجزء من الكتابة:

1. إنشاء معاملة للقراءة والكتابة
2. اقرأ مستند restaurant1 في مجموعة Restaurants من جدول المستندات من طبقة التخزين.
3. اقرأ فهارس المستند من جدول الفهارس.
4. حساب الطفرات التي سيتم إجراؤها على البيانات. في هذه الحالة، هناك خمس طفرات:
   • M1: عدِّل صف restaurant1 في جدول المستندات لإظهار التغيير في قيمة الحقل priceCategory.
   • M2 وM3: احذف صفوف القيمة القديمة لـ priceCategory في جدول الفهارس للفهارس التنازلية والتصاعدية.
   • M4 وM5: أدرِج صفوف القيمة الجديدة priceCategory في جدول الفهارس للفهارس التنازلية والتصاعدية.
5. تنفيذ هذه التغييرات

يبحث برنامج التخزين في خدمة Cloud Firestore عن الأقسام التي تملك مفاتيح الصفوف المطلوب تغييرها. لنلقِ نظرة على الحالة التي يعرض فيها القسم 3 M1 والقسم 6 على M2-M5. هناك معاملة موزَّعة تتضمّن كل هذه التقسيمات كمشاركين. قد تتضمن تقسيمات المشاركين أيضًا أي قسم آخر تمت قراءة البيانات منه سابقًا كجزء من معاملة القراءة والكتابة.

تصف الخطوات التالية ما يحدث كجزء من الالتزام:

1. يصدر عميل مساحة التخزين التزامًا. يحتوي التنفيذ على الطفرات M1-M5.
2. في هذه المعاملة، يتم تقسيم المبلغين 3 و6. يتم اختيار أحد المشاركين كمنسّق، مثل التقسيم 3. وتتمثل وظيفة المنسق في التأكد من تنفيذ المعاملة أو إلغاؤها تمامًا عبر جميع المشاركين.
   • النسخ المكررة للقائد من هذه التقسيمات هي المسؤولة عن العمل الذي يقوم به المشاركون والمنسقون.
3. يدير كل مشارك ومنسق خوارزمية Paxos مع النسخ المتماثلة الخاصة بها.
   • يدير القائد خوارزمية Paxos مع النسخ المكررة. يتحقق النصاب إذا ردت معظم النسخ المكررة برد ok to commit للقائد.
   • بعد ذلك، يرسل كل مشارك إشعارًا إلى المنسّق عندما يكون جاهزًا (المرحلة الأولى من الالتزام على مرحلتين). في حال لم يتمكّن أي مشارك من إتمام المعاملة، يتم تحصيل aborts المعاملة بالكامل.
4. وعندما يعلم المنسِّق أنّ جميع المشاركين، بما فيهم نفسه، مستعدّون، يُبلغ جميع المشاركين بنتيجة معاملة accept (المرحلة الثانية من الالتزام على مرحلتين). في هذه المرحلة، يسجل كل مشارك قرار الالتزام بمساحة تخزين ثابتة ويتم الالتزام بالمعاملة.
5. يردّ المنسّق على عميل مساحة التخزين في Cloud Firestore بأنّه تم إكمال المعاملة. بالتوازي، يقوم المنسق وجميع المشاركين بتطبيق الطفرات على البيانات.

عندما تكون قاعدة بيانات Cloud Firestore صغيرة، قد يمتلك قسم واحد جميع المفاتيح الناتجة عن التغييرات M1-M5. في هذه الحالة، يكون هناك مشارك واحد فقط في العملية ولا يلزم الالتزام بالمرحلتين السابق ذكره، ما يؤدي إلى زيادة سرعة عمليات الكتابة.

الكتابة بلغات متعددة

في عملية النشر على مستوى عدة مناطق، يؤدي انتشار النُسخ المتماثلة في جميع المناطق إلى زيادة مدى توفُّرها، ولكن سيؤدّي ذلك إلى زيادة التكلفة. يستغرق الاتصال بين النسخ المكررة في المناطق المختلفة أوقات رحلات ذهاب وعودة أطول. وبالتالي، يكون وقت الاستجابة الأساسي لعمليات النشر في Cloud Firestore أكبر قليلاً مقارنةً بعمليات النشر في منطقة واحدة.

نحن نهيئ النسخ المماثلة بطريقة تجعل قيادة الانقسامات دائمًا في المنطقة الأساسية. المنطقة الأساسية هي المنطقة التي تأتي منها الزيارات إلى خادم Cloud Firestore. يؤدي قرار القيادة هذا إلى الحدّ من تأخير إرسال البيانات واستقبالها في الاتصال بين عميل التخزين في Cloud Firestore وقائد النسخة التجريبية (أو منسّق المعاملات المتعدّدة التقسيمات).

تتضمّن كل عملية كتابة في Cloud Firestore أيضًا بعض التفاعل مع محرّك البحث في الوقت الفعلي في Cloud Firestore. لمزيد من المعلومات عن طلبات البحث في الوقت الفعلي، يمكنك الاطّلاع على مقالة فهم طلبات البحث في الوقت الفعلي على نطاق واسع.

نقطة رئيسية: يستخدم تطبيق "Cloud Firestore" المعاملات لإجراء عمليات الكتابة، ما يتطلّب الحصول على أقفال مشترَكة للقراءة وقفل حصرية للكتابة. عندما تقرأ المعاملة العديد من الصفوف، لا يمكن لأي معاملة أخرى الكتابة إلى هذه المجموعة من الصفوف حتى يتم تنفيذ هذه المعاملة أو إيقافها، ما يؤدي إلى زيادة وقت الاستجابة و/أو حدوث أخطاء في المنافسة. لذلك، ننصحك بتجنّب إجراء عمليات قراءة كبيرة داخل المعاملة.

نقطة رئيسية: يزداد وقت استجابة الكتابة/المعاملات مع زيادة عدد الأقسام/المشاركين. لا توجد آلية واضحة للتحكم في عدد المشاركين. ومع ذلك، يمكنك إجراء ما يلي لتقليل عدد المشاركين:

• يحدث توزيع الفهرس المرتفع عندما يلزم كتابة العديد من إدخالات الفهرس. يؤدي توزيع الفهرس المرتفع لكتابة مستند إلى زيادة عدد صفوف قاعدة البيانات التي سيتم تبديلها، مما يزيد من عدد المشاركين. إيقاف فهرسة الحقول غير المستخدمة في طلبات البحث بشكل صريح.
• يزداد عدد المشاركين مع زيادة عدد المستندات التي تم تحديثها في معاملة الكتابة. لوقت استجابة أقل، ننصحك بإبقاء عدد المستندات محدّثة في عملية كتابة واحدة منخفضًا.

التعرّف على حياة القراءة في Cloud Firestore

يتناول هذا القسم القراءات المستقلة التي لا يتم عرضها في الوقت الفعلي باللغة Cloud Firestore. ويعالج خادم Cloud Firestore داخليًا معظم طلبات البحث هذه في مرحلتَين رئيسيتَين:

1. فحص نطاق واحد على جدول المؤشرات
2. عمليات البحث عن النقاط في جدول المستندات استنادًا إلى نتيجة الفحص السابق

قد تكون هناك طلبات بحث معيّنة تتطلّب معالجة أقل أو معالجة إضافية (على سبيل المثال، طلبات بحث IN) في Cloud Firestore.

تتم قراءات البيانات من طبقة التخزين داخليًا باستخدام معاملة قاعدة بيانات لضمان عمليات قراءة متسقة. ومع ذلك، على عكس المعاملات المستخدمة في عمليات الكتابة، لا تستخدم هذه المعاملات قفلاً. وإنما تعمل عن طريق اختيار طابع زمني ثم تنفيذ جميع عمليات القراءة عند ذلك الطابع الزمني. ولأنها لا تكتسب أقفالاً، فإنها لا تحظر معاملات القراءة والكتابة المتزامنة. لتنفيذ هذه المعاملة، يحدّد برنامج مساحة التخزين في Cloud Firestore طابعًا زمنيًا مرتبطًا بطابع زمني يحدّد لطبقة التخزين كيفية اختيار طابع زمني للقراءة. تحدّد خيارات القراءة لطلب القراءة نوع الطابع الزمني المرتبط الذي يختاره برنامج مساحة التخزين في Cloud Firestore.

فهم معاملة القراءة في طبقة التخزين

يوضِّح هذا القسم أنواع القراءات وكيفية معالجتها في طبقة التخزين في Cloud Firestore.

قراءات قوية

بشكل افتراضي، تكون القراءات Cloud Firestore متسقة إلى حد كبير. ويعني هذا الاتساق القوي أنّ القراءة Cloud Firestore تعرض أحدث نسخة من البيانات التي تعكس جميع عمليات الكتابة التي تم الالتزام بها حتى بداية القراءة.

قراءة مقسَّمة واحدة

يبحث برنامج مساحة التخزين في Cloud Firestore عن الأقسام التي تملك مفاتيح الصفوف المراد قراءتها. لنفترض أنّه يجب قراءة المحتوى من القسم 3 من القسم السابق. يرسل العميل طلب القراءة إلى أقرب نسخة مطابقة لتقليل وقت الاستجابة للإرسال والاستقبال.

في هذه المرحلة، قد تحدث الحالات التالية اعتمادًا على النسخة المطابقة المحددة:

• ينتقل طلب القراءة إلى نسخة مطابقة للقائد (المنطقة أ).
  • وحيث إن القائد محدّث دائمًا، يمكن متابعة القراءة مباشرةً.
• ينتقل طلب القراءة إلى نسخة مطابقة لعنصر غير قائد (مثل المنطقة "ب")
  • قد يعرف التقسيم 3 حسب حالته الداخلية أنه يحتوي على معلومات كافية لعرض القراءة ويكون التقسيم كذلك.
  • القسم 3 غير متأكّد مما إذا كان قد تم عرض أحدث البيانات منه. وتُرسل رسالة إلى المسؤول لطلب الطابع الزمني لآخر معاملة يحتاج إلى تطبيقها لعرض القراءة. وبعد تطبيق هذه المعاملة، يمكن متابعة القراءة.

بعد ذلك، تعرض الدالة Cloud Firestore الردّ إلى العميل.

قراءة متعددة الانقسام

وفي الحالة التي يجب فيها إجراء عمليات القراءة من عدة أقسام، تحدث الآلية نفسها في جميع الأقسام. بعد عرض البيانات من كل التقسيمات، يجمع برنامج التخزين في Cloud Firestore النتائج. بعد ذلك، يستجيب Cloud Firestore لعميله بهذه البيانات.

نقطة رئيسية: يزداد وقت الاستجابة مع زيادة عدد التقسيمات التي تحدث في القراءة. يمكن أن يؤدي إبقاء استعلاماتك المجموعات الصغيرة كلما أمكن ذلك.

قراءات قديمة

إنّ القراءات القوية هي الوضع التلقائي في Cloud Firestore. ومع ذلك، فإنّها تترتّب وقت استجابة أطول بسبب التواصل الذي قد يكون مطلوبًا مع القائد. غالبًا ما لا يحتاج تطبيق Cloud Firestore إلى قراءة أحدث إصدار من البيانات، حيث تعمل الوظائف بشكل جيد مع البيانات التي قد يستغرق ظهورها بضع ثوانٍ.

في هذه الحالة، قد يختار العميل تلقّي قراءات قديمة باستخدام خيارات القراءة read_time. في هذه الحالة، تتم عمليات القراءة على النحو الذي كانت عليه البيانات في read_time، ومن المرجّح جدًا أن تكون أقرب نسخة مطابقة قد تحقّقت من احتواء البيانات على بيانات على النطاق read_time المحدَّد. ولتحقيق أداء أفضل بشكل ملحوظ، تُعتبر 15 ثانية قيمة قديمة ومعقولة. حتى بالنسبة إلى القراءات القديمة، فإن الصفوف التي تم الحصول عليها متسقة مع بعضها البعض.

نقطة رئيسية: تضمن القراءات القوية الاطّلاع على أحدث البيانات. ومع ذلك، قد ينتج عن ذلك عبء وقت الاستجابة الإضافي ذهابًا وإيابًا لنسخة طبق الأصل التي تحتاج إلى التواصل مع القائد، وقد تضطر أيضًا إلى الانتظار إلى أن يتم تطبيق معاملات الكتابة. لتحقيق أداء أفضل، استخدِم القراءات التي تسمح بإرجاع البيانات القديمة.

تجنُّب نقاط الاتصال

يتم تقسيم الأجزاء في Cloud Firestore تلقائيًا إلى أجزاء أصغر لتوزيع عملية نقل الزيارات على المزيد من خوادم التخزين عند الحاجة أو عند توسيع المساحة الرئيسية. يتم الاحتفاظ بالأقسام التي تم إنشاؤها لمعالجة عدد الزيارات الزائد لمدة 24 ساعة تقريبًا، حتى في حال انخفاض عدد الزيارات. لذلك في حال حدوث ارتفاعات متكررة في عدد الزيارات، يتم الحفاظ على التقسيمات ويتم تطبيق المزيد من التقسيمات متى لزم الأمر. تساعد هذه الآليات قواعد بيانات Cloud Firestore على التحسين التلقائي مع زيادة حِمل حركة البيانات أو حجم قاعدة البيانات. ومع ذلك، هناك بعض القيود التي يجب معرفتها كما هو موضّح أدناه.

يستغرق تقسيم مساحة التخزين والتحميل بعض الوقت، وقد تؤدي زيادة حركة البيانات بشكل سريع جدًا إلى حدوث أخطاء في وقت الاستجابة أو تجاوز الموعد النهائي، ويُشار إليها عادةً باسم نقاط الاتصال أثناء ضبط الخدمة. من أفضل الممارسات توزيع العمليات عبر النطاق الرئيسي، مع زيادة حركة البيانات على مجموعة في قاعدة بيانات تتضمن 500 عملية في الثانية. وبعد هذا التحسين التدريجي، يمكنك زيادة عدد الزيارات بنسبة تصل إلى 50% كل خمس دقائق. تُعرف هذه العملية باسم القاعدة 500/50/5، وهي تحدّد موضع قاعدة البيانات لتوسيع نطاقها على النحو الأمثل لتلبية أعباء العمل.

نقطة رئيسية: يجب زيادة عدد الزيارات باتّباع القاعدة 500/50/5 لتحقيق أفضل توسيع نطاق.

على الرغم من أنّه يتم إنشاء التقسيمات تلقائيًا مع زيادة التحميل، يمكن لـ Cloud Firestore تقسيم نطاق رئيسي فقط إلى أن يعرض مستندًا واحدًا باستخدام مجموعة مخصّصة من خوادم التخزين المنسوخة. نتيجةً لذلك، قد تؤدي عمليات التشغيل المتزامنة الكبيرة والمستمرة على مستند واحد إلى نقطة اتصال على ذلك المستند. إذا واجهت فترات استجابة طويلة مستمرة في مستند واحد، يجب تعديل نموذج البيانات لتقسيم البيانات أو تكرارها على عدة مستندات.

تحدث أخطاء التضارب عندما تحاول عمليات متعددة قراءة و/أو كتابة نفس المستند في وقت واحد.

نقطة رئيسية: تجنَّب المعدّلات العالية لقراءة أو كتابة مستند واحد أو المستندات في نطاق رئيسي يحتوي على بعض المستندات، وإلّا سيواجه تطبيقك أخطاء وقت استجابة و/أو تعارض عالية.

هناك حالة خاصة أخرى من نقاط الاتصال تحدث عند استخدام مفتاح زيادة/خفض بشكل تسلسلي كرقم تعريف المستند في Cloud Firestore، وهناك عدد كبير جدًا من العمليات في الثانية. فإنشاء المزيد من التقسيمات لا يفيد هنا؛ لأن زيادة عدد الزيارات تنتقل ببساطة إلى التقسيم الذي تم إنشاؤه حديثًا. وبما أنّ Cloud Firestore يفهرس جميع الحقول في المستند تلقائيًا، قد يتم أيضًا إنشاء نقاط الاتصال المتحركة هذه على مساحة الفهرس لحقل مستند يحتوي على قيمة تتزايد أو تنخفض بشكل تسلسلي مثل طابع زمني.

نقطة رئيسية: تجنَّب إنشاء المستندات بمعدل مرتفع مع تخصيص معرّفات المستندات التي تزيد أو تقل بشكل رتيب لأنّ ذلك قد يؤدي إلى إنشاء نقاط اتصال. لتجنُّب نقطة الاتصال، يمكنك الاستفادة من معرّفات المستندات التلقائية في Cloud Firestore التي تستخدم خوارزمية مبعثرة لانتشارها قاموسًا.

النقطة الرئيسية: قد تؤدي فهرسة الحقول التي تتضمن قيمًا متزايدة أو مخفّضة بشكل روتيني، مثل الطوابع الزمنية، إلى نقاط اتصال تؤثر في وقت الاستجابة للتطبيقات ذات معدلات القراءة والكتابة العالية. إذا لم تقدم طلب البحث استنادًا إلى الحقل الذي يتضمن قيمًا متسلسلة، يمكنك استثناء الحقل من الفهرسة لتجاوز هذا الحد.

يُرجى العلم أنّه باتّباع الممارسات الموضّحة أعلاه، يمكن أن يوسّع Cloud Firestore نطاق تنفيذ أعباء عمل كبيرة بشكل عشوائي بدون الحاجة إلى تعديل أي إعدادات.

تحديد المشاكل وحلّها

يوفّر Cloud Firestore أداة عرض المرئيات الرئيسية كأداة تشخيص مصمَّمة لتحليل أنماط الاستخدام وتحديد مشاكل نقطة الاتصال وحلّها.

ما هي الخطوات التالية؟

• الاطّلاع على المزيد من أفضل الممارسات
• تعرَّف على طلبات البحث في الوقت الفعلي على نطاق واسع.