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

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

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

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

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

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

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

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

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

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

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

أسماء الحقول

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

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

فهارس

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

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

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

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

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

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

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

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

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

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

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

تحديثات في الوقت الحقيقي

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

تصميم للمقياس

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

تحديثات وثيقة واحدة

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

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

معدلات قراءة وكتابة وحذف عالية في نطاق مستند ضيق

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

• ينشئ مستندات جديدة بمعدل مرتفع جدًا ويخصص معرفات متزايدة بشكل رتيب.

  يخصص 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 Firestore. على سبيل المثال ، قد يؤدي استخدام القواعد إلى تجنب سيناريو يقوم فيه المستخدم الضار بتنزيل قاعدة البيانات بالكامل بشكل متكرر.

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