تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تفرض Firebase رسومًا على البيانات التي تخزِّنها في قاعدة البيانات وعلى جميع زيارات الشبكة الصادرة على مستوى جلسة (الطبقة 5) من نموذج OSI. يتم تحصيل رسوم التخزين بقيمة 5 دولار أمريكي لكل غيغابايت في الشهر، ويتم تقييمها يوميًا. لا تتأثر الفوترة بموقع قاعدة البيانات. تشمل الزيارات الصادرة تكاليف الاتصال والتشفير
من جميع عمليات قاعدة البيانات والبيانات التي يتم تنزيلها من خلال عمليات قراءة قاعدة البيانات. يمكن أن تؤدي عمليات قراءة وكتابة البيانات في قاعدة البيانات إلى تكاليف اتصال في فاتورتك. تؤدي جميع الزيارات الواردة إلى قاعدة البيانات والصادرة منها، بما في ذلك العمليات التي ترفضها قواعد الأمان، إلى تكاليف قابلة للفوترة.
في ما يلي بعض الأمثلة الشائعة على عدد الزيارات الخاضع للفوترة:
البيانات التي تم تنزيلها: عندما يحصل العملاء على بيانات من قاعدة البيانات، يفرض Firebase رسومًا على البيانات التي تم تنزيلها. عادةً ما يشكّل هذا الجزء الأكبر من تكاليف النطاق الترددي، ولكنّه ليس العامل الوحيد في فاتورتك.
البيانات الإضافية للبروتوكول: بعض الزيارات الإضافية بين الخادم والعملاء ضرورية لإنشاء جلسة والحفاظ عليها. واستنادًا إلى البروتوكول الأساسي، قد تتضمّن هذه الزيارات ما يلي: الحمل الزائد لبروتوكول الوقت الفعلي في "قاعدة بيانات Firebase في الوقت الفعلي"، والحمل الزائد لبروتوكول WebSocket، والحمل الزائد لعناوين HTTP. في كل مرة يتم فيها إنشاء اتصال، تساهم هذه التكلفة العامة، بالإضافة إلى أي تكلفة عامة لتشفير SSL، في تكاليف الاتصال. على الرغم من أنّ هذا المقدار ليس كبيرًا بالنسبة إلى طلب واحد، إلا أنّه قد يشكّل جزءًا كبيرًا من فاتورتك إذا كانت حمولاتك صغيرة أو إذا كنت تجري اتصالات قصيرة ومتكررة.
تكلفة تشفير طبقة المقابس الآمنة: هناك تكلفة مرتبطة بتشفير طبقة المقابس الآمنة اللازم لتوفير اتصالات آمنة. في المتوسط، تبلغ هذه التكلفة حوالي 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.
البحث عن الأخطاء: إذا كانت تكاليف النطاق الترددي مرتفعة بشكل غير متوقّع، تأكَّد من أنّ تطبيقك لا يزامن بيانات أكثر أو يزامنها بشكل متكرّر أكثر مما كنت تنوي في الأصل. لتحديد المشاكل بدقة، استخدِم أداة Profiler لقياس عمليات القراءة وفعِّل تسجيل تصحيح الأخطاء في حِزم تطوير البرامج (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.
تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["\u003cbr /\u003e\n\nFirebase bills for the data you store in your database and all outbound network\ntraffic at the session layer (layer 5) of the OSI model. Storage is billed at\n$5 for each GB/month, evaluated daily. Billing is not affected by the location\nof your database. Outbound traffic includes connection and encryption overhead\nfrom all database operations and data downloaded through database reads. Both\ndatabase reads and writes can lead to connection costs on your bill. All\ntraffic to and from your database, including operations denied by security\nrules, leads to billable costs.\n\nSome common examples of billed traffic include:\n\n- **Data downloaded:** When clients get data from your database, Firebase charges for the downloaded data. Typically, this makes up the bulk of your bandwidth costs, but it isn't the only factor in your bill.\n- **Protocol overhead:** Some additional traffic between the server and clients is necessary to establish and maintain a session. Depending on the underlying protocol, this traffic might include: Firebase Realtime Database's realtime protocol overhead, WebSocket overhead, and HTTP header overhead. Each time a connection is established, this overhead, combined with any SSL encryption overhead, contributes to the connection costs. Although this isn't a lot of bandwidth for a single request, it can be a substantial part of your bill if your payloads are tiny or you make frequent, short connections.\n- **SSL encryption overhead:** There is a cost associated with the SSL encryption overhead necessary for secure connections. On average, this cost is approximately 3.5KB for the initial handshake, and approximately tens of bytes for TLS record headers on each outgoing message. For most apps, this is a small percentage of your bill. However, this can become a large percentage if your specific case requires a lot of SSL handshakes. For example, devices that don't support [TLS session tickets](https://tools.ietf.org/html/rfc5077) might require large numbers of SSL connection handshakes.\n- **Firebase console data:** Although this isn't usually a significant portion of Realtime Database costs, Firebase charges for data that you read and write from the Firebase console.\n\n| When your project is on the Blaze pricing plan, [**set up budget alerts**](/docs/projects/billing/avoid-surprise-bills#set-up-budget-alert-emails) using the console. You can use the [Blaze plan calculator](/pricing#blaze-calculator) to estimate your monthly costs.\n|\n| Be aware that **budget alerts do *not* cap your usage or\n| charges** --- they are *alerts* about your costs so that you can\n| take action, if needed. For example, you might consider\n| [using\n| budget notifications to programmatically disable Cloud Billing on a\n| project](https://cloud.google.com/billing/docs/how-to/disable-billing-with-notifications).\n\nEstimate your billed usage\n\nTo see your current Realtime Database connections and data usage, check the\n[Usage](https://console.firebase.google.com/project/_/database/usage/current-billing/)\ntab in the Firebase console. You can check usage over the current billing\nperiod, the last 30 days, or the last 24 hours.\n\nFirebase shows usage statistics for the following metrics:\n\n- **Connections:** The number of simultaneous, currently open, realtime connections to your database. This includes the following realtime connections: WebSocket, long polling, and HTML server-sent events. It does not include RESTful requests.\n- **Storage:** How much data is stored in your database. This doesn't include Firebase hosting or data stored through other Firebase products.\n- **Downloads:** All bytes downloaded from your database, including protocol and encryption overhead.\n- **Load:** This graph shows how much of your database is in use, processing requests, over a given 1-minute interval. You might see performance issues as your database approaches 100%.\n\nOptimize usage\n\nThere are a few best practices you can employ to optimize your database usage\nand bandwidth costs.\n\n- **Use the native SDKs:** Whenever possible, use the SDKs that correspond to your app's platform, instead of the REST API. The SDKs maintain open connections, reducing the SSL encryption costs that typically add up with the REST API.\n- **Check for bugs:** If your bandwidth costs are unexpectedly high, verify that your app isn't syncing more data or syncing more often than you originally intended. To pinpoint issues, use the [profiler tool](/docs/database/usage/profile) to measure your read operations and turn on debug logging in the [Android](https://firebase.google.com/docs/reference/android/com/google/firebase/database/Logger), [Objective-C](https://firebase.google.com/docs/reference/ios/firebasecore/api/reference/Enums/FIRLoggerLevel), and [Web](https://firebase.google.com/docs/reference/js/database#enablelogging) SDKs. Check background and sync processes in your app to make sure everything is working as you intended.\n- **Reduce connections:** If possible, try to optimize your connection bandwidth. Frequent, small REST requests can be more costly than a single, continuous connection using the native SDK. If you do use the REST API, consider using an HTTP keep-alive or [server-sent events](/docs/reference/rest/database#section-streaming), which can reduce costs from SSL handshakes.\n- **Use TLS session tickets:** Reduce SSL encryption overhead costs on resumed connections by issuing [TLS session tickets](https://tools.ietf.org/html/rfc5077). This is particularly helpful if you do require frequent, secure connections to the database.\n- **Index queries:** [Indexing your data](/docs/database/security/indexing-data) reduces the total bandwidth you use for queries, which has the double benefit of lowering your costs and increasing your database's performance. Use the profiler tool to [find unindexed queries](/docs/database/usage/profile#unindexed_queries) in your database.\n- **Optimize your listeners:** Add queries to limit the data that your listen operations return and use listeners that only download updates to data --- for example, `on()` instead of `once()`. Additionally, place your listeners as far down the path as you can to limit the amount of data they sync.\n- **Reduce storage costs:** Run periodic cleanup jobs and reduce any duplicate data in your database.\n- **Use Rules:** Prevent any potentially costly, unauthorized operations on your database. For example, using Firebase Realtime Database Security Rules could avoid a scenario where a malicious user repeatedly downloads your entire database. Learn more about [using Firebase Realtime Database Rules](/docs/database/security).\n\n| **Note about the profiler tool:** The profiler tool doesn't account for network traffic. It only records an estimate of the application data sent in responses. The profiler tool is intended to give you an overall picture of your database's performance, to help you monitor operations and troubleshoot issues, **not to estimate billing** . To learn more, see [the profiler tool documentation](/docs/database/usage/profile).\n\nThe best optimization plan for your app depends on your particular use case.\nWhile this isn't an exhaustive list of best practices, you can find\nmore advice and tips from the Firebase experts on our\n[Slack channel](https://firebase.community/)\nor on [Stack Overflow](https://stackoverflow.com/questions/tagged/firebase)."]]
