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

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

الموقع الجغرافي لقاعدة البيانات

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

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

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

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

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

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

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

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

أسماء الحقول

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

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

الفهارس

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

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

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

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

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

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

الحالة الإعرابية	الوصف
حقول السلاسل الكبيرة	إذا كان لديك حقل سلسلة يحتوي غالبًا على قيم سلاسل طويلة لا تستخدمها في طلبات البحث، يمكنك خفض تكاليف التخزين عن طريق إعفاء الحقل من الفهرسة.
معدّلات الكتابة العالية في مجموعة تحتوي على مستندات ذات قيم تسلسلية	إذا أشرت إلى حقل يزداد أو ينقص بشكل تسلسلي بين المستندات في مجموعة، مثل الطابع الزمني، يكون الحد الأقصى لمعدّل الكتابة في المجموعة هو 500 عملية كتابة في الثانية. إذا كنت لا تطلب البحث استنادًا إلى الحقل الذي يحتوي على قيم تسلسلية، يمكنك إعفاء الحقل من الفهرسة لتجاوز هذا الحدّ. في أحد حالات استخدام إنترنت الأشياء التي تتضمن معدّل كتابة مرتفعًا، على سبيل المثال، قد تقترب مجموعة تحتوي على مستندات تتضمّن حقل طابع زمني من الحد الأقصى البالغ 500 عملية كتابة في الثانية.
حقول مدة البقاء (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. قد يتم الاحتفاظ بمعرّف مشروع على Cloud بعد انتهاء دورة حياة مشروعك.
• في إطار أفضل الممارسات المتعلقة بالامتثال للبيانات، ننصح بعدم تخزين معلومات حساسة في أسماء المستندات وحقولها.

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

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

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