So wählen Sie den richtigen Datenbanktyp für Ihr Unternehmen aus

Es gibt Hunderte von technikintensiven Datenbanküberprüfungen, die jedoch nicht immer klare Hinweise für den ersten Schritt bei der Auswahl einer Datenbank geben: Auswahl des besten allgemeinen Typs für eine bestimmte Anwendung. Nicht alle Datenbanken sind gleich. Jeder hat spezifische Stärken und Schwächen. Zwar gibt es Problemumgehungen, damit eine bevorzugte Datenbank für die meisten Projekte funktioniert, doch die Verwendung dieser Tricks führt zu unnötiger Komplexität.

Bevor Sie sich für eine bestimmte Datenbank entscheiden, sollten Sie sich überlegen, welcher Typ das vorliegende Projekt am besten unterstützt. Die Frage geht tiefer als "SQL vs. NoSQL". Lesen Sie weiter, um einen Überblick über die gängigsten Datenbanktypen, die jeweiligen relativen Vorteile und die Ermittlung der am besten geeigneten Datenbanktypen zu erhalten.

Relationale Datenbankverwaltungssysteme (Oracle, MySQL, MS Server, PostgreSQL)

In den 1970er Jahren wurden relationale Datenbanken entwickelt, um die zunehmende Datenflut zu bewältigen. Sie haben eine solide Grundtheorie und haben nahezu jedes heute verwendete Datenbanksystem beeinflusst.

Relationale Datenbanken speichern Datensätze als „Beziehungen“: Tabellen mit Zeilen und Spalten, in denen alle Informationen als Wert einer bestimmten Zelle gespeichert werden. Daten in einem RDBMS werden mit SQL verwaltet. Obwohl es verschiedene Implementierungen gibt, ist SQL standardisiert und bietet ein Maß an Vorhersagbarkeit und Nützlichkeit.

Nachdem eine frühe Flut von Anbietern versucht hatte, die Popularität des Systems bei nicht ganz relationalen Produkten auszunutzen, skizzierte der Entwickler EF Codd eine Reihe von Regeln, die von allen relationalen Datenbankverwaltungssystemen befolgt werden müssen. Die 12 Regeln von Codd drehen sich darum, strenge interne Strukturprotokolle festzulegen, sicherzustellen, dass Suchvorgänge die angeforderten Daten zuverlässig zurückgeben, und strukturelle Änderungen (zumindest durch Benutzer) zu verhindern. Das Framework stellte sicher, dass relationale Datenbanken bis heute konsistent und zuverlässig sind.

Stärken

Relationale Datenbanken zeichnen sich durch die Verarbeitung stark strukturierter Daten aus und bieten Unterstützung für ACID-Transaktionen (Atomicity, Consistency, Isolation und Durability). Daten können mithilfe von SQL-Abfragen einfach gespeichert und abgerufen werden. Die Struktur kann schnell vergrößert werden, da das Hinzufügen von Daten ohne Änderung vorhandener Daten einfach ist.

Das Erstellen von Beschränkungen für den Zugriff oder die Änderung bestimmter Benutzertypen ist in die Struktur eines RDBMS integriert. Aus diesem Grund eignen sich relationale Datenbanken gut für Anwendungen, die einen mehrstufigen Zugriff erfordern. Beispielsweise können Kunden ihre Konten anzeigen, während Agenten die erforderlichen Änderungen anzeigen und vornehmen können.

Schwächen

Die größte Schwäche relationaler Datenbanken ist der Spiegel ihrer größten Stärke. So gut sie mit strukturierten Daten umgehen können, so schwer haben sie es mit unstrukturierten Daten. Die Darstellung realer Entitäten im Kontext ist im Rahmen eines RDBMS schwierig. "Aufgeschnittene" Daten müssen aus Tabellen zu etwas besser lesbarem zusammengesetzt werden, und die Geschwindigkeit kann negativ beeinflusst werden. Das feste Schema reagiert auch nicht gut auf Änderungen.

Bei relationalen Datenbanken spielen die Kosten eine Rolle. Ihre Einrichtung und ihr Wachstum sind tendenziell teurer. Die horizontale Skalierung oder die Skalierung durch Hinzufügen weiterer Server ist normalerweise sowohl schneller als auch wirtschaftlicher als die vertikale Skalierung, bei der einem Server mehr Ressourcen hinzugefügt werden. Die Struktur relationaler Datenbanken erschwert den Prozess jedoch. Sharding (bei dem Daten horizontal partitioniert und auf eine Sammlung von Computern verteilt werden) ist erforderlich, um eine relationale Datenbank zu skalieren. Das Sharding relationaler Datenbanken unter Wahrung der ACID-Konformität kann eine Herausforderung sein.

Verwenden Sie eine relationale Datenbank für:

  • Situationen, in denen die Datenintegrität von größter Bedeutung ist (z. B. für Finanzanwendungen, Verteidigung und Sicherheit sowie private Gesundheitsinformationen)
  • Hoch strukturierte Daten
  • Automatisierung interner Prozesse

Dokumentenspeicher (MongoDB, Couchbase)

Ein Dokumentenspeicher ist eine nicht relationale Datenbank, in der Daten in JSON-, BSON- oder XML-Dokumenten gespeichert werden. Sie verfügen über ein flexibles Schema. Im Gegensatz zu SQL-Datenbanken, in denen Benutzer vor dem Einfügen von Daten das Schema einer Tabelle deklarieren müssen, erzwingen Dokumentenspeicher keine Dokumentstruktur. Dokumente können beliebige Daten enthalten. Sie haben Schlüssel-Wert-Paare, aber auch eingebettete Attribut-Metadaten, um das Abfragen zu vereinfachen.

Stärken

Dokumentenspeicher sind sehr flexibel. Sie verarbeiten semistrukturierte und unstrukturierte Daten gut. Benutzer müssen während der Einrichtung nicht wissen, welche Datentypen gespeichert werden. Dies ist daher eine gute Wahl, wenn nicht im Voraus klar ist, welche Art von Daten eingehen werden.

Benutzer können ihre gewünschte Struktur in einem bestimmten Dokument erstellen, ohne alle Dokumente zu beeinflussen. Das Schema kann ohne Ausfallzeiten geändert werden, was zu einer hohen Verfügbarkeit führt. Die Schreibgeschwindigkeit ist im Allgemeinen ebenfalls hoch.

Neben der Flexibilität mögen Entwickler Dokumentenspeicher, weil sie sich leicht horizontal skalieren lassen. Das für die horizontale Skalierung erforderliche Sharding ist viel intuitiver als bei relationalen Datenbanken, sodass Dokumentenspeicher schnell und effizient skaliert werden können.

Schwächen

Dokumentendatenbanken opfern die ACID-Konformität für Flexibilität. Auch wenn die Abfrage in einem Dokument durchgeführt werden kann, ist dies nicht für alle Dokumente möglich.

Verwenden Sie eine Dokumentendatenbank für:

  • Unstrukturierte oder semistrukturierte Daten
  • Content Management
  • Eingehende Datenanalyse
  • Rapid-Prototyping

Schlüsselwertspeicher (Redis, Memcached)

Ein Schlüsselwertspeicher ist eine Art nicht relationaler Datenbank, in der jeder Wert einem bestimmten Schlüssel zugeordnet ist. Es ist auch als assoziatives Array bekannt.

Der „Schlüssel“ ist eine eindeutige Kennung, die nur dem Wert zugeordnet ist. Schlüssel können alles sein, was das DBMS zulässt. In Redis können Schlüssel beispielsweise eine beliebige Binärsequenz bis zu 512 MB sein.

"Werte" werden als Blobs gespeichert und benötigen kein vordefiniertes Schema. Sie können nahezu jede Form annehmen: Zahlen, Zeichenfolgen, Zähler, JSON, XML, HTML, PHP, Binärdateien, Bilder, kurze Videos, Listen und sogar ein weiteres Schlüssel-Wert-Paar, das in einem Objekt gekapselt ist. In einigen DBMS kann der Datentyp angegeben werden, dies ist jedoch nicht obligatorisch.

Stärken

Dieser Datenbankstil hat viele positive Aspekte. Es ist unglaublich flexibel und kann eine Vielzahl von Datentypen problemlos verarbeiten. Schlüssel werden verwendet, um ohne Indexsuche oder Verknüpfungen direkt zum Wert zu gelangen, sodass die Leistung hoch ist. Portabilität ist ein weiterer Vorteil: Schlüsselwertspeicher können von einem System auf ein anderes verschoben werden, ohne dass Code neu geschrieben werden muss. Schließlich sind sie hochgradig horizontal skalierbar und haben insgesamt niedrigere Betriebskosten.

Schwächen

Flexibilität hat ihren Preis. Es ist unmöglich, Werte abzufragen, da sie als Blob gespeichert sind und nur als solche zurückgegeben werden können. Dies macht es schwierig, Teile von Werten zu melden oder zu bearbeiten. Auch sind nicht alle Objekte einfach als Schlüssel-Wert-Paare zu modellieren.

Verwenden Sie einen Schlüsselwertspeicher für:

  • Empfehlungen
  • Benutzerprofile und Einstellungen
  • Unstrukturierte Daten wie Produktbewertungen oder Blog-Kommentare
  • Sitzungsmanagement im Maßstab
  • Daten, auf die häufig zugegriffen wird, die jedoch nicht häufig aktualisiert werden

Breitspaltiger Laden (Cassandra, HBase)

Breitspaltige Speicher, auch Spaltenspeicher oder erweiterbare Datensatzspeicher genannt, sind dynamische spaltenorientierte nicht relationale Datenbanken. Sie werden manchmal als eine Art Schlüsselwertspeicher angesehen, haben aber auch Attribute traditioneller relationaler Datenbanken.

Wide-Column-Stores verwenden das Konzept eines Keyspace anstelle von Schemas. Ein Schlüsselbereich umfasst Spaltenfamilien (ähnlich wie Tabellen, jedoch flexibler in der Struktur), von denen jede mehrere Zeilen mit unterschiedlichen Spalten enthält. Jede Zeile muss nicht dieselbe Anzahl oder denselben Spaltentyp haben. Ein Zeitstempel bestimmt die neueste Version der Daten.

Stärken

Diese Art von Datenbank bietet einige Vorteile sowohl für relationale als auch für nicht relationale Datenbanken. Es verarbeitet sowohl strukturierte als auch semistrukturierte Daten besser als andere nicht relationale Datenbanken und ist einfacher zu aktualisieren. Im Vergleich zu relationalen Datenbanken ist es horizontal skalierbarer und skalierbarer.

Säulendatenbanken werden besser komprimiert als zeilenbasierte Systeme. Außerdem sind große Datenmengen einfach zu untersuchen. Wide-Column-Stores eignen sich beispielsweise besonders gut für Aggregationsabfragen.

Schwächen

Schriften sind im Kleinen teuer. Während das Aktualisieren in großen Mengen einfach ist, ist das Hochladen und Aktualisieren einzelner Datensätze schwierig. Außerdem sind breitspaltige Speicher bei der Verarbeitung von Transaktionen langsamer als relationale Datenbanken.

Verwenden Sie einen breitspaltigen Speicher für:

  • Big Data-Analyse, bei der Geschwindigkeit wichtig ist
  • Data Warehousing für Big Data
  • Großprojekte (dieser Datenbankstil ist kein gutes Werkzeug für durchschnittliche Transaktionsanwendungen)

Suchmaschine (Elasticsearch)

Es mag seltsam erscheinen, Suchmaschinen in einen Artikel über Datenbanktypen aufzunehmen. Elasticsearch erfreut sich jedoch in diesem Bereich zunehmender Beliebtheit, da Entwickler nach innovativen Möglichkeiten suchen, um die Suchverzögerung zu verringern. Elastisearch ist eine nicht relationale, dokumentbasierte Lösung zum Speichern und Abrufen von Daten, die speziell für das Speichern und schnelle Abrufen von Daten eingerichtet und optimiert wurde.

Stärken

Elastisearch ist sehr skalierbar. Es bietet ein flexibles Schema und ein schnelles Abrufen von Datensätzen mit erweiterten Suchoptionen, einschließlich Volltextsuche, Vorschlägen und komplexen Suchausdrücken.

Eine der interessantesten Suchfunktionen ist das Stemming. Stemming analysiert die Grundform eines Wortes, um relevante Datensätze zu finden, selbst wenn eine andere Form verwendet wird. Beispielsweise würde ein Benutzer, der eine Beschäftigungsdatenbank nach "bezahlten Jobs" durchsucht, auch Positionen finden, die als "bezahlt" und "bezahlen" gekennzeichnet sind.

Schwächen

Elastisearch wird eher als Zwischen- oder Zusatzspeicher als als Primärdatenbank verwendet. Es hat eine geringe Haltbarkeit und schlechte Sicherheit. Es gibt keine angeborene Authentifizierung oder Zugriffskontrolle. Außerdem unterstützt Elastisearch keine Transaktionen.

Verwenden Sie eine Suchmaschine wie Elastisearch für:

  • Verbesserung der Benutzererfahrung durch schnellere Suchergebnisse
  • Protokollierung

Schlussbetrachtungen

Einige Anwendungen passen genau zu den Stärken eines bestimmten Datenbanktyps, aber bei den meisten Projekten gibt es Überschneidungen zwischen zwei oder mehr. In diesen Fällen kann es hilfreich sein, zu prüfen, welche spezifischen Datenbanken in den konkurrierenden Stilen gute Kandidaten sind. Anbieter bieten ein breites Spektrum an Funktionen, um ihre Datenbank an individuelle Standards anzupassen. Einige davon können dazu beitragen, die Unsicherheit über Faktoren wie Sicherheit, Skalierbarkeit und Kosten zu beseitigen.