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 Daten-Downloads pro Monat umfasst.

Wenn Sie ein Upgrade auf das Blaze-Preismodell (Pay as you go) durchführen, behalten Sie die kostenlose Nutzung (1 GB Datenspeicher und 10 GB Daten-Downloads pro Monat) bei und werden für jede Nutzung über diesen Betrag hinaus abgerechnet. Wenn Ihr Projekt das Blaze-Preismodell nutzt, empfehlen wir, Budgetbenachrichtigungen für Ihr Projekt einzurichten.

Im Folgenden wird die Abrechnung genauer beschrieben.

So berechnet Realtime Database die Abrechnung

Firebase berechnet die Daten, die Sie in Ihrer Datenbank speichern, und den gesamten ausgehenden Netzwerkverkehr auf der Sitzungsebene (Ebene 5) des OSI-Modells. Die Speicherung wird täglich abgerechnet und kostet 5 $ pro GB und Monat. Die Abrechnung ist nicht vom Standort Ihrer Datenbank abhängig. Ausgehender Traffic umfasst den Overhead für Verbindung und Verschlüsselung aus allen Datenbankvorgängen und Daten, die durch 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 Vorgänge, die durch Sicherheitsregeln abgelehnt werden, führt zu abrechenbaren Kosten.

Hier einige typische Beispiele für abgerechneten Traffic:

  • Heruntergeladene Daten:Wenn Clients Daten aus Ihrer Datenbank abrufen, berechnet Firebase die heruntergeladenen Daten. In der Regel machen diese Kosten den Großteil Ihrer Bandbreitenkosten aus, sind 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 von Firebase Realtime Database, WebSocket-Overhead und HTTP-Header-Overhead. Jedes Mal, wenn eine Verbindung hergestellt wird, trägt dieser Overhead in Kombination mit dem Overhead der SSL-Verschlüsselung zu den Verbindungskosten bei. Das ist zwar nicht viel Bandbreite für eine einzelne Anfrage, kann aber einen erheblichen Teil Ihrer Rechnung ausmachen, wenn Ihre Nutzlasten klein sind oder Sie häufige, kurze Verbindungen herstellen.
  • SSL-Verschlüsselungs-Overhead:Für die SSL-Verschlüsselung, die für sichere Verbindungen erforderlich ist, fallen Kosten an. Im Durchschnitt betragen die Kosten für den ersten Handshake etwa 3,5 KB und für TLS-Datensatzheader in jeder ausgehenden Nachricht etwa zehn Byte. Bei den meisten Apps macht dies nur einen kleinen Prozentsatz Ihrer Rechnung aus. Das kann jedoch einen großen Prozentsatz ausmachen, wenn in Ihrem speziellen Fall viele SSL-Handshakes erforderlich sind. Beispielsweise können Geräte, die TLS-Sitzungstickets nicht 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, fallen für Daten, die Sie in der Firebase-Konsole lesen und schreiben, Firebase-Gebühren an.

Abgerechnete Nutzung schätzen

Ihre aktuellen Realtime Database-Verbindungen und die Datennutzung können Sie in der Firebase-Konsole auf dem Tab Nutzung 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 offenen Echtzeitverbindungen zu Ihrer Datenbank. Dazu gehören die folgenden Echtzeitverbindungen: WebSocket, Long Polling und vom HTML-Server gesendete Ereignisse. RESTful-Anfragen sind nicht enthalten.
  • Speicher:Die Menge der in Ihrer Datenbank gespeicherten Daten. Firebase-Hosting oder Daten, die mit anderen Firebase-Produkten gespeichert wurden, sind nicht enthalten.
  • Downloads:Alle aus Ihrer Datenbank heruntergeladenen Bytes, einschließlich Protokoll- und Verschlüsselungs-Overhead.
  • Auslastung:In diesem Diagramm sehen Sie, wie viel von Ihrer Datenbank in einem bestimmten 1-Minuten-Intervall für die Verarbeitung von Anfragen verwendet wird. Wenn sich Ihre Datenbank dem Grenzwert von 100 % nähert, können Leistungsprobleme auftreten.

Nutzung optimieren

Es gibt einige Best Practices, mit denen Sie Ihre Datenbanknutzung und 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 Verbindungen offen, wodurch die Kosten für die SSL-Verschlüsselung gesenkt 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 ursprünglich vorgesehen. Verwenden Sie das Profiler-Tool, um Probleme zu ermitteln, Ihre Lesevorgänge zu messen und das Debugging-Logging 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 vorgesehen 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 über das native 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 den Aufwand für die SSL-Verschlüsselung bei fortgesetzten Verbindungen, indem Sie TLS-Sitzungstickets ausstellen. Dies ist besonders hilfreich, wenn Sie häufig sichere Verbindungen zur Datenbank benötigen.
  • Indexabfragen:Wenn Sie Ihre Daten indexieren, verringert sich die für Abfragen verwendete Gesamtbandbreite. Das hat den doppelten Vorteil, dass Ihre Kosten sinken und die Leistung Ihrer Datenbank steigt. Mit dem Profiler-Tool können Sie nicht indexierte Abfragen in Ihrer Datenbank finden.
  • Listener optimieren:Fügen Sie Abfragen hinzu, um die von Ihren Listen-Vorgängen zurückgegebenen Daten zu begrenzen, und verwenden Sie Listener, die nur Updates für Daten herunterladen, z. B. on() anstelle von once(). Außerdem sollten Sie die Listener so weit wie möglich unten im Pfad platzieren, um die Menge der synchronisierten Daten zu begrenzen.
  • 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. Wenn Sie beispielsweise Firebase Realtime Database Security Rules verwenden, können Sie 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 der Best Practices. Weitere Ratschläge und Tipps von den Firebase-Experten finden Sie in unserem Slack-Channel oder auf Stack Overflow.