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

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

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

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

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

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

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

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

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

    • 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 تجهيز المجموعة الجديدة بفعالية لزيادة عدد الزيارات، خاصةً عندما تحتوي على مستندات قليلة.

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

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

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

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

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

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

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

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

الخصوصية

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

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

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

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