فهم ما يقرأ ويكتب على نطاق واسع

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

Cloud Firestore عبارة عن قاعدة بيانات مرنة وقابلة للتطوير لتطوير الأجهزة المحمولة والويب والخوادم من Firebase وGoogle Cloud. من السهل جدًا البدء باستخدام Cloud Firestore وكتابة تطبيقات غنية وقوية.

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

راجع الأقسام التالية للحصول على أفضل الممارسات قبل تصميم التطبيق الخاص بك.

فهم المكونات عالية المستوى

يوضح الرسم البياني التالي المكونات عالية المستوى المتضمنة في طلب Cloud Firestore API.

Cloud Firestore SDK ومكتبات العملاء

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

واجهة جوجل الأمامية (GFE)

هذه خدمة بنية أساسية مشتركة بين جميع خدمات Google السحابية. يقبل GFE الطلبات الواردة ويعيد توجيهها إلى خدمة Google ذات الصلة (خدمة Firestore في هذا السياق). كما يوفر أيضًا وظائف مهمة أخرى، بما في ذلك الحماية ضد هجمات رفض الخدمة.

خدمة سحابة Firestore

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

طبقة تخزين Cloud Firestore

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

النطاقات الرئيسية والانقسامات

Cloud Firestore هي قاعدة بيانات NoSQL موجهة نحو المستندات. يمكنك تخزين البيانات في المستندات ، والتي يتم تنظيمها في تسلسلات هرمية للمجموعات . تتم ترجمة التسلسل الهرمي للمجموعة ومعرف المستند إلى مفتاح واحد لكل مستند. يتم تخزين المستندات بشكل منطقي وترتيبها معجميًا بواسطة هذا المفتاح الفردي. نحن نستخدم مصطلح نطاق المفاتيح للإشارة إلى نطاق متجاور من المفاتيح المعجمية.

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

النسخ المتزامن

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

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

تخطيط البيانات

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

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

يوضح الرسم التخطيطي التالي كيف قد تبدو الجداول الخاصة بقاعدة بيانات Cloud Firestore مع التقسيمات. يتم تكرار الانقسامات في ثلاث مناطق مختلفة ولكل قسم قائد باكسوس معين.

منطقة واحدة مقابل منطقة متعددة

عند إنشاء قاعدة بيانات، يجب عليك تحديد منطقة أو منطقة متعددة .

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

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

لمزيد من المعلومات حول مواقع المنطقة، راجع مواقع Cloud Firestore .

فهم حياة الكتابة في Cloud Firestore

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

بالنسبة لجميع أنواع عمليات الكتابة، يوفر Cloud Firestore خصائص ACID (الذرية والاتساق والعزل والمتانة) لقواعد البيانات العلائقية. يوفر Cloud Firestore أيضًا إمكانية التسلسل ، مما يعني أن جميع المعاملات تظهر كما لو تم تنفيذها بترتيب تسلسلي.

خطوات عالية المستوى في معاملة الكتابة

عندما يصدر عميل Cloud Firestore عملية كتابة أو تنفيذ معاملة، باستخدام أي من الطرق المذكورة سابقًا، يتم تنفيذ ذلك داخليًا كمعاملة قراءة وكتابة لقاعدة البيانات في طبقة التخزين. تتيح المعاملة لـ Cloud Firestore توفير خصائص ACID المذكورة سابقًا.

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

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

• تحتاج الحقول التي تتم إضافتها إلى المستندات إلى إدراجات مقابلة في جدول الفهارس.
• تحتاج الحقول التي يتم إزالتها من المستندات إلى عمليات الحذف المقابلة في جدول الفهارس.
• تحتاج الحقول التي يتم تعديلها في المستندات إلى عمليات الحذف (للقيم القديمة) والإدراج (للقيم الجديدة) في جدول الفهارس.

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

بمجرد حساب الطفرات، يقوم Cloud Firestore بجمعها داخل معاملة ثم تنفيذها.

فهم معاملة الكتابة في طبقة التخزين

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

في الرسم التخطيطي التالي، تحتوي قاعدة بيانات Cloud Firestore على ثمانية أقسام (مميزة بالعلامة 1-8) مستضافة على ثلاثة خوادم تخزين مختلفة في منطقة واحدة، ويتم نسخ كل قسم في 3 مناطق مختلفة (أو أكثر). كل قسم لديه زعيم Paxos، والذي قد يكون في منطقة مختلفة لتقسيمات مختلفة.

خذ بعين الاعتبار قاعدة بيانات Cloud Firestore التي تحتوي على مجموعة Restaurants على النحو التالي:

يطلب عميل Cloud Firestore التغيير التالي على مستند في مجموعة Restaurant عن طريق تحديث قيمة حقل priceCategory .

تصف الخطوات عالية المستوى التالية ما يحدث كجزء من الكتابة:

1. إنشاء معاملة القراءة والكتابة.
2. اقرأ مستند restaurant1 في مجموعة Restaurants من جدول المستندات من طبقة التخزين.
3. اقرأ فهارس الوثيقة من جدول الفهارس .
4. حساب الطفرات التي سيتم إجراؤها على البيانات. وفي هذه الحالة هناك خمس طفرات:
   • M1: قم بتحديث صف restaurant1 في جدول المستندات ليعكس التغيير في قيمة حقل priceCategory .
   • M2 وM3: احذف الصفوف الخاصة بالقيمة القديمة لـ priceCategory في جدول الفهارس للفهارس التنازلية والصاعدة.
   • M4 وM5: قم بإدراج الصفوف للقيمة الجديدة لـ priceCategory في جدول الفهارس للفهارس التنازلية والصاعدة.
5. ارتكاب هذه الطفرات.

يبحث عميل التخزين في خدمة Cloud Firestore عن الأقسام التي تمتلك مفاتيح الصفوف المراد تغييرها. لنفكر في حالة يخدم فيها Split 3 M1، وSplit 6 يخدم M2-M5. هناك معاملة موزعة، تتضمن كل هذه الانقسامات كمشاركين . قد تتضمن تقسيمات المشاركين أيضًا أي تقسيم آخر تمت قراءة البيانات منه مسبقًا كجزء من معاملة القراءة والكتابة.

تصف الخطوات التالية ما يحدث كجزء من الالتزام:

1. يُصدر عميل التخزين التزامًا. يحتوي الالتزام على الطفرات M1-M5.
2. الانقسامات 3 و 6 هم المشاركون في هذه الصفقة. يتم اختيار أحد المشاركين ليكون المنسق ، مثل Split 3. وتتمثل مهمة المنسق في التأكد من تنفيذ المعاملة أو إحباطها ذريًا عبر جميع المشاركين.
   • إن النسخ المتماثلة لهذه الانقسامات هي المسؤولة عن العمل الذي يقوم به المشاركون والمنسقون.
3. يقوم كل مشارك ومنسق بتشغيل خوارزمية Paxos مع النسخ المتماثلة الخاصة بهم.
   • يدير القائد خوارزمية Paxos مع النسخ المتماثلة. يتم تحقيق النصاب القانوني إذا ردت معظم النسخ المتماثلة ok to commit بالرد على القائد.
   • يقوم كل مشارك بعد ذلك بإخطار المنسق عندما يتم إعداده (المرحلة الأولى من الالتزام على مرحلتين). إذا لم يتمكن أي مشارك من تنفيذ المعاملة، aborts المعاملة بأكملها.
4. بمجرد أن يعرف المنسق أن جميع المشاركين، بما في ذلك نفسه، مستعدون، فإنه يقوم بإبلاغ نتائج معاملة accept إلى جميع المشاركين (المرحلة الثانية من الالتزام على مرحلتين). في هذه المرحلة، يسجل كل مشارك قرار الالتزام للتخزين المستقر ويتم الالتزام بالمعاملة.
5. يستجيب المنسق لعميل التخزين في Cloud Firestore بأنه تم تنفيذ المعاملة. بالتوازي، يقوم المنسق وجميع المشاركين بتطبيق الطفرات على البيانات.

عندما تكون قاعدة بيانات Cloud Firestore صغيرة، قد يحدث أن يمتلك الانقسام الواحد جميع المفاتيح في الطفرات M1-M5. في مثل هذه الحالة، يوجد مشارك واحد فقط في المعاملة ولا يلزم الالتزام على مرحلتين المذكور سابقًا، مما يجعل عملية الكتابة أسرع.

يكتب في منطقة متعددة

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

نقوم بتكوين النسخ المتماثلة بطريقة تظل فيها قيادة الانقسامات دائمًا في المنطقة الأساسية. المنطقة الأساسية هي المنطقة التي تأتي منها حركة المرور إلى خادم Cloud Firestore. يؤدي قرار القيادة هذا إلى تقليل التأخير ذهابًا وإيابًا في الاتصال بين عميل التخزين في Cloud Firestore وقائد النسخة المتماثلة (أو منسق المعاملات متعددة الانقسام).

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

فهم حياة القراءة في Cloud Firestore

يتعمق هذا القسم في القراءات المستقلة وغير الفعلية في Cloud Firestore. داخليًا، يتعامل خادم Cloud Firestore مع معظم هذه الاستعلامات على مرحلتين رئيسيتين:

1. مسح نطاق واحد عبر جدول الفهارس
2. قم بتحديد نقاط البحث في جدول المستندات بناءً على نتيجة الفحص السابق

قد تكون هناك استعلامات معينة تتطلب معالجة أقل أو معالجة أكثر (على سبيل المثال، استعلامات IN) في Cloud Firestore.

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

فهم معاملة القراءة في طبقة التخزين

يصف هذا القسم أنواع القراءات وكيفية معالجتها في طبقة التخزين في Cloud Firestore.

قراءات قوية

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

قراءة انقسام واحد

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

في هذه المرحلة، قد تحدث الحالات التالية اعتمادًا على النسخة المتماثلة المختارة:

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

يقوم Cloud Firestore بعد ذلك بإرجاع الاستجابة إلى عميله.

قراءة متعددة الانقسام

في الحالة التي يجب فيها إجراء القراءات من تقسيمات متعددة، تحدث نفس الآلية عبر جميع الانقسامات. بمجرد إرجاع البيانات من جميع الانقسامات، يقوم عميل التخزين في Cloud Firestore بدمج النتائج. ثم يستجيب Cloud Firestore لعملائه بهذه البيانات.

يقرأ التي لا معنى لها

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

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

تجنب النقاط الساخنة

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

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

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

تحدث أخطاء التنافس عندما تحاول عمليات متعددة قراءة و/أو كتابة نفس المستند في وقت واحد.

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

لاحظ أنه من خلال اتباع الممارسات الموضحة أعلاه، يمكن لـ Firestore التوسع لخدمة أحمال العمل الكبيرة بشكل عشوائي دون الحاجة إلى تعديل أي تكوين.

استكشاف الأخطاء وإصلاحها

يوفر Firestore Key Visualizer كأداة تشخيصية مصممة خصيصًا لتحليل أنماط الاستخدام واستكشاف مشكلات نقاط الاتصال وإصلاحها.

ماذا بعد

• اقرأ المزيد عن أفضل الممارسات
• تعرف على الاستعلامات في الوقت الفعلي على نطاق واسع