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

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

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

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

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

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

ضع في الاعتبار قاعدة بيانات 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. لمزيد من المعلومات عن طلبات البحث في الوقت الفعلي، يمكنك الاطّلاع على مقالة فهم طلبات البحث في الوقت الفعلي على نطاق واسع.

Key Point: تستخدم 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 التي تستخدم خوارزمية للنقاط المبعثرة بحيث تكون موزعة بطريقة معجمية.

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

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

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

توفّر Firestore أداة Key Visualizer كأداة تشخيص مصممة خصيصًا لتحليل أنماط الاستخدام وتحديد مشاكل نقطة الاتصال وإصلاحها.

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

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