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

تُحصّل Firebase رسومًا مقابل البيانات التي تخزّنها في قاعدة بياناتك وجميع الزيارات الصادرة على الشبكة في طبقة الجلسة (الطبقة 5) من نموذج OSI. يتم تحصيل رسوم مساحة التخزين بقيمة ٥ دولار أمريكي لكل غيغابايت في الشهر، ويتم تقييمها يوميًا. لا تتأثر الفوترة بالموقع الجغرافي لقاعدة بياناتك. تتضمن حركة البيانات الصادرة نفقات الاتصال والتشفير من جميع عمليات قاعدة البيانات والبيانات التي يتم تنزيلها من خلال قراءات قاعدة البيانات. يمكن أن تؤدي كلّ من عمليات قراءة قاعدة البيانات وعمليات كتابتها إلى تحصيل رسوم اتصال في فاتورتك. تؤدي جميع الزيارات الواردة من قاعدة البيانات وإليها، بما في ذلك العمليات التي تم رفضها بموجب قواعد الأمان، إلى تحمُّل تكاليف قابلة للفوترة.

تشمل بعض الأمثلة الشائعة للزيارات التي يتمّ تحصيل رسومها ما يلي:

  • البيانات التي تم تنزيلها: عندما يحصل العملاء على بيانات من قاعدة بياناتك، تحصّل Firebase رسومًا مقابل البيانات التي تم تنزيلها. ويشكّل ذلك عادةً الجزء الأكبر من تكاليف النطاق الترددي، ولكنه ليس العامل الوحيد في فاتورتك.
  • أعباء عمل البروتوكول: من الضروري إجراء بعض الزيارات الإضافية بين الخادم والعملاء لإنشاء جلسة وصيانتها. استنادًا إلى الprotocolly الأساسي، قد تتضمّن هذه الزيارات: النفقات العامة لprotocolly في الوقت الفعلي في قاعدة بيانات Firebase في الوقت الفعلي، والنفقات العامة لبروتوكول WebSocket، والنفقات العامة لعنوان HTTP. في كل مرة يتم فيها إتمام اتصال، تساهم هذه التكاليف العامة، بالإضافة إلى أي تكاليف عامة لتشفير بروتوكول SSL، في تكاليف الاتصال. على الرغم من أنّ هذا الحجم ليس كبيرًا بالنسبة إلى معدل نقل البيانات لطلب واحد، إلا أنّه يمكن أن يشكّل جزءًا كبيرًا من فاتورتك إذا كانت حِزم البيانات صغيرة أو كنت تُجري عمليات اتصال قصيرة ومتكرّرة.
  • التكلفة الإضافية لتشفير طبقة المقابس الآمنة: هناك تكلفة مرتبطة بالتكلفة الإضافية لتشفير طبقة المقابس الآمنة اللازمة للاتصالات الآمنة. في المتوسّط، تبلغ هذه التكلفة حوالي 3.5 كيلوبايت لمرحلة المصافحة الأولية، وعشرات بايت تقريبًا لرؤوس سجلّات TLS في كل رسالة خارجية. في معظم التطبيقات، يشكّل ذلك نسبة صغيرة من فاتورتك. ومع ذلك، يمكن أن تصبح هذه النسبة كبيرة إذا كانت حالتك المحدّدة تتطلّب الكثير من عمليات مصافحة طبقة المقابس الآمنة. على سبيل المثال، قد تتطلّب الأجهزة التي لا تتوافق مع تذاكر جلسات بروتوكول أمان طبقة النقل (TLS) إجراء عمليات مصافحة اتصال SSL بأعداد كبيرة.
  • بيانات وحدة تحكّم Firebase: على الرغم من أنّ هذه البيانات لا تمثّل عادةً جزءًا كبيرًا من تكاليف Realtime Database، إلا أنّ Firebase يحصِّل رسومًا مقابل البيانات التي تقرأها وتكتبها من وحدة تحكّم Firebase.

تقدير الاستخدام الذي يتمّ فوترته

للاطّلاع على عمليات الاتصال الحالية واستخدام البيانات في Realtime Database، اطّلِع على علامة التبويب الاستخدام في وحدة تحكّم Firebase. يمكنك التحقّق من الاستخدام على مدار فترة الفوترة الحالية أو آخر 30 يومًا أو آخر 24 ساعة.

تعرِض Firebase إحصاءات الاستخدام للمقاييس التالية:

  • عمليات الربط: عدد عمليات الربط المتزامنة والمفتوحة حاليًا في الوقت الفعلي بقاعدة بياناتك ويتضمّن ذلك عمليات الاتصال في الوقت الفعلي التالية: WebSocket والاستطلاع الطويل والأحداث التي يرسلها خادم HTML. ولا يشمل الطلبات المستندة إلى أسلوب REST.
  • مساحة التخزين: مقدار البيانات المخزّنة في قاعدة بياناتك ولا يشمل ذلك استضافة Firebase أو البيانات المخزّنة من خلال منتجات Firebase الأخرى.
  • عمليات التنزيل: جميع وحدات البايت التي تم تنزيلها من قاعدة بياناتك، بما في ذلك النفقات العامة للبروتوكول والتشفير
  • التحميل: يعرض هذا الرسم البياني مقدار ما تكون من قاعدة البيانات قيد الاستخدام ومعالجة الطلبات على مدار فترة دقيقة واحدة. قد تلاحظ مشاكل في الأداء عندما تقترب قاعدة بياناتك من نسبة %100.

تحسين الاستخدام

هناك بعض أفضل الممارسات التي يمكنك استخدامها لتحسين استخدام قاعدة البيانات وتكاليف معدل نقل البيانات.

  • استخدام حِزم SDK الأصلية: استخدِم حِزم SDK التي تتوافق مع منصّة تطبيقك كلما أمكن ذلك، بدلاً من REST API. تحافظ حِزم تطوير البرامج (SDK) على اتصالات مفتوحة، ما يقلل من تكاليف تشفير طبقة المقابس الآمنة التي تتراكم عادةً مع واجهة برمجة التطبيقات REST API.
  • التحقّق من الأخطاء: إذا كانت تكاليف النطاق الترددي مرتفعة بشكل غير متوقّع، تأكَّد مما يلي: أنّ تطبيقك لا يُزامن المزيد من البيانات أو يُزامن البيانات بمعدّل أكبر مما كان مقصودًا في الأصل. لتحديد المشاكل، استخدِم أداة تحليل الأداء لقياس عمليات القراءة وتفعيل تسجيل تصحيح الأخطاء في حِزم تطوير البرامج (SDK) لأنظمة التشغيل Android و Objective-C و Web. تحقَّق من عمليات المزامنة والعمليات التي تعمل في الخلفية في تطبيقك للتأكّد من أنّه يعمل على النحو المطلوب.
  • تقليل عمليات الربط: جرِّب تحسين سرعة اتصالك بقدر الإمكان. يمكن أن تكون طلبات REST الصغيرة والمتكرّرة أكثر تكلفة من عملية ربط واحدة ومتواصلة باستخدام حزمة SDK الأصلية. إذا كنت تستخدم واجهة برمجة تطبيقات REST، يمكنك استخدام واجهة HTTP للحفاظ على الاتصال أو الأحداث التي يرسلها الخادم، ما يمكن أن يؤدي إلى خفض التكاليف الناتجة من عمليات تأكيد الاتصال من خلال طبقة المقابس الآمنة.
  • استخدام تذاكر جلسات بروتوكول أمان طبقة النقل (TLS): يمكنك تقليل التكاليف الإضافية لتشفير طبقة المقابس الآمنة (SSL) في اتصالات المتابعة من خلال إصدار تذاكر جلسات بروتوكول أمان طبقة النقل (TLS). ويُعدّ ذلك مفيدًا بشكل خاص إذا كنت بحاجة إلى عمليات اتصال آمنة ومتكرّرة بقاعدة البيانات.
  • طلبات البحث في الفهرس: تعمل فهرسة بياناتك على خفض إجمالي معدل نقل البيانات الذي تستخدمه لطلبات البحث، ما يعود بالفائدة على مضاعفة خفض التكاليف وتعزيز أداء قاعدة البيانات. استخدِم أداة أداة تحليل الأداء للعثور على طلبات البحث غير المفهرَسة في قاعدة بياناتك.
  • تحسين المستمعين: يمكنك إضافة طلبات بحث للحدّ من البيانات التي تعرضها عمليات الاستماع واستخدام أدوات معالجة البيانات التي تنزّل تحديثات البيانات فقط، على سبيل المثال، on() بدلاً من once(). بالإضافة إلى ذلك، ضَع المستمعين في أقصى نقطة ممكنة من المسار لتقليل كمية البيانات التي تتم مزامنتها.
  • تقليل تكاليف مساحة التخزين: يمكنك تنفيذ مهام تنظيف دورية وتقليل أي بيانات تكرارية في قاعدة بياناتك.
  • استخدام القواعد: يمكنك منع أي عمليات غير مصرّح بها قد تكون باهظة التكلفة على قاعدة بياناتك. على سبيل المثال، يمكن أن يؤدي استخدام Firebase Realtime Database Security Rules إلى تجنُّب سيناريو يتمثل في تنزيل مستخدم ضار لقاعدة بياناتك بالكامل بشكل متكرّر. اطّلِع على مزيد من المعلومات عن استخدام قواعد قاعدة بيانات Firebase الآنية الاستجابة.

تعتمد أفضل خطة تحسين لتطبيقك على حالة الاستخدام المحدّدة. هذه القائمة ليست شاملة لأفضل الممارسات، ولكن يمكنك العثور على المزيد من النصائح من خبراء Firebase على قناة Slack أو على Stack Overflow.