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

يُرجى قراءة هذا المستند لاتّخاذ قرارات مدروسة بشأن تصميم تطبيقاتك لتحقيق أداء عالٍ وموثوقية. يتضمّن هذا المستند مواضيع متقدّمة حول 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 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. احتسِب التغييرات التي سيتم إجراؤها على البيانات. في هذه الحالة، هناك خمس عمليات تحوُّر:
    • M1: عدِّل الصف الخاص بـ "restaurant1" في جدول المستندات ليعكس التغيير في قيمة حقل priceCategory.
    • M2 وM3: حذف الصفوف الخاصة بالقيمة القديمة لـ priceCategory في جدول الفهارس للفهارس التنازلية والتصاعدية
    • ‫M4 وM5: يتم إدراج الصفوف للقيمة الجديدة لـ priceCategory في جدول الفهارس للفهارس التنازلية والتصاعدية.
  5. نفِّذ هذه التغييرات.

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

توضّح الخطوات التالية ما يحدث كجزء من عملية الإرسال:

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

مراحل نشاط الالتزام

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

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