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

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

موقع قاعدة البيانات

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

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

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

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

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

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

  • Customer1 وCustomer2 وCustomer3 وما إلى ذلك
  • Product 1 وProduct 2 وProduct 3 وما إلى ذلك

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

أسماء الحقول

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

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

الفهارس

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

العامل الرئيسي الذي يؤثر في وقت استجابة عمليات الكتابة هو التوسّع الكبير للفهرس. في ما يلي أفضل الممارسات لتقليل التوسّع الكبير للفهرس:

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

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

الإعفاءات من الفهرس

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

الحالة الإعرابية	الوصف
حقول السلاسل الكبيرة	إذا كان لديك حقل سلسلة يحتوي غالبًا على قيم سلاسل طويلة لا تستخدِمها في طلبات البحث، يمكنك خفض تكاليف التخزين من خلال إعفاء الحقل من الفهرسة.
معدّلات الكتابة المرتفعة في مجموعة تحتوي على مستندات ذات قيم تسلسلية	إذا كنت تفهرس حقلًا يزداد أو ينقص بشكل تسلسلي بين المستندات في مجموعة، مثل طابع زمني، يكون الحد الأقصى لمعدّل الكتابة في المجموعة 500 عملية كتابة في الثانية. إذا لم تكن تستعلم استنادًا إلى الحقل الذي يحتوي على قيم تسلسلية، يمكنك إعفاء الحقل من الفهرسة لتجاوز هذا الحد. في حالة استخدام إنترنت الأشياء بمعدّل كتابة مرتفع، على سبيل المثال، قد تقترب مجموعة تحتوي على مستندات تتضمّن حقل طابع زمني من الحد الأقصى البالغ 500 عملية كتابة في الثانية.
حقول مدة البقاء (TTL)	إذا كنت تستخدِم سياسات مدة البقاء (TTL)، يُرجى العِلم أنّ حقل مدة البقاء (TTL) يجب أن يكون طابعًا زمنيًا. تكون الفهرسة في حقول مدة البقاء (TTL) مفعّلة تلقائيًا ويمكن أن تؤثر في الأداء عند ارتفاع معدّلات الزيارات. كأفضل ممارسة، أضِف إعفاءات من الفهرسة التلقائية لحقول مدة البقاء (TTL).
حقول الصفائف أو الخرائط الكبيرة	يمكن أن تقترب حقول الصفائف أو الخرائط الكبيرة من الحد الأقصى البالغ 40,000 إدخال فهرس لكل مستند. إذا لم تكن تستعلم استنادًا إلى حقل صفيف أو خريطة كبير، عليك إعفاؤه من الفهرسة.

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

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

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

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

محاولات إعادة تنفيذ المعاملات

تعيد 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 Firestore Security Rules. على سبيل المثال، يمكن أن يؤدي استخدام القواعد إلى تجنُّب سيناريو يكرّر فيه مستخدم ضار تنزيل قاعدة بياناتك بالكامل.

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