So wählen Sie die richtige Datenbank für Ihre Anwendung aus

Die Auswahl der „richtigen“ Datenbank kann häufig entscheidend für den Erfolg einer Anwendung sein. Anstatt den Rat von Anbietern zu befolgen oder eine Datenbank zu verwenden, weil Sie diese bereits haben, ist es hilfreich, den grundlegenden Zweck und die Anforderungen des Datenspeichers zu berücksichtigen.

Dies sind die wichtigsten Fragen, die Sie bei der Auswahl einer Datenbank stellen müssen:

  • Wie viele Daten werden voraussichtlich gespeichert, wenn die Anwendung ausgereift ist?
  • Wie viele Benutzer werden voraussichtlich bei Spitzenlast gleichzeitig behandelt?
  • Welche Verfügbarkeit, Skalierbarkeit, Latenz, Durchsatz und Datenkonsistenz benötigt Ihre Anwendung?
  • Wie oft ändern sich Ihre Datenbankschemata?
  • Wie ist die geografische Verteilung Ihrer Benutzerpopulation?
  • Was ist die natürliche „Form“ Ihrer Daten?
  • Benötigt Ihre Anwendung Online-Transaktionsverarbeitung (OLTP), analytische Abfragen (OLAP) oder beides?
  • Welches Verhältnis von Lesevorgängen zu Schreibvorgängen erwarten Sie in der Produktion?
  • Benötigen Sie geografische Abfragen und / oder Volltextabfragen?
  • Was sind Ihre bevorzugten Programmiersprachen?
  • Hast du ein Budget? Wenn ja, werden Lizenzen und Supportverträge abgedeckt?
  • Gibt es gesetzliche Einschränkungen für Ihre Datenspeicherung?

Lassen Sie uns auf diese Fragen und ihre Auswirkungen eingehen.

Wie viele Daten werden Sie speichern?

Wenn Ihre Schätzung in Gigabyte oder weniger angegeben ist, verarbeitet fast jede Datenbank Ihre Daten, und In-Memory-Datenbanken sind vollständig realisierbar. Es gibt immer noch viele Datenbankoptionen für die Verarbeitung von Daten im Terabyte-Bereich (Tausende von Gigabyte).

Wenn Ihre Antwort in Petabyte (Millionen Gigabyte) oder mehr vorliegt, sind nur wenige Datenbanken hilfreich, und Sie müssen auf erhebliche Datenspeicherkosten vorbereitet sein, entweder bei den Investitionen für die lokale Speicherung oder bei den Betriebsausgaben für Cloud-Speicher. In dieser Größenordnung möchten Sie möglicherweise mehrstufigen Speicher, damit Abfragen zu "Live" -Daten aus Gründen der Geschwindigkeit im Speicher oder gegen lokale SSDs ausgeführt werden können, während sich der gesamte Datensatz aus wirtschaftlichen Gründen auf sich drehenden Festplatten befindet.

Wie viele Benutzer gleichzeitig?

Das Schätzen der Auslastung vieler gleichzeitiger Benutzer wird häufig als Übung zur Servergröße behandelt, die unmittelbar vor der Installation Ihrer Produktionsdatenbank durchgeführt werden muss. Leider können viele Datenbanken aufgrund von Skalierungsproblemen nicht mit Tausenden von Benutzern umgehen, die Terabyte oder Petabyte an Daten abfragen.

Das Schätzen gleichzeitiger Benutzer ist für eine von Mitarbeitern verwendete Datenbank viel einfacher als für eine öffentliche Datenbank. Für letztere müssen Sie möglicherweise die Option haben, für unerwartete oder saisonale Belastungen auf mehrere Server zu skalieren. Leider unterstützen nicht alle Datenbanken die horizontale Skalierung ohne zeitaufwändiges manuelles Sharding der großen Tabellen.

Was sind Ihre Anforderungen an die Fähigkeit?

In diese Kategorie fallen Verfügbarkeit, Skalierbarkeit, Latenz, Durchsatz und Datenkonsistenz, obwohl nicht alle Begriffe mit "-ility" enden.

Verfügbarkeit ist häufig ein Schlüsselkriterium für Transaktionsdatenbanken. Während nicht jede Anwendung mit einer Verfügbarkeit von 99,999% rund um die Uhr ausgeführt werden muss, tun dies einige. Einige Cloud-Datenbanken bieten eine Verfügbarkeit von fünf Neunen, sofern Sie sie in mehreren Verfügbarkeitszonen ausführen. Lokale Datenbanken können normalerweise für eine hohe Verfügbarkeit außerhalb geplanter Wartungsperioden konfiguriert werden, insbesondere wenn Sie es sich leisten können, ein Aktiv-Aktiv-Serverpaar einzurichten.

Die Skalierbarkeit, insbesondere die horizontale Skalierbarkeit, war in der Vergangenheit für NoSQL-Datenbanken besser als für SQL-Datenbanken, aber mehrere SQL-Datenbanken holen auf. Dynamische Skalierbarkeit ist in der Cloud viel einfacher zu erreichen. Datenbanken mit guter Skalierbarkeit können viele gleichzeitige Benutzer verarbeiten, indem sie vergrößert oder verkleinert werden, bis der Durchsatz für die Last ausreicht.

Die Latenz bezieht sich sowohl auf die Antwortzeit der Datenbank als auch auf die End-to-End-Antwortzeit der Anwendung. Im Idealfall hat jede Benutzeraktion eine Antwortzeit von weniger als einer Sekunde. Dies bedeutet häufig, dass die Datenbank für jede einfache Transaktion in weniger als 100 Millisekunden antworten muss. Analytische Abfragen können oft Sekunden oder Minuten dauern. Anwendungen können die Antwortzeit erhalten, indem sie komplizierte Abfragen im Hintergrund ausführen.

Der Durchsatz für eine OLTP-Datenbank wird normalerweise in Transaktionen pro Sekunde gemessen. Datenbanken mit hohem Durchsatz können viele gleichzeitige Benutzer unterstützen.

Die Datenkonsistenz ist für SQL-Datenbanken normalerweise „stark“, was bedeutet, dass alle Lesevorgänge die neuesten Daten zurückgeben. Die Datenkonsistenz kann für NoSQL-Datenbanken von „eventuell“ bis „stark“ reichen. Eine eventuelle Konsistenz bietet eine geringere Latenz bei dem Risiko, veraltete Daten zu lesen.

Konsistenz ist das „C“ in den ACID-Eigenschaften, das für die Gültigkeit bei Fehlern, Netzwerkpartitionen und Stromausfällen erforderlich ist. Die vier ACID-Eigenschaften sind Atomizität, Konsistenz, Isolation und Haltbarkeit.

Sind Ihre Datenbankschemata stabil?

Wenn sich Ihre Datenbankschemata im Laufe der Zeit wahrscheinlich nicht wesentlich ändern und Sie möchten, dass die meisten Felder von Datensatz zu Datensatz konsistente Typen aufweisen, sind SQL-Datenbanken eine gute Wahl für Sie. Andernfalls sind NoSQL-Datenbanken, von denen einige nicht einmal Schemas unterstützen, möglicherweise besser für Ihre Anwendung. Es gibt jedoch Ausnahmen. Rockset ermöglicht beispielsweise SQL-Abfragen, ohne den importierten Daten ein festes Schema oder konsistente Typen aufzuerlegen.

Geografische Verteilung der Benutzer

Wenn sich Ihre Datenbankbenutzer auf der ganzen Welt befinden, wird durch die Lichtgeschwindigkeit die Datenbanklatenz für die Remotebenutzer niedriger begrenzt, sofern Sie keine zusätzlichen Server in ihren Regionen bereitstellen. Einige Datenbanken ermöglichen verteilte Lese- / Schreibserver. Andere bieten verteilte schreibgeschützte Server an, bei denen alle Schreibvorgänge über einen einzelnen Master-Server ausgeführt werden müssen. Die geografische Verteilung macht den Kompromiss zwischen Konsistenz und Latenz noch schwieriger.

Die meisten Datenbanken, die global verteilte Knoten und eine starke Konsistenz unterstützen, verwenden Konsensgruppen, um das Schreiben zu beschleunigen, ohne die Konsistenz ernsthaft zu beeinträchtigen. In der Regel werden die Algorithmen Paxos (Lamport, 1990) oder Raft (Ongaro und Ousterhout, 2013) verwendet. Verteilte NoSQL-Datenbanken, die letztendlich konsistent sind, verwenden normalerweise eine nicht konsensfähige Peer-to-Peer-Replikation. Dies kann zu Konflikten führen, wenn zwei Replikate gleichzeitig in denselben Datensatz schreiben. Diese Konflikte werden normalerweise heuristisch gelöst.

Datenform

SQL-Datenbanken speichern klassisch stark typisierte Daten klassisch in rechteckigen Tabellen mit Zeilen und Spalten. Sie basieren auf definierten Beziehungen zwischen Tabellen, verwenden Indizes, um ausgewählte Abfragen zu beschleunigen, und verwenden JOINS, um mehrere Tabellen gleichzeitig abzufragen. Dokumentdatenbanken speichern normalerweise schwach typisiertes JSON, das Arrays und verschachtelte Dokumente enthalten kann. Diagrammdatenbanken speichern entweder Scheitelpunkte und Kanten oder Tripel oder Quads. Andere NoSQL-Datenbankkategorien umfassen Schlüsselwert- und Spaltenspeicher.

Manchmal werden die Daten in einer Form generiert, die auch für die Analyse geeignet ist. manchmal ist es nicht und eine Transformation wird notwendig sein. Manchmal baut eine Datenbank auf einer anderen auf. Beispielsweise können Schlüsselwertspeicher fast jeder Art von Datenbank zugrunde liegen.

OLTP, OLAP oder HTAP?

Um die oben genannten Akronyme zu entschlüsseln, stellt sich die Frage, ob Ihre Anwendung eine Datenbank für Transaktionen, Analysen oder beides benötigt. Schnelle Transaktionen erfordern eine schnelle Schreibgeschwindigkeit und minimale Indizes. Eine Analyse erfordert eine schnelle Lesegeschwindigkeit und viele Indizes. Hybridsysteme verwenden verschiedene Tricks, um beide Anforderungen zu unterstützen, einschließlich eines primären Transaktionsspeichers, der einen sekundären Analysespeicher durch Replikation versorgt.

Lese- / Schreibverhältnis

Einige Datenbanken sind beim Lesen und Abfragen schneller, andere beim Schreiben schneller. Die Mischung aus Lese- und Schreibvorgängen, die Sie von Ihrer Anwendung erwarten, ist eine nützliche Zahl, die Sie in Ihre Datenbankauswahlkriterien aufnehmen können, und kann Ihre Benchmarking-Bemühungen leiten. Die optimale Auswahl des Indextyps unterscheidet sich zwischen leselastigen Anwendungen (normalerweise ein B-Baum) und schreibintensiven Anwendungen (häufig ein logarithmisch strukturierter Zusammenführungsbaum, auch bekannt als LSM-Baum).

Geodaten und Abfragen

Wenn Sie über geografische oder geometrische Daten verfügen und effiziente Abfragen durchführen möchten, um Objekte innerhalb einer Grenze oder Objekte innerhalb einer bestimmten Entfernung von einem Ort zu finden, benötigen Sie andere Indizes als bei typischen relationalen Daten. Ein R-Baum ist häufig die bevorzugte Wahl für Geodatenindizes, es gibt jedoch mehr als ein Dutzend anderer möglicher Geodatenindexdatenstrukturen. Es gibt ein paar Dutzend Datenbanken, die Geodaten unterstützen. Die meisten unterstützen einige oder alle Standards des Open Geospatial Consortium.

Volltextindizes und Abfragen

Ebenso erfordert eine effiziente Volltextsuche in Textfeldern andere Indizes als relationale oder geografische Daten. In der Regel erstellen Sie einen invertierten Listenindex mit Token-Wörtern und suchen diesen, um einen kostspieligen Tabellenscan zu vermeiden.

Bevorzugte Programmiersprachen

Während die meisten Datenbanken APIs für viele Programmiersprachen unterstützen, kann die bevorzugte Programmiersprache in Ihrer Anwendung manchmal Ihre Datenbankauswahl beeinflussen. Beispielsweise ist JSON das natürliche Datenformat für JavaScript. Daher möchten Sie möglicherweise eine Datenbank auswählen, die den JSON-Datentyp für eine JavaScript-Anwendung unterstützt. Wenn Sie eine stark typisierte Programmiersprache verwenden, möchten Sie möglicherweise eine stark typisierte Datenbank auswählen.

Budgetbeschränkungen

Die Preise für Datenbanken reichen von kostenlos bis sehr teuer. Viele Datenbanken haben sowohl kostenlose als auch kostenpflichtige Versionen und manchmal mehr als eine Stufe des kostenpflichtigen Angebots, z. B. eine Enterprise-Version und unterschiedliche Service-Antwortzeiten. Darüber hinaus sind einige Datenbanken in der Cloud zu Pay-as-you-go-Bedingungen verfügbar.

Wenn Sie sich für eine kostenlose Open Source-Datenbank entscheiden, müssen Sie möglicherweise auf die Unterstützung von Anbietern verzichten. Solange Sie intern über Fachwissen verfügen, kann dies in Ordnung sein. Auf der anderen Seite kann es für Ihre Mitarbeiter produktiver sein, sich auf die Anwendung zu konzentrieren und die Datenbankverwaltung und -wartung Anbietern oder Cloud-Anbietern zu überlassen.

Rechtliche Beschränkungen

Es gibt viele Gesetze zur Datensicherheit und zum Datenschutz. In der EU hat die DSGVO weitreichende Auswirkungen auf die Privatsphäre, den Datenschutz und den Speicherort von Daten. In den USA regelt die HIPAA medizinische Informationen und die GLBA regelt den Umgang von Finanzinstituten mit privaten Informationen von Kunden. In Kalifornien verbessert die neue CCPA die Datenschutzrechte und den Verbraucherschutz.

Einige Datenbanken sind in der Lage, Daten so zu verarbeiten, dass einige oder alle dieser Vorschriften eingehalten werden, sofern Sie die Best Practices befolgen. Andere Datenbanken weisen Mängel auf, die es sehr schwierig machen, sie für persönlich identifizierbare Informationen zu verwenden, egal wie vorsichtig Sie sind.

Ehrlich gesagt war dies eine lange Liste von Faktoren, die bei der Auswahl einer Datenbank berücksichtigt werden mussten, wahrscheinlich mehr, als Sie bevorzugen würden. Es lohnt sich jedoch, alle Fragen nach besten Kräften Ihres Teams zu beantworten, bevor Sie das Risiko eingehen, Ihr Projekt in eine unzureichende oder übermäßig teure Datenbank zu übertragen.