Abrechnung für Realtime Database

Wenn Ihr Projekt den kostenlosen Spark-Tarif nutzt, wird Ihnen die Nutzung von Realtime Database nicht in Rechnung gestellt. Sie erhalten eine kostenlose Nutzung, die 1 GB Datenspeicher und 10 GB/Monat Datendownloads umfasst.

Wenn Sie ein Upgrade auf das Blaze-Preismodell (Pay as you go) durchführen, können Sie die kostenlose Nutzung (1 GB Datenspeicher und 10 GB/Monat Datendownloads) beibehalten. Ihnen wird dann jede Nutzung über diesen Betrag hinaus in Rechnung gestellt. Wenn Ihr Projekt das Blaze-Preismodell nutzt, empfehlen wir, Budgetbenachrichtigungen für Ihr Projekt einzurichten.

Im Folgenden wird die Abrechnung ausführlicher beschrieben.

So berechnet Realtime Database die Abrechnung

Firebase stellt die Daten, die Sie in Ihrer Datenbank speichern, und den gesamten ausgehenden Netzwerkverkehr auf der Sitzungsschicht (Ebene 5) des OSI-Modells in Rechnung. Der Speicherplatz wird mit 5 $ pro GB/Monat abgerechnet und täglich ausgewertet. Die Abrechnung wird nicht vom Standort Ihrer Datenbank beeinflusst. Der ausgehende Traffic umfasst den Verbindungs- und Verschlüsselungs-Overhead aller Datenbankvorgänge und Daten, die über Datenbanklesevorgänge heruntergeladen werden. Sowohl Lese- als auch Schreibvorgänge in der Datenbank können zu Verbindungskosten auf Ihrer Rechnung führen. Der gesamte Traffic zu und von Ihrer Datenbank, einschließlich der von Sicherheitsregeln abgelehnten Vorgänge, führt zu abrechenbaren Kosten.

Hier einige gängige Beispiele für abgerechneten 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: Overhead des Echtzeitprotokolls 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. Dies ist zwar nicht viel Bandbreite für eine einzelne Anfrage, kann aber einen erheblichen Teil Ihrer Rechnung ausmachen, wenn Ihre Nutzlasten sehr klein sind oder Sie häufige, kurze Verbindungen herstellen.
  • SSL-Verschlüsselungsaufwand: Für den SSL-Verschlüsselungsaufwand, 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 einige Dutzend Byte für TLS-Datensatzheader bei jeder ausgehenden Nachricht. Bei den meisten Apps macht dies nur einen kleinen Prozentsatz Ihrer Rechnung aus. Dieser Prozentsatz kann jedoch steigen, wenn in Ihrem speziellen 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: Dies macht in der Regel keinen großen Teil der Realtime Database-Kosten aus. Firebase berechnet jedoch Gebühren für Daten, die Sie über die Firebase-Konsole lesen und schreiben.

Abgerechnete Nutzung schätzen

Ihre aktuellen Realtime Database-Verbindungen und die Datennutzung finden Sie in der Firebase-Konsole auf dem Tab Nutzung. 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 offenen Echtzeitverbindungen zu Ihrer Datenbank. Dazu gehören die folgenden Echtzeitverbindungen: WebSocket, Long Polling und HTML-Server-Sent-Events. RESTful-Anfragen sind nicht enthalten.
  • Speicher: Wie viele Daten in Ihrer Datenbank gespeichert sind. Dies umfasst nicht das Firebase-Hosting oder Daten, die über andere Firebase-Produkte gespeichert werden.
  • Downloads: Alle aus Ihrer Datenbank heruntergeladenen Byte, einschließlich Protokoll- und Verschlüsselungs-Overhead.
  • Last: In diesem Diagramm sehen Sie, wie viel Ihrer Datenbank in einem bestimmten einminütigen Intervall verwendet wird, um Anfragen zu verarbeiten. Wenn sich die Datenbank 100 % nähert, kann es zu Leistungsproblemen kommen.

Nutzung optimieren

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

  • Native SDKs verwenden: Verwenden Sie nach Möglichkeit die SDKs, die der Plattform Ihrer App entsprechen, anstatt der REST API. Die SDKs halten Verbindungen offen, wodurch die SSL-Verschlüsselungskosten reduziert werden, die bei der REST API normalerweise anfallen.
  • Auf Fehler prüfen:Wenn Ihre Bandbreitenkosten unerwartet hoch sind, prüfen Sie, ob Ihre App mehr Daten oder häufiger synchronisiert, als Sie ursprünglich beabsichtigt haben. Verwenden Sie das Profiler-Tool, um Probleme zu lokalisieren und Ihre Lesevorgänge zu messen. Aktivieren Sie außerdem das Debugging-Logging in den SDKs für Android, Objective-C und Web. Prüfe die Hintergrund- und Synchronisierungsprozesse in deiner App, um sicherzustellen, dass alles wie gewünscht funktioniert.
  • Verbindungen reduzieren: Versuchen Sie, wenn möglich, die Bandbreite Ihrer Verbindung zu optimieren. 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 vom Server gesendete Ereignisse verwenden, um die Kosten für SSL-Handshakes zu reduzieren.
  • TLS-Sitzungstickets verwenden: Reduzieren Sie die SSL-Verschlüsselungskosten für wiederaufgenommene Verbindungen, indem Sie TLS-Sitzungstickets ausstellen. Dies ist besonders hilfreich, wenn Sie häufige, sichere Verbindungen zur Datenbank benötigen.
  • Indexabfragen: Durch die Indexierung Ihrer Daten wird die Gesamtbandbreite reduziert, die Sie für Abfragen verwenden. Das hat den doppelten Vorteil, dass Ihre Kosten gesenkt und die Leistung Ihrer Datenbank erhöht wird. Verwenden Sie das Profiler-Tool, um nicht indexierte Abfragen in Ihrer Datenbank zu finden.
  • Listener optimieren: Fügen Sie Abfragen hinzu, um die von Ihren Abhörvorgängen zurückgegebenen Daten zu begrenzen, 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 synchronisierten Daten zu begrenzen.
  • Speicherkosten senken: Führen Sie regelmäßige 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 können Sie beispielsweise verhindern, dass 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 von Best Practices. Weitere Ratschläge und Tipps von Firebase-Experten finden Sie in unserem Slack-Kanal oder auf Stack Overflow.