أفضل الممارسات في 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