NoSQL umfasst ein breites Spektrum an Datenbanktechnologien, die für spezifische Anforderungen moderner Anwendungen entwickelt wurden:
Entwicklungsteams haben es mit Anwendungen zu tun, die ungeheure Volumina neuer und sich rasch ändernder Datentypen generieren: strukturiert, halbstrukturiert, unstrukturiert und polymorph.
Die Zeiten, wo nach dem Wasserfall-Modell mit seinen 12- bis 18-monatigen Phasen entwickelt wurde, sind lange vorüber. Heute arbeiten kleine Teams dynamisch und schubweise, die Phasen sind viel kürzer, und alle ein oder zwei Wochen wird neuer Code bereitgestellt, mitunter sogar mehrmals täglich.
Anwendungen, die sich früher an eine eng umrissene Nutzergruppe richteten, werden nun als permanent verfügbare Services angeboten und von unterschiedlichsten Geräten aus genutzt, weltweit und millionenfach.
Organizations are now turning to scale-out architectures using open software technologies, commodity servers and cloud computing instead of large monolithic servers and storage infrastructure.
Relationale Datenbanken wurden weder für das Maß an Skalierbarkeit und Flexibilität ausgelegt, das moderne Anwendungen benötigen, noch für die Ausführung auf kostengünstigen Standardservern und ‑speichergeräten entwickelt.
Probieren Sie aus, wie einfach es ist, Prototypen von Anwendungen auf MongoDB, der führenden nicht-relationalen Datenbank, zu entwickeln.
Das Aufsetzen einer Anwendung auf eine Datenbank sollte gut geplant sein, um eine hohe Leistung, Verfügbarkeit und Sicherheit sowie eine zuverlässige Wiederherstellung nach Ausfällen zu gewährleisten. Zudem müssen Sie diese Punkte im Auge behalten, solange Sie die Anwendung nutzen. Mit MongoDB Atlas erhalten Sie alle Funktionen von MongoDB, jedoch ohne den Administrationsaufwand. So können Sie sich darauf konzentrieren, sich mit MongoDB Atlas vertraut zu machen und Ihre Anwendungen zu entwickeln. Folgende Funktionen sind enthalten:
Zahlung nach Verbrauch auf Abruf
Nahtlose Upgrades und Selbstheilung
Flexible Skalierbarkeit
Detaillierte Überwachung & anpassbare Benachrichtigungen
Von Haus aus starke Sicherheit
Kontinuierliche Backups mit Point-in-Time-Wiederherstellung
Dokumentdatenbanken kombinieren jeden Schlüssel mit einer komplexen Datenstruktur, dem sogenannten Dokument. Jedes Dokument kann viele verschiedene Schlüssel-Wert-Paare bzw. Schlüssel-Array-Paare und sogar eingebettete Dokumente enthalten.
Graphdatenbanken speichern Informationen über Datennetzwerke, wie etwa soziale Verbindungen. Beispiele für Graphdatenbanken sind Neo4J and Giraph.
Schlüssel-Wert-Datenbanken sind die einfachsten NoSQL-Datenbanken. Jedes einzelne Element wird in der Datenbank als Attributname (bzw. Schlüssel) zusammen mit seinem Wert gespeichert. Beispiele für Schlüssel-Wert-Datenbanken sind Riak and Berkeley DB. In einigen Schlüssel-Wert-Datenbanken wie etwa Redis kann den Werten ein Typ, beispielsweise "Integer", zugeordnet und somit die Funktionalität gesteigert werden.
Spaltenorientierte Datenbanken wie etwa Cassandra und HBase sind für Suchvorgänge in großen Datensätzen optimiert und speichern alle Werte in einer Datenspalte zusammen (anstelle aller Werte in einer Zeile).
Im Vergleich zu relationalen Datenbanken sind NoSQL-Datenbanken skalierbarer und leistungsstärker. Außerdem ist ihr Datenmodell im Gegensatz zum relationalen Modell für folgende Herausforderungen ausgelegt:
Große Mengen sich schnell ändernder strukturierter, halbstrukturierter und unstrukturierter Daten
Agile Entwicklung, schnelle Schemaiteration und häufige Programmänderungen
Benutzerfreundliche und flexible objektorientierte Programmierung
Geografisch verteilte, skalierbare Architektur anstelle von kostenintensiven, monolithischen Architekturen
die Auswahl des geeigneten Datenmodells: Dokumentmodell, Schlüssel-Wert-Modell, spaltenorientiertes Modell oder Graphmodell
die Vor- und Nachteile von konsistenten und zeitverzögert konsistenten Systemen
Warum die MongoDB-Treiber für spezifische Programmiersprachen die Einarbeitungszeit für neue Entwickler auf ein Minimum reduzieren und die Anwendungsentwicklung vereinfachen
In relationalen Datenbanken müssen Sie Schemata definieren, bevor Sie Daten hinzufügen können. Wenn Sie beispielsweise Daten über Ihre Kunden wie etwa Telefonnummern, Vor- und Nachnamen, Straßen, Städte und Länder speichern möchten, müssen Sie dies bei der Erstellung einer SQL-Datenbank im Vorfeld festlegen.
Das passt jedoch nicht zum Konzept der agilen Entwicklung, denn häufig muss das Schema Ihrer Datenbank geändert werden, wenn Sie neue Funktionen implementieren. Wenn Sie also irgendwann später beschließen, dass Sie die Lieblingsartikel Ihrer Kunden zusätzlich zu deren Adressen und Telefonnummern speichern möchten, müssen Sie eine entsprechende Spalte in die Datenbank einfügen und anschließend die komplette Datenbank in das neue Schema migrieren.
Bei großen Datenbanken ist das ein sehr langwieriger Prozess, der nicht bei laufendem Betrieb erfolgen kann. Wenn Sie die in Ihrer Anwendung gespeicherten Daten häufig ändern – weil Sie die Funktionalität fortlaufend erweitern – ist die Datenbank möglicherweise häufig nicht verfügbar. Außerdem können Sie in einer relationalen Datenbank keine komplett unstrukturierten Daten oder Daten mit einem nicht vorab bekannten Datentyp verarbeiten.
In NoSQL-Datenbanken ist es dagegen möglich, Daten ohne vordefiniertes Schema einzufügen. Infolgedessen können Anwendungen problemlos und ohne Unterbrechung des Betriebs in Echtzeit geändert werden. Das beschleunigt die Entwicklung, vereinfacht die Integration neuer Software und reduziert den Zeitaufwand für das Datenbankmanagement. Wenn Entwickler sicherstellen wollten, dass bestimmte Felder nicht leer waren oder einen bestimmten Datentyp bzw. einen zulässigen Wert hatten, mussten sie bislang allerdings Code in ihre Anwendungen integrieren, der dies prüfte und nicht konforme Eingaben zurückwies. Funktionsreichere NoSQL-Datenbanken unterstützen die Definition von Regeln für bestimmte Felder in der Datenbank, sodass die Benutzer die Einhaltung bestimmter Vorgaben erzwingen und gleichzeitig von der Flexibilität eines dynamischen Schemas profitieren können.
Aufgrund ihrer Struktur werden relationale Datenbanken in der Regel vertikal skaliert – ein einziger Server muss die gesamte Datenbank hosten, damit tabellenübergreifende Joins und Transaktionen mit akzeptabler Leistung ausgeführt werden können. Die daraus resultierende Architektur wird jedoch schnell teuer, lässt sich nur bedingt skalieren und enthält meist sogenannte „single points of failure“ – Ressourcen, deren Ausfall den Ausfall der gesamten Datenbank nach sich zieht. Die Lösung für schnell wachsende Anwendungen lautet „horizontale Skalierung“. Damit ist eine Architektur gemeint, in der Server hinzugefügt werden können, anstatt die Kapazität eines einzigen Servers zu vergrößern.
Ein „Sharding“ von SQL-Datenbanken über mehrere Serverinstanzen ist zwar möglich, wird aber normalerweise mit SANs und anderen komplexen Anordnungen erreicht, die der Datenbank die genutzte Hardware als einen einzigen Server präsentieren. Da das Sharding nicht als native Datenbankfunktion verfügbar ist, müssen die Entwickler mehrere relationale Datenbanken auf unterschiedlichen Computern einrichten. Die in den verschiedenen Datenbanken gespeicherten Daten sind dabei zunächst voneinander unabhängig. Die Anwendungssoftware muss dafür sorgen, dass die Daten und Suchvorgänge richtig verteilt und die Abfrageergebnisse aller Datenbankinstanzen korrekt aggregiert werden. Zusätzlich müssen Funktionen zur Handhabung von Ressourcenengpässen, zur Ausführung von datenbankübergreifenden Joins, zur Umverteilung von Daten, zur Replikation und für andere Eventualitäten programmiert werden. Außerdem werden viele Vorteile relationaler Datenbanken durch manuelles Sharding beeinträchtigt oder zerstört, wie beispielsweise die Integrität von Transaktionen.
NoSQL-Datenbanken unterstützen dagegen im Allgemeinen Auto-Sharding. Das bedeutet, dass sie für die automatische Verteilung von Daten auf eine beliebige Anzahl an Servern ausgelegt sind, wobei die Anwendung die Zusammenstellung des Serverpools noch nicht einmal zu kennen braucht. Die Daten und die Suchvorgänge werden automatisch auf die Server verteilt und wenn ein Server ausfällt, kann er ohne Unterbrechung des Dienstes schnell und transparent ersetzt werden.
Cloud Computing macht dies deutlich einfacher, da Anbieter wie etwa Amazon Web Services praktisch unbegrenzte On-Demand-Kapazität bereitstellen und das Infrastrukturmanagement übernehmen. Die Entwickler müssen also nicht wie bisher komplexe, kostenintensive Plattformen für ihre Anwendungen einrichten und pflegen, sondern können sich ganz auf das Schreiben der Anwendungssoftware konzentrieren. Mehrere Standardserver können die gleiche CPU- und Speicherkapazität bereitstellen wie ein einziger High-End-Server – zu einem Bruchteil der Kosten.
Die meisten NoSQL-Datenbanken unterstützen außerdem die automatische Datenbankreplikation, sodass der Service auch bei unerwarteten Ausfällen oder geplanten Wartungsmaßnahmen verfügbar ist. Funktionsreichere NoSQL-Datenbanken enthalten automatische Failover- und Recoveryfunktionen und können sich vollkommen selbstständig wiederherstellen. Zudem unterstützen sie die Verteilung der Datenbank auf mehrere geografische Regionen. Das bedeutet erstens, dass ein Ausfall in einer Region nicht zum Ausfall der ganzen Datenbank führen kann. Zweitens können Nutzer auf in ihrer Region gespeicherte Daten zugreifen und profitieren von einer geringeren Latenz. Im Gegensatz zu relationalen Datenbanken benötigen NoSQL-Datenbanken im Allgemeinen keine separaten Anwendungen oder kostenintensiven Add-Ons, um die Replikation zu unterstützen.
Viele Produkte stellen eine Caching-Ebene für SQL-Datenbanksysteme bereit. Diese Systeme können die Lesegeschwindigkeit deutlich steigern. Die Schreibgeschwindigkeit bleibt jedoch gleich – und das ganze System wird komplexer. Wenn Ihre Anwendung größtenteils zum Lesen von Daten genutzt wird, kann ein verteilter Cache sinnvoll sein. Wenn Sie jedoch auch Schreibvorgänge unterstützen, wird die Gesamtleistung durch einen verteilten Cache möglicherweise nicht gesteigert, die Cachedevalidierung jedoch deutlich aufwendiger. Dies gilt auch, wenn nur ein kleiner Teil der Datenbankzugriffe Schreibvorgänge sind.
Viele NoSQL-Datenbanken bieten hervorragende Cachingfunktionen und behalten so viele häufig verwendete Daten wie möglich im Arbeitsspeicher, sodass keine separate Cachingebene erforderlich ist. Für Workloads, die einen hohen Durchsatz mit niedriger Latenz benötigen, bieten einige NoSQL-Datenbanken sogar eine integrierte, vollständig verwaltete, speicherresidente Datenbankmanagementebene an.
| SQL-Datenbanken | NoSQL-Datenbanken | |
|---|---|---|
| Art | Eine Art (SQL-Datenbank) mit leichten Variationen | Viele verschiedene Arten einschließlich Schlüssel-Wert-Datenbanken, Dokumentdatenbanken, spaltenorientierten Datenbanken und Graphdatenbanken |
| Entwicklungsgeschichte | In den 1970er Jahren für die erste Welle der Anwendungen für die Datenspeicherung entwickelt | Gegen Ende der 2000er Jahre entwickelt, um die Leistungsgrenzen von SQL-Datenbanken – insbesondere hinsichtlich der Skalierbarkeit, der Verarbeitung von Daten mit unterschiedlichen Strukturen, der geografischen Verteilung und der agilen Entwicklung – zu überwinden |
| Beispiele | MySQL, Postgres, Microsoft SQL Server, Oracle Database | MongoDB, Cassandra, HBase, Neo4j |
| Datenspeicherungsmodell | Individuelle Datensätze (z.B. „Mitarbeiter“) werden als Zeilen in Tabellen gespeichert, wobei in jeder Spalte eine bestimmte Angabe über den Datensatz enthalten ist (z.B. „Manager“, „Einstellungsdatum“ usw.). Verwandte Daten werden in separaten Tabellen gespeichert und anschließend bei komplexeren Suchvorgängen zusammengeführt. „Standorte“ könnten beispielsweise in einer Tabelle und „Mitarbeiter“ in einer anderen gespeichert werden. Wenn ein Benutzer die Geschäftsadresse eines Mitarbeiters sucht, verknüpft die Datenbank-Engine die Tabellen „Mitarbeiter“ und „Standorte“, um alle erforderlichen Daten zu finden. | Variiert abhängig vom Datenbanktyp. Schlüssel-Wert-Datenbanken funktionieren beispielsweise ähnlich wie SQL-Datenbanken, haben jedoch nur zwei Spalten („Schlüssel“ und „Wert“). Sehr komplexe Daten werden mitunter als BLOBs (binary large objects, großer Binärwert) in der „Wert“-Spalte gespeichert. In Dokumentdatenbanken wurde das Tabellen- und Zeilenkonzept komplett abgeschafft und alle wichtigen Daten werden in einem einzigen „Dokument“ in JSON, XML oder einem anderen Format gespeichert, das Werte hierarchisch verschachteln kann. |
| Schemata | Die Struktur und die Datentypen müssen vorab definiert werden. Bevor Informationen über ein neues Datenelement gespeichert werden können, muss die gesamte Datenbank geändert und dazu offline genommen werden. | Typischerweise dynamisch, mit einigen Datenvalidierungsregeln. Neue Felder können in Echtzeit hinzugefügt werden und anders als bei SQL-Tabellen ist es möglich, ungleiche Daten bei Bedarf zusammen zu erfassen. Bei einigen Datenbankarten (z. B. spaltenorientierten Datenbanken) ist das dynamische Hinzufügen von neuen Feldern ein wenig schwieriger. |
| Skalierung | Vertikal. Die Leistung des einzigen Servers muss also ständig erhöht werden, damit er die wachsenden Anforderungen erfüllen kann. SQL-Datenbanken können zwar prinzipiell auf mehrere Server verteilt werden, doch ist dies im Allgemeinen sehr aufwendig und mit dem Verlust einiger Kernfunktionen von relationalen Datenbanken verbunden, darunter JOINs, referentielle Integrität und Transaktionsintegrität. | Horizontal. Das bedeutet, dass ein Datenbankadministrator einfach zusätzliche Standardserver oder Cloudinstanzen hinzufügen kann, wenn eine höhere Kapazität benötigt wird. Die Datenbank verteilt die Daten bei Bedarf automatisch neu. |
| Entwicklungsmodell | Mix of open technologies (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database) | Open technologies |
| Unterstützt Multi-Record-ACID-Transaktionen | Ja | Meist nicht. MongoDB 4.0 und höher unterstützt Multi-Dokument-ACID-Transaktionen. Weitere Informationen |
| Änderung der Daten | Spezielle Sprache mit Select-, Insert- und Update-Statements wie etwa „SELECT fields FROM table WHERE“ | Anhand von objektorientierten APIs |
| Konsistenz | Kann für starke Konsistenz konfiguriert werden | Je nach Produkt. Einige bieten starke Konsistenz (z. B. MongoDB mit konfigurierbarer Konsistenz für Lesevorgänge), während andere (z. B. Cassandra) nur zeitverzögerte Konsistenz unterstützen. |
Often, organizations will begin with a small-scale trial of a NoSQL database in their organization, which makes it possible to develop an understanding of the technology in a low-stakes way. Most NoSQL databases are also based on open technologies and are free to use, meaning that they can be downloaded, implemented and scaled at little cost. Because development cycles are faster, organizations can also innovate more quickly and deliver superior customer experience at a lower cost.
Es gibt verschiedene Gründe, Alternativen zu den bisherigen Infrastrukturen zu recherchieren: Skalierung und Leistung über die Grenzen Ihres vorhandenen Systems hinaus, Suche nach realisierbaren Alternativen zur teuren proprietären Software oder schnellere und agilere Entwicklung. Bei der Auswahl der passenden Datenbank für Ihr Unternehmen und Ihre Anwendung sollten Sie fünf wichtige Aspekte genauer unter die Lupe nehmen.
Lesen Sie unser kostenloses WhitepaperDie fünf wichtigsten Aspekte bei der Auswahl einer NoSQL-Datenbank (nur auf Englisch verfügbar) Die Themen:
die Auswahl des geeigneten Datenmodells: Dokumentmodell, Schlüssel-Wert-Modell, spaltenorientiertes Modell oder Graphmodell
die Vor- und Nachteile von konsistenten und zeitverzögert konsistenten Systemen
Warum die MongoDB-Treiber für spezifische Programmiersprachen die Einarbeitungszeit für neue Entwickler auf ein Minimum reduzieren und die Anwendungsentwicklung vereinfachen