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

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

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

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

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

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

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

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

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

  • 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 التكاليف المتكبَّدة.

الخصوصية

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

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

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

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