Abrechnung für Realtime Database

Wenn Ihr Projekt den kostenlosen Spark-Tarif nutzt, werden Ihnen keine Kosten für die Nutzung von Realtime Database in Rechnung gestellt. Sie erhalten eine kostenlose Nutzung, die 1 GB Datenspeicher und 10 GB Daten-Downloads pro Monat umfasst.

Wenn Sie auf den Blaze-Tarif mit nutzungsabhängiger Bezahlung umsteigen, behalten Sie die kostenlose Nutzung bei (1 GB Datenspeicher und 10 GB Daten-Downloads pro Monat). Für jede Nutzung über dieses Kontingent hinaus werden Ihnen Kosten in Rechnung gestellt. Wenn Ihr Projekt das Blaze-Preismodell nutzt, empfehlen wir, Budgetbenachrichtigungen für Ihr Projekt einzurichten.

Im Rest dieser Seite wird die Abrechnung genauer beschrieben.

So werden die Kosten für Realtime Database berechnet

Firebase stellt Ihnen die in Ihrer Datenbank gespeicherten Daten und den gesamten ausgehenden Netzwerk-Traffic auf der Sitzungsebene (Ebene 5) des OSI-Modells in Rechnung. Für den Speicher werden 5 $ pro GB und Monat berechnet. Die Berechnung erfolgt täglich. Der Standort Ihrer Datenbank hat keinen Einfluss auf die Abrechnung. Der ausgehende Traffic umfasst den Verbindungs- und Verschlüsselungs-Overhead aller Datenbankvorgänge und Daten, die durch Datenbanklesevorgänge heruntergeladen werden. Sowohl Datenbanklese- als auch -schreibvorgänge können zu Verbindungskosten auf Ihrer Rechnung führen. Für den gesamten Traffic zu und von Ihrer Datenbank, einschließlich Vorgängen, die durch Sicherheitsregeln abgelehnt werden, fallen Kosten an.

Einige häufige Beispiele für kostenpflichtigen Traffic:

  • Heruntergeladene Daten:Wenn Clients Daten aus Ihrer Datenbank abrufen, berechnet Firebase die heruntergeladenen Daten. In der Regel macht dies den Großteil Ihrer Bandbreitenkosten aus, ist aber nicht der einzige Faktor auf Ihrer Rechnung.
  • Protokoll-Overhead:Für das Einrichten und Aufrechterhalten einer Sitzung ist zusätzlicher Traffic zwischen dem Server und den Clients erforderlich. Je nach zugrunde liegendem Protokoll kann dieser Traffic Folgendes umfassen: Realtime-Protokoll-Overhead der Firebase Realtime Database, WebSocket-Overhead und HTTP-Header-Overhead. Jedes Mal, wenn eine Verbindung hergestellt wird, trägt dieser Overhead zusammen mit dem SSL-Verschlüsselungs-Overhead zu den Verbindungskosten bei. Obwohl dies für eine einzelne Anfrage nicht viel Bandbreite ist, kann es einen erheblichen Teil Ihrer Rechnung ausmachen, wenn Ihre Nutzlasten klein sind oder Sie häufige, kurze Verbindungen herstellen.
  • SSL-Verschlüsselungs-Overhead:Für den SSL-Verschlüsselungs-Overhead, der für sichere Verbindungen erforderlich ist, fallen Kosten an. Im Durchschnitt betragen diese Kosten etwa 3,5 KB für den ersten Handshake und etwa zehn Byte für TLS-Datensatzheader in jeder ausgehenden Nachricht. Für die meisten Apps macht dies einen kleinen Prozentsatz Ihrer Rechnung aus. Dies kann jedoch ein großer Prozentsatz sein, wenn in Ihrem Fall viele SSL-Handshakes erforderlich sind. Beispielsweise können Geräte die keine TLS-Sitzungstickets unterstützen, eine große Anzahl von SSL-Verbindungs-Handshakes erfordern.
  • Firebase Konsolendaten: Obwohl dies in der Regel keinen erheblichen Teil der Realtime Database Kosten ausmacht, berechnet Firebase die Daten, die Sie in der Firebase Konsole lesen und schreiben.

Kostenpflichtige Nutzung schätzen

Auf dem Tab „Nutzung“ in der Firebase Konsole können Sie Ihre aktuellen Realtime Database Verbindungen und die Datennutzung einsehen. Sie können die Nutzung für den aktuellen Abrechnungszeitraum, die letzten 30 Tage oder die letzten 24 Stunden prüfen.

Firebase zeigt Nutzungsstatistiken für die folgenden Messwerte an:

  • Verbindungen:Die Anzahl der gleichzeitigen, derzeit geöffneten Echtzeitverbindungen zu Ihrer Datenbank. Dazu gehören die folgenden Echtzeitverbindungen: WebSocket, Long Polling und HTML-Server-Sent Events. RESTful-Anfragen sind nicht enthalten.
  • Speicher:Die Menge der in Ihrer Datenbank gespeicherten Daten. Firebase-Hosting oder Daten, die über andere Firebase-Produkte gespeichert wurden, sind nicht enthalten.
  • Downloads:Alle aus Ihrer Datenbank heruntergeladenen Byte, einschließlich Protokoll- und Verschlüsselungs-Overhead.
  • Last:In diesem Diagramm wird angezeigt, wie viel von Ihrer Datenbank in einem bestimmten 1-Minuten-Intervall verwendet wird und Anfragen verarbeitet. Wenn sich die Auslastung Ihrer Datenbank 100 % nähert, können Leistungsprobleme auftreten.

Nutzung optimieren

Es gibt einige Best Practices, mit denen Sie die Nutzung Ihrer Datenbank und die Bandbreitenkosten optimieren können.

  • Native SDKs verwenden:Verwenden Sie nach Möglichkeit die SDKs, die der Plattform Ihrer App entsprechen, anstelle der REST API. Die SDKs halten offene Verbindungen aufrecht, wodurch die Kosten für die SSL-Verschlüsselung reduziert werden, die sich normalerweise bei der REST API summieren.
  • Auf Fehler prüfen:Wenn Ihre Bandbreitenkosten unerwartet hoch sind, prüfen Sie, ob Ihre App mehr Daten oder häufiger synchronisiert als ursprünglich beabsichtigt. Verwenden Sie das Profiler-Tool, um Probleme zu ermitteln, Ihre Lesevorgänge zu messen und die Debug-Protokollierung in den Android, Objective-C und Web SDKs zu aktivieren. Prüfen Sie die Hintergrund- und Synchronisierungsprozesse in Ihrer App, um sicherzustellen, dass alles wie beabsichtigt funktioniert.
  • Verbindungen reduzieren:Optimieren Sie nach Möglichkeit die Bandbreite Ihrer Verbindung. Häufige, kleine REST-Anfragen können teurer sein als eine einzelne, kontinuierliche Verbindung mit dem nativen SDK. Wenn Sie die REST API verwenden, sollten Sie HTTP-Keep-Alive oder Server-Sent Events, verwenden, um die Kosten für SSL-Handshakes zu senken.
  • TLS-Sitzungstickets verwenden: Reduzieren Sie die Kosten für den SSL-Verschlüsselungs-Overhead bei wiederaufgenommenen Verbindungen, indem Sie TLS-Sitzungstickets ausstellen. Dies ist besonders hilfreich, wenn Sie häufige, sichere Verbindungen zur Datenbank benötigen.
  • Abfragen indexieren: Durch das Indexieren Ihrer Daten wird die für Abfragen verwendete Gesamtbandbreite reduziert. Das hat den doppelten Vorteil, dass Ihre Kosten sinken und die Leistung Ihrer Datenbank steigt. Verwenden Sie das Profiler-Tool, um nicht indexierte Abfragen in Ihrer Datenbank zu finden.
  • Listener optimieren:Fügen Sie Abfragen hinzu, um die Daten zu begrenzen, die von Ihren Listener-Vorgängen zurückgegeben werden, und verwenden Sie Listener, die nur Aktualisierungen von Daten herunterladen, z. B. on() anstelle von once(). Platzieren Sie Ihre Listener außerdem so weit unten im Pfad wie möglich, um die Menge der Daten zu begrenzen, die sie synchronisieren.
  • Speicherkosten senken:Führen Sie regelmäßig Bereinigungsjobs aus und reduzieren Sie doppelte Daten in Ihrer Datenbank.
  • Regeln verwenden:Verhindern Sie potenziell kostspielige, nicht autorisierte Vorgänge in Ihrer Datenbank. Mit Firebase Realtime Database Security Rules lässt sich beispielsweise ein Szenario vermeiden, in dem ein böswilliger Nutzer Ihre gesamte Datenbank wiederholt herunterlädt. Weitere Informationen zur Verwendung von Firebase Realtime Database-Regeln .

Der beste Optimierungsplan für Ihre App hängt von Ihrem jeweiligen Anwendungsfall ab. Dies ist keine vollständige Liste der Best Practices. Weitere Ratschläge und Tipps von den Firebase-Experten finden Sie in unserem Slack-Channel oder auf Stack Overflow.