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

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

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

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

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

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

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

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

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

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

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

أسماء الحقول

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

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

الفهارس

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

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

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

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

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

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

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

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

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

تعمل مجموعات SDK ومكتبات العملاء في Cloud Firestore تلقائيًا على إعادة محاولة المعاملات الفاشلة للتعامل مع الأخطاء العابرة. إذا كان تطبيقك يصل إلى Cloud Firestore من خلال REST أو RPC APIs مباشرةً بدلاً من الوصول من خلال 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 Project ID. قد يتم الاحتفاظ بمعرف مشروع Cloud بعد انتهاء عمر مشروعك.
• كأفضل ممارسة لامتثال البيانات، نوصي بعدم تخزين المعلومات الحساسة في أسماء المستندات وأسماء حقول المستندات.

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

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

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