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

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

الموقع الجغرافي لقاعدة البيانات

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

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

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

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

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

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

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

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

أسماء الحقول

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

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

المؤشرات

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

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

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

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

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

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

الحالة الإعرابية	الوصف
حقول السلاسل الكبيرة	إذا كان لديك حقل سلسلة يحتوي غالبًا على قيم سلسلة طويلة التي لا تستخدمها للاستعلام، فيمكنك خفض تكاليف التخزين من خلال إعفاء الحقل من الفهرسة.
معدّلات الكتابة العالية في مجموعة تحتوي على مستندات ذات قيم تسلسلية	إذا أشرت إلى حقل يزداد أو ينقص بشكل تسلسلي بين المستندات في مجموعة، مثل الطابع الزمني، يكون الحد الأقصى لمعدّل الكتابة في المجموعة هو 500 عملية كتابة في الثانية. إذا لم تقدم طلب البحث استنادًا إلى الحقل الذي يحتوي على قيم متسلسلة، يمكنك استثناء الحقل من الفهرسة لتجاوز هذا الحد. في حالة استخدام إنترنت الأشياء (IoT) ذات معدل الكتابة المرتفع، على سبيل المثال، قد تصل المجموعة التي تحتوي على مستندات ذات حقل طابع زمني إلى الحد الأقصى البالغ 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