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