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

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

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

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

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

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

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

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

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

  • ‫Customer1، Customer2، Customer3، ...
  • ‫Product 1، Product 2، Product 3، ...

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

أسماء الحقول

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

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

المؤشرات

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

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

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

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

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

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

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

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

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

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

إعادة محاولة إجراء المعاملات

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

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

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

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

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

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

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

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

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

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

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

  يخصّص 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