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

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

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

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

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

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

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

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

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

  • 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