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

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

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

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

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

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

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

Cloud Firestore حِزم SDK ومكتبات العملاء

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

Google Front End (GFE)

هذه خدمة بنية أساسية شائعة لجميع خدمات Google Cloud. يقبل GFE الطلبات الواردة ويعيد توجيهها إلى خدمة 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 لتحقيق الإجماع. يتم اختيار نسخة طبق الأصل واحدة من كل قسم لتكون قائد Paxos، وهو المسؤول عن معالجة عمليات الكتابة في هذا القسم. يمنحك النسخ المتزامن إمكانية قراءة أحدث إصدار من البيانات من Cloud Firestore في أي وقت.

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

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

تنسيق البيانات

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

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

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

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

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

الموقع الجغرافي الإقليمي هو موقع جغرافي محدّد، مثل 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. احتساب الطفرات التي سيتم إجراؤها على البيانات في هذه الحالة، هناك خمس طفرات:
   • م1: عدِّل صف 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 يوفّر Key Visualizer كأداة تشخيص مصمّمة لتحليل أنماط الاستخدام وتحديد المشاكل المتعلّقة بنقاط الاتصال وحلّها.

الخطوات التالية

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