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

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

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

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

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

<span class=تقسيم قاعدة بيانات 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 معظم هذه طلبات البحث في مرحلتين رئيسيتين:

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

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

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

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

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

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

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

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