أفضل الممارسات في 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 معرّفات المستندات باستخدام خوارزمية التوزيع. لن تواجه مشكلة hotspotting عند الكتابة إذا أنشأت مستندات جديدة باستخدام معرّفات المستندات التلقائية.

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

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

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

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

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

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

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

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 قد يتعذّر إعداد المجموعة الجديدة بكفاءة لاستيعاب عدد الزيارات المتزايد، خاصةً عندما تحتوي على عدد قليل من المستندات.

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

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

قراءات متوازية

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

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

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

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

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

الخصوصية

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

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

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

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