يقوم Firebase بسداد فواتير البيانات التي تخزنها في قاعدة بياناتك وكل حركة مرور الشبكة الصادرة في طبقة الجلسة (الطبقة 5) من نموذج OSI. تتم محاسبة التخزين بمبلغ 5 دولارات لكل جيجابايت/شهر، ويتم تقييمه يوميًا. لا تتأثر الفواتير بموقع قاعدة البيانات الخاصة بك. تتضمن حركة المرور الصادرة تكاليف الاتصال والتشفير من جميع عمليات قاعدة البيانات والبيانات التي تم تنزيلها من خلال قراءات قاعدة البيانات. يمكن أن تؤدي كل من عمليات القراءة والكتابة في قاعدة البيانات إلى فرض تكاليف الاتصال على فاتورتك. كل حركة المرور من وإلى قاعدة البيانات الخاصة بك، بما في ذلك العمليات التي تم رفضها بواسطة قواعد الأمان، تؤدي إلى تكاليف قابلة للفوترة.
تتضمن بعض الأمثلة الشائعة لحركة المرور المفوترة ما يلي:
- البيانات التي تم تنزيلها: عندما يحصل العملاء على بيانات من قاعدة بياناتك، يفرض Firebase رسومًا مقابل البيانات التي تم تنزيلها. عادة، يشكل هذا الجزء الأكبر من تكاليف النطاق الترددي، ولكنه ليس العامل الوحيد في فاتورتك.
- عبء البروتوكول: بعض حركة المرور الإضافية بين الخادم والعملاء ضرورية لإنشاء الجلسة والحفاظ عليها. اعتمادًا على البروتوكول الأساسي، قد تتضمن حركة المرور هذه ما يلي: حمل بروتوكول الوقت الفعلي لقاعدة بيانات Firebase Realtime Database، وعبء WebSocket، ورأس HTTP. في كل مرة يتم فيها إنشاء اتصال، تساهم هذه النفقات العامة، بالإضافة إلى أي نفقات إضافية لتشفير SSL، في تكاليف الاتصال. على الرغم من أن هذا لا يمثل نطاقًا تردديًا كبيرًا لطلب واحد، إلا أنه يمكن أن يمثل جزءًا كبيرًا من فاتورتك إذا كانت حمولاتك صغيرة أو قمت بإجراء اتصالات قصيرة ومتكررة.
- حمل تشفير SSL: هناك تكلفة مرتبطة بحمل تشفير SSL الضروري للاتصالات الآمنة. في المتوسط، تبلغ هذه التكلفة حوالي 3.5 كيلو بايت للمصافحة الأولية، وعشرات البايتات تقريبًا لرؤوس سجلات TLS في كل رسالة صادرة. بالنسبة لمعظم التطبيقات، تمثل هذه نسبة صغيرة من فاتورتك. ومع ذلك، يمكن أن تصبح هذه نسبة كبيرة إذا كانت حالتك المحددة تتطلب الكثير من مصافحات SSL. على سبيل المثال، قد تتطلب الأجهزة التي لا تدعم تذاكر جلسة TLS عددًا كبيرًا من مصافحات اتصال SSL.
- بيانات وحدة تحكم Firebase: على الرغم من أن هذا لا يمثل عادةً جزءًا كبيرًا من تكاليف Realtime Database، إلا أن Firebase يفرض رسومًا مقابل البيانات التي تقرأها وتكتبها من وحدة تحكم Firebase.
قم بتقدير استخدامك المفوتر
لرؤية اتصالات قاعدة بيانات Realtime الحالية واستخدام البيانات، تحقق من علامة التبويب "الاستخدام" في وحدة تحكم Firebase. يمكنك التحقق من الاستخدام خلال فترة الفاتورة الحالية، أو آخر 30 يومًا، أو آخر 24 ساعة.
يعرض Firebase إحصائيات الاستخدام للمقاييس التالية:
- الاتصالات: عدد الاتصالات المتزامنة والمفتوحة حاليًا بقاعدة البيانات الخاصة بك. يتضمن ذلك اتصالات الوقت الفعلي التالية: WebSocket، والاستقصاء الطويل، والأحداث المرسلة من خادم HTML. ولا يتضمن طلبات RESTful.
- التخزين: مقدار البيانات المخزنة في قاعدة البيانات الخاصة بك. ولا يشمل ذلك استضافة Firebase أو البيانات المخزنة من خلال منتجات Firebase الأخرى.
- التنزيلات: جميع وحدات البايت التي تم تنزيلها من قاعدة البيانات الخاصة بك، بما في ذلك البروتوكول والتشفير.
- التحميل: يوضح هذا الرسم البياني مقدار استخدام قاعدة البيانات الخاصة بك، ومعالجة الطلبات، خلال فترة زمنية محددة مدتها دقيقة واحدة. قد تواجه مشكلات في الأداء عندما تقترب قاعدة بياناتك من 100%.
تحسين الاستخدام
هناك بعض أفضل الممارسات التي يمكنك استخدامها لتحسين استخدام قاعدة البيانات وتكاليف النطاق الترددي.
- استخدم حزم SDK الأصلية: كلما أمكن، استخدم حزم SDK التي تتوافق مع النظام الأساسي لتطبيقك، بدلاً من REST API. تحافظ مجموعات SDK على اتصالات مفتوحة، مما يقلل من تكاليف تشفير SSL التي تضاف عادةً مع REST API.
- التحقق من وجود أخطاء: إذا كانت تكاليف النطاق الترددي مرتفعة بشكل غير متوقع، فتأكد من أن تطبيقك لا يقوم بمزامنة المزيد من البيانات أو المزامنة أكثر مما كنت تنوي في الأصل. لتحديد المشكلات بدقة، استخدم أداة ملف التعريف لقياس عمليات القراءة لديك وتشغيل تسجيل التصحيح في Android و Objective-C و Web SDK. تحقق من الخلفية وعمليات المزامنة في تطبيقك للتأكد من أن كل شيء يعمل كما تريد.
- تقليل الاتصالات: حاول، إن أمكن، تحسين النطاق الترددي لاتصالك. يمكن أن تكون طلبات REST الصغيرة والمتكررة أكثر تكلفة من الاتصال الفردي المستمر باستخدام SDK الأصلي. إذا كنت تستخدم REST API، ففكر في استخدام HTTP Keep-Alive أو الأحداث المرسلة من الخادم ، والتي يمكن أن تقلل التكاليف من مصافحات SSL.
- استخدم تذاكر جلسة TLS: قم بتقليل التكاليف العامة لتشفير SSL على الاتصالات المستأنفة عن طريق إصدار تذاكر جلسة TLS . يعد هذا مفيدًا بشكل خاص إذا كنت تحتاج إلى اتصالات متكررة وآمنة بقاعدة البيانات.
- استعلامات الفهرسة: تعمل فهرسة بياناتك على تقليل إجمالي النطاق الترددي الذي تستخدمه للاستعلامات، مما له فائدة مزدوجة تتمثل في خفض التكاليف وزيادة أداء قاعدة البيانات الخاصة بك. استخدم أداة التعريف للعثور على الاستعلامات غير المفهرسة في قاعدة البيانات الخاصة بك.
- تحسين المستمعين: قم بإضافة استعلامات للحد من البيانات التي ترجعها عمليات الاستماع الخاصة بك واستخدم المستمعين الذين يقومون فقط بتنزيل التحديثات على البيانات - على سبيل المثال،
on()بدلاً منonce(). بالإضافة إلى ذلك، ضع مستمعيك في أقصى المسار قدر الإمكان للحد من كمية البيانات التي يقومون بمزامنتها. - تقليل تكاليف التخزين: قم بتشغيل مهام التنظيف الدورية وتقليل أي بيانات مكررة في قاعدة البيانات الخاصة بك.
- قواعد الاستخدام: منع أي عمليات غير مصرح بها ومكلفة على قاعدة البيانات الخاصة بك. على سبيل المثال، قد يؤدي استخدام قواعد أمان قاعدة بيانات Firebase Realtime إلى تجنب السيناريو الذي يقوم فيه مستخدم ضار بتنزيل قاعدة البيانات بالكامل بشكل متكرر. تعرف على المزيد حول استخدام قواعد قاعدة بيانات Firebase Realtime .
تعتمد أفضل خطة تحسين لتطبيقك على حالة الاستخدام الخاصة بك. على الرغم من أن هذه ليست قائمة شاملة لأفضل الممارسات، إلا أنه يمكنك العثور على المزيد من النصائح والإرشادات من خبراء Firebase على قناة Slack الخاصة بنا أو على Stack Overflow .