Sie haben ein Softwareprodukt? Fügen Sie es kostenlos hinzu. Eine Person liest es und veröffentlicht es innerhalb eines Tages.Sie haben ein Produkt? Kostenlos hinzufügen.

Produkt hinzufügen
Produkt hinzufügen

Datenbanken

Daten speichern und schnell wieder abrufen.

Datenbanken

In dieser Kategorie gibt es noch keine Produkte

Bisher ist hier nichts eingetragen. Wenn Sie ein Produkt entwickeln, das in dieses Regal gehört, fügen Sie es hinzu, und eine Person liest es.

Produkt hinzufügen

Was in diesem Regal steht

Orte, um Daten aufzubewahren und schnell wieder abzurufen: relationale Engines, Dokumentenspeicher, Key-Value-Caches, Suchindizes, Zeitreihenspeicher und die Managed Services, die jedes davon für Sie betreiben.

Die meisten Teams brauchen weniger davon, als Anbieter nahelegen. Eine relationale Datenbank trägt die Mehrzahl der Anwendungen sehr lange, und eine zweite Engine bringt einen zweiten Satz an Ausfällen, Backups und Leuten, die sie verstehen.

Analyse und Berichte über diese Daten gehören zu Analytics. Wo die Anwendung selbst läuft, ist Hosting und Cloud.

Eine Engine wählen

Gehen Sie von der Form Ihrer Daten und den Fragen aus, die Sie daran stellen werden.

Relationale Engines passen zu allem mit Beziehungen, Transaktionen, Constraints und Berichten, und das beschreibt den Großteil der Business-Software.

Die übrigen sind Spezialisten. Dokumentenspeicher passen zu Datensätzen, die in der Form variieren und meist ganz gelesen werden. Key-Value-Speicher sind für Tempo bei einfachen Abfragen. Suchindizes gibt es, weil die relationale Textsuche ab einer gewissen Größe nicht mehr reicht, und Zeitreihenspeicher, weil Metriken schneller eintreffen als alles andere.

Der ehrliche Standard ist eine relationale Engine, bis etwas ihre Unzulänglichkeit beweist. Teams, die mit einem exotischen Speicher beginnen, um ein Skalierungsproblem zu vermeiden, das sie nicht haben, begegnen meist zuerst einem anderen, schlimmeren Problem.

Kompatibilität zählt mehr als Markenname. Eine Engine, die ein weit verbreitetes Protokoll spricht, gibt Ihnen Tools, Treiber, Personalsuche und einen Ausstieg. Eine proprietäre Schnittstelle gibt Ihnen ein Migrationsprojekt.

Managed, selbst gehostet oder Serverless

Managed Services verlangen einen Aufpreis und nehmen Arbeit ab, die Sie sonst zu unpassenden Zeiten machen würden: Patches, Versions-Upgrades, Failover, Prüfung der Backups.

Selbst zu hosten ist auf dem Papier billiger und in der Praxis nur billiger, wenn das Können schon im Haus ist. Zählen Sie die Stunden ehrlich, auch die an dem Abend, an dem eine Platte vollläuft.

Serverless-Angebote skalieren die Kapazität mit der Last und berechnen im Leerlauf wenig. Das passt zu ungleichmäßigem Traffic und noch besser zu Entwicklungsumgebungen. Prüfen Sie das Kaltstartverhalten, die Verbindungslimits und wie die Abrechnung einen Hintergrundjob behandelt, der nie aufhört.

Die Fragen, die die Zuverlässigkeit entscheiden

  • Backups: wie oft, wie lange sie aufbewahrt werden und ob Sie auf einen gewählten Zeitpunkt zurückstellen können.
  • Wiederherstellung: wie lange eine vollständige bei Ihrer Datengröße dauert, getestet statt versprochen.
  • Failover: automatisch oder manuell, wie lange es dauert und was die Anwendung währenddessen sieht.
  • Replikation: Lesereplikate, regionsübergreifende Kopien und die Verzögerung, die Ihr Code tolerieren muss.
  • Verbindungen: die Obergrenze und ob Pooling enthalten ist oder etwas, das Sie selbst betreiben müssen.

Führen Sie in der Testphase eine Wiederherstellung durch. Ein Backup, das niemand wiederhergestellt hat, ist eine Hoffnung, und das ist die Kategorie, in der Hoffnung am teuersten ist.

Wachstum, Migrationen und die Teile, die später wehtun

Schemaänderungen an einer großen Tabelle sind die Operation, die Wochenenden ruiniert. Fragen Sie, wie die Engine das Hinzufügen einer Spalte, das Ändern eines Typs oder den Aufbau eines Index bei laufendem Traffic handhabt.

Halten Sie Migrationen von Tag eins an in der Versionskontrolle neben der Anwendung. Die Alternative, von Hand in einer Konsole angewandte Änderungen, erzeugt Umgebungen, die sich auf eine Weise unterscheiden, die niemand rekonstruieren kann.

Achten Sie auch auf den Speicherort der Daten. Eine Datenbank in einer anderen Region als die Anwendung fügt jeder Abfrage Latenz hinzu, und eine Anwendung mit fünfzig Abfragen pro Seite spürt das deutlich.

Wie die Rechnung zustande kommt

Rechenleistung, Speicher, Backup-Speicher, Netzwerk-Egress und bei manchen Diensten eine Einheit für Lese- und Schreibzugriffe.

Egress ist die Zeile, die Leute überrascht, besonders wenn Analytics oder Replikate große Mengen über Regionen ziehen. Speicher schrumpft selten von selbst, gelöschte Zeilen werden also womöglich weiter bezahlt, bis die Wartung läuft. Entwicklungs- und Staging-Kopien verdoppeln alles, sofern sie nicht verkleinert oder über Nacht gestoppt werden.

Fragen Sie, wie hoch der Preis beim Dreifachen des heutigen Volumens wird, nicht beim heutigen, denn das ist die Zahl, die Sie tatsächlich zahlen werden. Verwandte Gewohnheiten sind in was Preisseiten verschweigen gesammelt.

Praktiken, die eine Datenbank langweilig halten

Das Ziel in dieser Kategorie ist die Abwesenheit von Drama, und wenige Gewohnheiten erzeugen das meiste davon.

Halten Sie Migrationen in der Versionskontrolle und wenden Sie sie in jeder Umgebung gleich an. Manuelle Änderungen in einer Konsole erzeugen Unterschiede, die später niemand rekonstruieren kann.

Legen Sie Indizes bewusst an und prüfen Sie sie gelegentlich, denn ungenutzte kosten Schreibleistung und Speicher und sehen harmlos aus.

Beobachten Sie langsame Abfragen als Routine und nicht erst bei einem Vorfall. Die Abfrage, die heute vier Sekunden braucht, ist im nächsten Quartal der Ausfall, wenn die Tabelle gewachsen ist.

Und stellen Sie nach Plan ein Backup wieder her. Eine Kopie, die nie wiederhergestellt wurde, ist eine Datei und keine Absicherung, und das ist die Kategorie, in der es am teuersten ist, das spät zu entdecken.

Fragen, die Leute stellen

Managed Service oder selbst gehostet?

Managed kostet pro Monat mehr und insgesamt weniger, wenn man Patches, Upgrades, Backups und die Nacht mitzählt, in der jemand wach sein muss. Selbst hosten lohnt sich, wenn das betriebliche Können schon da ist und Sie Kontrolle über Platzierung oder Tuning brauchen.

Was bedeutet Serverless bei einer Datenbank?

Die Kapazität skaliert mit der Last, und Leerlauf kostet wenig oder nichts. Gut für ungleichmäßigen Traffic und Entwicklungsumgebungen. Achten Sie auf Kaltstarts, Verbindungslimits und die Rechnung, wenn ein Hintergrundjob dauerhaft läuft.

Wie vermeide ich einen Lock-in?

Bevorzugen Sie Engines mit offener Implementierung, die Sie anderswo betreiben könnten, halten Sie Schemaänderungen in Migrationsdateien und testen Sie einmal eine Wiederherstellung in eine gewöhnliche Instanz. Proprietäre Erweiterungen machen den Ausstieg still teuer.

Wo sollte die Datenbank relativ zur Anwendung stehen?

In derselben Region, idealerweise in derselben Zone. Wenige Millisekunden pro Abfrage werden zu Sekunden pro Seite, sobald eine Anwendung fünfzig davon stellt, und kein Caching versteckt eine schlecht platzierte Primärinstanz.

Wie wird der Preis üblicherweise berechnet?

Rechenleistung, Speicher, Backups, Netzwerk-Egress und manchmal Leseeinheiten, jeweils getrennt abgerechnet. Egress und regionsübergreifende Replikation sind die beiden Zeilen, die im ersten vollen Monat größer ausfallen als erwartet.