فهم فوترة Realtime Database

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

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

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

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

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

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

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

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