فهم فوترة Realtime Database

عندما يكون مشروعك ضمن خطة Spark الأساسية بدون تكلفة، لن يتم تحصيل رسوم منك مقابل استخدامك Realtime Database. يمكنك الاستفادة من الاستخدام بدون تكلفة الذي يشمل 1 غيغابايت من مساحة تخزين البيانات و10 غيغابايت/الشهر من عمليات تنزيل البيانات.

في حال الترقية إلى خطة أسعار Blaze للدفع حسب الاستخدام، سيظل بإمكانك الاستفادة من الاستخدام بدون تكلفة (غيغابايت واحد من مساحة تخزين البيانات و10 غيغابايت/الشهر من عمليات تنزيل البيانات)، وسيتم تحصيل رسوم منك مقابل أي استخدام يتجاوز هذا المبلغ. عندما يكون مشروعك ضمن خطة Blaze المَرِنة، ننصحك بإعداد تنبيهات بشأن الميزانية لمشروعك.

يشرح الجزء المتبقي من هذه الصفحة الفوترة بمزيد من التفصيل.

طريقة احتساب Realtime Database للفوترة

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

تشمل بعض الأمثلة الشائعة على عدد الزيارات الخاضع للفوترة ما يلي:

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

تقدير الاستخدام الخاضع للفوترة

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

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

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

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

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

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

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