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

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

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

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

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

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

معرّفات المستندات

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

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

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

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

أسماء الحقول

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

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

المؤشرات

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

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

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

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

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

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

الحالة الإعرابية الوصف
حقول سلاسل كبيرة

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

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

في حالة استخدام إنترنت الأشياء (IoT) ذات معدل الكتابة المرتفع، على سبيل المثال، قد تصل المجموعة التي تحتوي على مستندات ذات حقل طابع زمني إلى الحد الأقصى البالغ 500 عملية كتابة في الثانية.
حقول TTL

في حال استخدام سياسات مدة البقاء (TTL)، يُرجى ملاحظة أنّ مدة البقاء (TTL) أن يكون طابعًا زمنيًا. يتم تفعيل الفهرسة في حقول TTL بشكلٍ تلقائي ويمكن أن تؤثر في الأداء بمعدلات زيارات أعلى. كأفضل ممارسة، أضف الاستثناءات ذات الحقل الواحد لحقول TTL.

حقول ربط أو مصفوفة كبيرة

يمكن أن تقترب حقول الصفيف أو الخريطة الكبيرة من الحد الأقصى المسموح به وهو 40,000 إدخال فهرس لكل مستند. إذا لم يكن تقديم طلب البحث يستند إلى صفيف كبير أو حقل خريطة، يجب استثناءه من الفهرسة.

عمليات القراءة والكتابة

  • يعتمد الحد الأقصى للمعدّل الدقيق الذي يمكن لتطبيق معيّن على تحديث مستند واحد بشكل كبير على عبء العمل. لمزيد من المعلومات راجِع التعديلات على مستند واحد.

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

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

إعادة محاولة المعاملات

حزمة SDK والعميل في Cloud Firestore المكتبات إعادة المحاولة تلقائيًا المعاملات للتعامل مع الأخطاء المؤقتة. في حال وصول التطبيق 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 قد لا تتمكّن من إعداد المجموعة الجديدة بكفاءة لزيادة عدد الزيارات خاصةً عندما يحتوي على مستندات قليلة.

يمكن أن تحدث مشكلة مماثلة في حالة تغيير معرّفات المستندات للعديد من المستندات ضمن نفس المجموعة.

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

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

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

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

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

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

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

الخصوصية

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

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

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

تعرَّف على مزيد من المعلومات عن استخدام قواعد أمان Cloud Firestore.