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

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

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

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

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

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

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

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

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

  • Customer1 وCustomer2 وCustomer3 و...
  • Product 1 وProduct 2 وProduct 3 و...

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

أسماء الحقول

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

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

الفهارس

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

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

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

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

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

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

الحالة الإعرابية	الوصف
حقول السلاسل الكبيرة	إذا كان لديك حقل سلسلة يحتوي غالبًا على قيم سلسلة طويلة لا تستخدمها في طلبات البحث، يمكنك خفض تكاليف التخزين عن طريق استثناء الحقل من الفهرسة.
معدّلات كتابة عالية في مجموعة تحتوي على مستندات ذات قيم متسلسلة	إذا أضفت فهرسًا إلى حقل يزيد أو ينقص بشكل تسلسلي بين المستندات في مجموعة، مثل الطابع الزمني، سيكون الحد الأقصى لمعدل الكتابة في المجموعة 500 عملية كتابة في الثانية. إذا لم تكن تستند في طلب البحث إلى الحقل الذي يتضمّن قيمًا تسلسلية، يمكنك استثناء الحقل من الفهرسة لتجاوز هذا الحد. في حالة استخدام إنترنت الأشياء (IoT) التي تتضمّن معدّل كتابة مرتفعًا، على سبيل المثال، قد تقترب المجموعة التي تحتوي على مستندات تتضمّن حقل طابع زمني من حدّ 500 عملية كتابة في الثانية.
حقول مدة البقاء (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 Standard. احرص على توزيع العمليات بشكل متساوٍ نسبيًا على مستوى النطاق الرئيسي. يُطلق على ذلك اسم قاعدة "500/50/5".

نقل الزيارات إلى مجموعة جديدة

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

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

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

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

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

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

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

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

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

الخصوصية

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

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

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

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