أفضل الممارسات في Cloud Firestore

استخدِم أفضل الممارسات المدرَجة هنا كمرجع سريع عند إنشاء تطبيق يستخدم Cloud Firestore.

الموقع الجغرافي لقاعدة البيانات

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

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

اختَر موقعًا جغرافيًا إقليميًا لتقليل التكاليف، أو لتقليل وقت استجابة عمليات النسخ إذا كان تطبيقك حسّاسًا لوقت الاستجابة، أو لتحديد موقع جغرافي قريب من موارد Google Cloud Platform الأخرى.

أرقام تعريف المستندات

• تجنَّب رقمَي تعريف المستند . و...
• تجنَّب استخدام الشُرط المائلة للأمام / في معرّفات المستندات.

• لا تستخدِم أرقام تعريف مستندات متزايدة بشكلٍ أحادي مثل:

  • Customer1 وCustomer2 وCustomer3 و...
  • Product 1 وProduct 2 وProduct 3 و...

  يمكن أن تؤدي معرّفات التسلسل هذه إلى نقاط ساخنة تؤثر في وقت الاستجابة.

أسماء الحقول

• تجنَّب استخدام الأحرف التالية في أسماء الحقول لأنّها تتطلّب استخدام علامات إلغاء إضافية:

  • . فترة
  • [ قوس أيسر
  • ] قوس أيمن
  • * علامة نجمية
  • ` الفاصلة العليا المائلة

الفهارس

تقليل وقت استجابة الكتابة

إنّ المساهم الرئيسي في وقت استجابة الكتابة هو توزيع الفهرس. في ما يلي أفضل الممارسات التي يجب اتّباعها لمحاولة تقليل عدد الصفحات التي يشير إليها فهرس معيّن:

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

• قلِّل عدد المستندات في المعاملة. لكتابة عددٍ كبير من المستندات، ننصحك باستخدام كاتب مجمّع بدلاً من كاتب الحِزم الذرّية.

استثناءات الفهرس

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

عمليات القراءة والكتابة

• يعتمد الحد الأقصى الدقيق لمعدل تحديث التطبيق لمستند واحد بشكل كبير على حجم العمل. لمزيد من المعلومات، اطّلِع على التعديلات على مستند واحد.

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

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

عمليات إعادة محاولة المعاملات

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

تحديثات في الوقت الفعلي

للاطّلاع على أفضل الممارسات المتعلّقة بالتغييرات في الوقت الفعلي، راجِع مقالة فهم طلبات البحث في الوقت الفعلي على نطاق واسع.

التصميم على نطاق واسع

توضّح أفضل الممارسات التالية كيفية تجنّب المواقف التي تؤدي إلى حدوث مشاكل في الصراع.

تعديلات على مستند واحد

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

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

معدّلات عالية للقراءة والكتابة والحذف في نطاق مستندات ضيّق

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

• تُنشئ مستندات جديدة بمعدّل عالٍ جدًا وتخصّص معرّفات متزايدة بشكلٍ أحادي.

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

• إنشاء مستندات جديدة بمعدّل مرتفع في مجموعة تحتوي على عدد قليل من المستندات

• إنشاء مستندات جديدة تتضمّن حقلًا متزايدًا بشكلٍ أحادي، مثل الطابع الزمني، بمعدّل مرتفع جدًا

• حذف المستندات في مجموعة بمعدّل مرتفع

• عمليات الكتابة في قاعدة البيانات بمعدّل مرتفع جدًا بدون زيادة عدد الزيارات تدريجيًا

تجنُّب تخطّي البيانات المحذوفة

تجنَّب طلبات البحث التي تتخطّى البيانات المحذوفة مؤخرًا. قد يضطر طلب البحث إلى تخطّي عدد كبير من إدخالات الفهرس إذا تم حذف نتائج الطلب المبكّرة مؤخرًا.

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

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

في كل مرة يتم فيها تشغيل طلب البحث هذا، يتم فحص إدخالات الفهرس للحقل created في أي مستندات تم حذفها مؤخرًا. ويؤدي ذلك إلى إبطاء طلبات البحث.

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

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

ملاحظة: يستخدم المثال أعلاه حقلًا متزايدًا بشكلٍ أحادي، وهو نموذج مضاد لمعدّلات الكتابة العالية.

زيادة عدد الزيارات

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

نقل الزيارات إلى مجموعة جديدة

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

يمكن أن تحدث مشكلة مشابهة إذا غيّرت أرقام تعريف المستندات لعدة مستندات ضمن المجموعة نفسها.

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

عمليات القراءة المتوازيّة

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

من الاستراتيجيات الممكنة لزيادة عمليات القراءة أو الكتابة تدريجيًا في مجموعة جديدة هو استخدام تجزئة محدّدة لمعرّف المستخدم لاختيار نسبة مئوية عشوائية من المستخدِمين الذين يحاولون كتابة مستندات جديدة. تأكَّد من أنّ نتيجة تجزئة ملف تعريف المستخدِم ليست منحرفة بسبب وظيفتك أو سلوك المستخدِم.

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

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

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

الخصوصية

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

منع الوصول غير المصرَّح به

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

مزيد من المعلومات حول استخدام Cloud Firestore Security Rules