Elefant unter Strom: Von OldSQL über NoSQL zu NewSQL?

NewSQL mit VoltDB

Jan Stamer

© Shutterstock.com/In Green

„Relationale Datenbanken sind groß, alt, schwer und langsam wie ein Elefant. Richtig gut können die eigentlich gar nichts“, sagt Michael Stonebreaker. Er will den Elefanten mit der Datenbank VoltDB zeigen, dass auch mit ACID und SQL gute Skalierbarkeit und hohe Performance möglich sind.

Liest man den oben zitierten Satz von Michael Stonebreaker, könnte man ihn für einen Jünger der NoSQL-Bewegung halten. Ist er nicht wirklich. Der Mann ist ein Datenbankdinosaurier, unter anderem Vater der relationalen Datenbank PostgreSQL und der Datawarehouse-Datenbank Vertica, die gerade für 430 Millionen Dollar an HP verkauft wurde. Daneben hat er noch weitere Start-ups wie StreamBase, Paradigm4 oder Tamr gegründet. Ach ja, und Professor am MIT ist er auch noch.

Zurück zu den Elefanten. Die mächtigen Vierbeiner sind langsam und behäbig. Das gilt auch für relationale Datenbanken, stellte Stonebreaker fest, und bezeichnet sie daher als OldSQL-Datenbanken. Michael Stonebreaker untersuchte die Performance relationaler Datenbanken mit dem Benchmark TPC-C – und stellte fest: Nur 4 Prozent der Zeit wird für die eigentliche Anfrage verbraucht. Die restlichen 96 Prozent sind Overhead. Das weckte Stonebreakers Neugier. Was macht denn die Datenbank in der Zeit, in der sie nicht mit der eigentlichen Anfrage beschäftigt ist?

Auf der Suche nach der verlorenen Performance

Relationale Datenbanken erlauben parallele Zugriffe auf die Daten und garantieren dabei die ACID-Eigenschaften. Um die widersprüchlichen Anforderungen Parallelität und Konsistenz unter einen Hut zu bringen, wird mit Sperrmechanismen gearbeitet. Das ist so aufwändig, dass es schon allein 50 Prozent des Overheads und damit nahezu der gesamten Zeit ausmacht.

Den Rest der Performance fressen zu gleichen Teilen Recovery-Mechanismen und die Interaktion mit dem Dateisystem. Die in Recovery investierte Zeit verkürzt einen Neustart oder das Hochfahren nach einem Crash und sorgt dafür, dass die Datenbank schnell wieder verfügbar ist. Mit dem Dateisystem interagieren relationale Datenbanken über den Buffer Pool. Hierbei handelt es sich um die Datenstruktur der Datenbank auf der Festplatte. Er befindet sich teilweise als Cache im Hauptspeicher. Anfragen an die Datenbank greifen nicht direkt auf die Daten im Hauptspeicher zu, sondern gehen immer über den Buffer Pool. Das kostet im Schnitt 25 Prozent der Anfragezeit.

Halten wir nochmal fest: Klassische RDBMs (Relationale Datenbankmanagementsysteme) verbrauchen nahezu 50 Prozent der Anfragezeit für Sperrmechanismen und je 25 Prozent für Recovery und Interaktion mit dem Dateisystem. Relationale Datenbanken mit diesen Eigenschaften bezeichnet Stonebreaker als OldSQL oder „Elefanten“.

NoSQL to the rescue?

Ist NoSQL der nächste Schritt nach OldSQL? Aus der Unzufriedenheit mit RDBMS heraus entstanden NoSQL-Datenbanken. Die tun einiges, um den Overhead relationaler Datenbanken zu reduzieren: Um Sperrmechanismen zu vermeiden, opfern sie ACID und garantieren nur noch „eventual consistency“, Konsistenz im weiteren Sinne. Statt Recovery setzen sie auf Redundanz. Mit dem Dateisystem interagieren auch NoSQL-Datenbanken, das heißt, etwas wie den Buffer Pool brauchen sie auch.

NoSQL-Datenbanken garantieren im Allgemeinen nicht die ACID-Eigenschaften, und SQL sprechen sie schon per Definition nicht. Die Frage ist also, ob ACID und SQL notwendig sind.

Wozu ACID?

Bekanntlich ist es für relationale Datenbanken sehr teuer, die ACID-Eigenschaften bei Transaktionen zu garantieren. ACID heißt: Änderungen auf der Datenbank, die innerhalb einer Transaktion durchgeführt werden, sind atomar, konsistent, isoliert und dauerhaft (Atomicity, Consistency, Isolation, Durability).

Nach Einschätzung Stonebreakers sind es genau diese Eigenschaften, die von vielen Anwendungen gebraucht werden. ACID ist für viele Anwendungen kein „Nice to have“, sondern eine harte Anforderung. Könnte Amazon akzeptieren, dass die letzte Harry-Potter-Ausgabe dreimal verkauft wurde? Sicher nicht. Bei Banken oder Versicherungen würde sicher keiner mit „eventual consistency“ zufriedengeben. Die ACID-Eigenschaften gehören zu den Grundlagen von Datenbanken – weil sie für viele Anwendungen wichtig sind. Werden die ACID-Eigenschaften nicht von der Datenbank garantiert, so müssen sie innerhalb der Anwendung gelöst werden, was nach Einschätzung Stonebreakers viel schwieriger ist.

Auch wenn sie kein ACID garantiert, geht MongoDB in Sachen Transaktionen deutlich weiter als viele andere NoSQL-Datenbanken. Das ist wohl auch ein Grund für die Popularität der Datenbank. Google bekennt sich dieser Tage klar zu ACID und löst seine Datenbank BigTable durch die ACID-konforme Datenbank Spanner ab. Das entscheidende Zitat von Google zum Thema Transaktionen ist: „We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.“

Wozu SQL?

NoSQL-Datenbanken sprechen kein SQL. Stattdessen hat jede Datenbanken eine eigene Query-Sprache. Mit der Cassandra Query Language und Couchbases „Next Generation Query Language“ N1QL gibt es zaghafte Versuche, eine standardisierte Query Language für NoSQL-Datenbanken zu schaffen. Manche Datenbanken gehen sogar noch weiter und unterstützen direkt SQL wie Apache Hive oder Facebooks Presto. Für Stonebreaker ist das kein Wunder, da dreißig Jahre Know-how in SQL stecken und es für viele Anwendungen gut funktioniert.

Also NoSQL statt OldSQL?

NoSQL eignet sich als Nachfolger für OldSQL nur für Anwendungen, die auf ACID und SQL verzichten können. Dies ist jedoch nach Einschätzung von Michael Stonebreaker ein eher geringerer Teil von Anwendungen, was auch der Grund dafür ist, dass sich NoSQL noch nicht im großen Stil durchgesetzt hat. Viele NoSQL-Datenbanken haben jedoch in Sachen Performance und (insbesondere horizontale) Skalierung weit mehr zu bieten als die OldSQL-Elefanten. Für einige Anwendungen sind Performance und Skalierbarkeit so wichtig, dass in Kauf genommen wird, Logik für Transaktionen in die Anwendung zu ziehen. Aber gibt es denn nur schwarz oder weiß, das heißt OldSQL oder NoSQL?

Die Welt der Datenbanken aus Stonebreakers Sicht

Michael Stonebreaker teilt die Welt der Datenbanken in drei Bereiche:

Der erste Bereich ist der des Datawarehouse, der zweite der des Online Transaction Processing und der dritte umfasst alles andere. Datawarehouse-Datenbanken sind auf die Auswertung und Analyse großer Datenmengen ausgerichtet. OLTP sind Datenbanken, die ACID-Transaktionen und SQL unterstützen. Die Elefanten, also die relationalen Datenbanken, fallen in den Bereich OLTP. Im Sammeltopf der weiteren Typen landen die NoSQL-Datenbanken.

Den Datawarehouse-Bereich hat Michael Stonebreaker mit Vertica aufgerollt. Den undankbaren Sammeltopf überlässt er der NoSQL-Community. Stonebreakers „next big Thing“ ist der OLTP-Bereich. Dort will der Dinosaurier den Elefanten zeigen, wie der Hase läuft:

„At least for new OLTP applications, giving up ACID and giving up SQL is a terrible idea. You don’t have to give up either of those. You can go fast without giving up either. If you give up ACID, you end up pushing data consistency into the application logic, and that’s just way harder to do.“

Statt sich in den Ruhestand zu begeben, tritt Stonebreaker mit siebzig Jahren noch einmal an, um den Markt der OLTP-Datenbanken für all die Anwendungen zu revolutionieren, die ACID-Transaktionen und SQL brauchen oder behalten wollen.

Introducing NewSQL

Die Revolution, die das OLTP auslösen könnte, nennt Stonebreaker NewSQL. NewSQL verbindet die Performance und horizontale Skalierbarkeit der NoSQL-Datenbanken mit den ACID-Eigenschaften und der SQL-Fähigkeit der Elefanten. VoltDB ist eine NewSQL-Datenbank, die genau dieses Versprechen erfüllen will. Stonebreaker ist der Kopf hinter VoltDB und deren CTO.

VoltDB ist eine vollwertige relationale Datenbank mit ACID-Transaktionen, SQL und JDBC-Treiber. Allerdings vermeidet sie den großen Overhead der OldSQL-Datenbanken durch eine neue Architektur. VoltDB vermeidet Locking, indem es als einzelner Thread läuft. Damit sind schon 50 Prozent Overhead eingespart. Recovery wird auch bei VoltDB durch Redundanz ersetzt – spart 25 Prozent Overhead. Die VoltDB-Datenbank läuft vollständig im Hauptspeicher und spart sich somit den Buffer Pool – das spart weitere 25 Prozent Overhead. Der Overhead entfällt somit fast vollständig, so das Versprechen. Horizontal skaliert VoltDB durch viele parallel laufende VoltDB-Instanzen, die jeweils in nur einem Thread laufen. Dies ist analog zu Node.js, das ja zunächst auch nur als einzelner Thread läuft und erst mit mehreren Instanzen horizontal skaliert.

Mit dieser neuen Architektur will VoltDB die OldSQL-Elefanten beerben und zu der ACID-Datenbank für Cloud-Anwendungen schlechthin werden. Man wird sehen, ob VoltDB das Zeug dafür hat. Fühlen wir dem jungen Dickhäuter in den nächsten Abschnitten etwas auf den Zahn.

VoltDB am Beispiel

Die NewSQL-Datenbank VoltDB gibt es als freie Community Edition oder als kommerzielle Enterprise Edition für alle gängigen Plattformen. Die Community Edition ist Open Source unter der AGPL-Lizenz zu beziehen. Die Quellen liegen bei GitHub. VoltDB ist zu gleichen Teilen in Java und C++ entwickelt. In C++ sind die Speicherverwaltung und IO-Zugriffe realisiert, die für die Performance besonders kritisch sind.

Um VoltDB kennenzulernen, werden wir eine kleine Anwendung zur Zeiterfassung mit VoltDB bauen. Dazu werden wir die Zeiterfassung Baralga mit einem VoltDB Backend versehen. Die fertige Beispielanwendung liegt bei GitHub.

Vorbereitung: Installation der VoltDB: Zur Installation sollten Sie die aktuelle Version von VoltDB herunterladen und entpacken. Der Pfad bin sollte in den Pfad des Betriebssystems aufgenommen werden, damit VoltDB in der Kommandozeile verfügbar ist.

Datenbank erzeugen: Die Struktur der Datenbank wird bei VoltDB wie bei OldSQL-Datenbanken über SQL-DDL-Statements erzeugt. Allerdings werden die DDL-Statements nicht direkt in die Datenbank eingespielt. Aus dem Schema wird mit dem VoltDB-Compiler ein so genannter Application Catalog in Form eines Java-JAR-Archives erstellt.

Unser Beispielprojekt, die Zeiterfassung, besteht aus zwei Tabellen. Die Tabelle ACTIVITY enthält alle erfassten Aktivitäten, und die Tabelle PROJECT enthält die Projekte. Die SQL-DDL-Skripte sind im SQL-DDL-Skript baralga.sql abgelegt. Das Schema wird mit Befehl voltdb compile -o baralga.jar baralga.sql kompiliert.

Das Ergebnis sind der Application Catalog in der Datei baralga.jar und ein Catalog Report in der Datei catalog-report.html. Der Catalog Report enthält eine detaillierte Beschreibung des Schemas mit einem praktischen Size Worksheet (Abb. 1), um den Speicherbedarf in Abhängigkeit der erwarteten Datensätze zu errechnen.

Abb. 1: Speicherbedarf mit dem Size Worksheet ermitteln

Abb. 1: Speicherbedarf mit dem Size Worksheet ermitteln

Im originalen Baralga-Datenbankschema wird ein Foreign Key Constraint verwendet. Dieser muss entfernt werden, da VoltDB keine Foreign Key Constraints unterstützt.

Datenbank starten: Beim Start von VoltDB wird der Application Catalog übergeben und damit eine VoltDB-Instanz für das Schema gestartet. Das passiert mit dem Befehl voltdb create baralga.jar.

Nun läuft die VoltDB-Datenbank für unser Baralga-Schema, und wir können uns mit der Datenbank verbinden. Mit VoltDB zusammen wird auch die Webanwendung VoltDB Studio (Abb. 2) unter der Adresse http://localhost:8080/studio/ gestartet. VoltDB Studio zeigt Kennzahlen über die aktuelle Performance der Datenbank, Details zum Schema, und es kann per SQL auf die Datenbank zugegriffen werden.

Abb. 2: Administration mit VoltDB Studio

Abb. 2: Administration mit VoltDB Studio

Zugriff auf die Datenbank: Auch mit dem Kommandozeilentool sqlcmd können SQL-Statements auf der laufenden Datenbank ausgeführt werden, analog zu SQL*Plus bei Oracle-Datenbanken. So können wir für unsere Beispielanwendung mit folgendem SQL-Statement ein neues Projekt erstellen:

INSERT INTO PROJECT VALUES (1, 'Löwe zähmen', 'Zähmen von Leo Löwe', 1);

Auch ein Zugriff per JDBC ist möglich, der Code dazu steht in Listing 1. Die Klasse ProjectRepository im Beispielprojekt enthält den vollständigen Code für einen Zugriff auf alle Projekte per JDBC. Aufgrund der JDBC-Unterstützung wird das gewohnte Tooling für JDBC-Datenzugriffe unterstützt. So kann VoltDB als Datenbank in Spring oder einem Application Server genutzt werden, und bestehender JDBC-Code lässt sich leicht auf VoltDB migrieren. Objektrelationale Mapper wie Hibernate oder MyBatis werden von VoltDB nicht offiziell unterstützt. Hier ist noch etwas Forschungsarbeit nötig.

Listing 1

Connection connection = DriverManager.getConnection("jdbc:voltdb://localhost:21212");
Statement query = connection.createStatement();
ResultSet results = query.executeQuery("SELECT id, title, description FROM project");

Eine weitere Möglichkeit, auf die VoltDB zuzugreifen, ist über das JSON-API. Der HTTP Request für das Select Statement auf die Projekte sieht so aus:

curl http://localhost:8080/api/1.0/?Procedure=@AdHoc&Parameters=["select * from project"]

Das JSON-API muss über die Konfigurationsdatei von VoltDB deployment.xml aktiviert werden. Listing 2 zeigt die entsprechende Konfiguration. Diese wird VoltDB beim Start als Parameter mitgegeben: voltdb create -d deployment.xml baralga.jar.

Listing 2

<?xml version="1.0"?>
<deployment>
  <httpd enabled="true">
    <jsonapi enabled="true" />
  </httpd>
</deployment>

Stored Procedures

Normale SQL Queries bezeichnet VoltDB als Ad Hoc Queries. Daneben gibt es in VoltDB Stored Procedures. Hierbei handelt es sich um ein sehr wichtiges und mächtiges Werkzeug in VoltDB, insbesondere, wenn es schnell gehen soll. Stored Procedures werden mit in den Application Catalog kompiliert. Bereits beim kompilieren wird der Execution Plan festgelegt, der dann bei der Ausführung herangezogen wird.

Die einfachste Form der Stored Procedure ist ein SQL-Statement mit Platzhaltern, vergleichbar mit einem Prepared Statement von JDBC. Der folgende Codeausschnitt zeigt die Stored Procedure lastXactivities, die die letzten x erfassten Aktivtäten ermittelt:

CREATE PROCEDURE lastXactivities AS

SELECT TOP ? project_id, .. FROM ACTIVITY ORDER BY act_end ASC;

Auch Stored Procedures können über JDBC ausgeführt werden. Der Code zur Ausführung der Stored Procedure lastXactivities mit Parameter 5 sieht wie folgt aus:

CallableStatement procedure = conn.prepareCall("{call lastXactivities(?)}");

procedure.setInt(1, 5); // Parameter 5

ResultSet results = procedure.executeQuery();

Komplexere Stored Procedures können in Java geschrieben werden. Listing 3 zeigt die Implementierung von LastXactivitiesJava als Stored Procedure in Java.

Listing 3

class LastXActivitiesJava extends VoltProcedure {

  SQLStmt lastXActivitiesSql = new SQLStmt("SELECT TOP ? * FROM ACTIVITY ORDER BY act_end ASC;");

  public VoltTable[] run(int x) {
    voltQueueSQL(lastXActivitiesSql, x);
    return voltExecuteSQL();
  }
}

Die Stored Procedure muss nun mit Java kompiliert und im Datenbankschema referenziert werden:

CREATE PROCEDURE FROM CLASS LastXActivitiesJava;

Beim Kompilieren des Schemas muss die kompilierte Stored Procedure dann im Classpath liegen:

voltdb compile --classpath=procedures.jar -o baralga.jar baralga.sql

Transaktionen in VoltDB

VoltDB unterstützt ACID-Transaktionen. Allerdings werden die Transaktionen anders gesteuert als in traditionellen relationalen Datenbanken. In VoltDB wird ein Statement in einer Transaktion ausgeführt. Ein explizites Starten und Beenden der Transaktion ist nicht möglich. Die Ausnahme bilden Stored Procedures. Diese werden immer in einer Transaktion ausgeführt. Daher muss komplexere Logik, die in einer Transaktion laufen soll, in eine Stored Procedure verlagert werden.

In unserer Beispielanwendung wollen wir ein Projekt löschen. Mit dem Projekt sollen auch alle dafür erfassten Aktivitäten verschwinden – ganz oder gar nicht. Dies realisieren wir durch eine Stored Procedure, die zunächst die Aktivitäten und dann das Projekt löscht. Diese Stored Procedure läuft innerhalb einer Transaktion und erfüllt somit unsere Anforderung.

Durability und Recovery

Haben wir ein paar Daten gespeichert, können wir die Datenbank zum Test neu starten. Dabei stellen wir fest: Die Daten sind weg. Die Erklärung ist ganz einfach: Wird VoltDB mit der Option create gestartet, wird stets eine neue Datenbank erzeugt, die vollständig im Hauptspeicher läuft.

Wir wollen ja aber unsere Daten behalten, auch wenn wir einmal neu starten. VoltDB kennt dazu eine Vielzahl von Möglichkeiten. Im Gegensatz zu Zugriffen auf den Hauptspeicher sind Zugriffe auf die Festplatte langsam. Daher kann genau gesteuert werden, wann und wie VoltDB Daten auf die Festplatte schreibt. So kann (und muss!) die Performance der Datenbank optimal auf die Bedürfnisse der Anwendung abgestimmt werden. Wer hohe Datensicherheit braucht, wird öfter Daten auf die Festplatte schreiben, wer auch mit Verlusten leben kann, vielleicht nur selten.

VoltDB kann einen Snapshot Daten der Datenbank im Dateisystem ablegen. Das kann manuell angestoßen werden mit dem Befehl:

voltadmin save $HERE/voltdbroot/snapshots/ "baralga" 

Snapshots können auch periodisch erzeugt werden. Listing 4 zeigt eine Konfiguration der VoltDB, die alle fünf Minuten einen Snapshot erzeugt und immer drei Snapshots vorhält.

Listing 4

<?xml version="1.0"?>
<deployment>
  <httpd enabled="true">
    <jsonapi enabled="true" />
  </httpd>
  <snapshot prefix="baralga" 
            frequency="5m" 
            retain="3"/>
</deployment>

Starten wir nun VoltDB mit voltdb recover -d=deployment.xml, so wird beim Start der aktuellste Snapshot geladen. Neben Snapshots gibt es in VoltDB noch einige weitere Mittel, um sicherzustellen, dass die Daten nicht verloren gehen. Dazu gehören Command Logging, K-Safety oder Datenbankreplikation. Diese Mechanismen sind im User Guide von von VoltDB detailliert beschrieben.

Partitionierung

VoltDB läuft im Hauptspeicher. Bei großen Datenmengen reicht aber der Hauptspeicher eines Knotens nicht mehr aus, um alle Daten vorzuhalten. Deswegen können Daten partitioniert werden. Dies ist für eine verteilte Datenbank unerlässlich.

In VoltDB kann jede Tabelle nach genau einer Spalte partitioniert werden. Für unsere Beispielanwendung rechnen wir mit sehr vielen Aktivitäten pro Projekt. Wir erwarten auch, dass wir häufig alle Aktivitäten eines Projekts benötigen. Also partitionieren wir die Aktivitäten nach der ID des Projekts. Das DDL-Statement, um die Tabelle der Aktivitäten nach Projekt-ID zu partitionieren, ist:

PARTITION TABLE activity ON COLUMN project_id;

Gibt es nun sehr viele Aktivitäten, so könnte ein Knoten der Datenbank alle Aktivitäten des Projekts „Löwe zähmen“ halten und ein anderer alle Aktivitäten des Projekts „Affenhaus erweitern“.

Alle Tabellen, die nicht partitioniert sind, werden auf jedem Knoten repliziert, das heißt, jeder Knoten hält die ganze Tabelle im Hauptspeicher. Partitionieren wir die Tabelle ACTIVITY, so wird die Tabelle PROJECT repliziert.

Die Partitionierung der Aktivitäten-Tabelle ist eine Änderung des Datenbankschemas. Schauen wir uns an, wie das funktioniert.

Ändern des Datenbankschemas

Das Schema der Datenbank wird bei VoltDB in den Application Catalog kompiliert, der die Struktur der Datenbank bildet. Eine Datenbank wird immer für einen Application Catalog gestartet. Eine Änderung des Datenbankschemas hat auch eine Änderung des Application Catalogs zur Folge. Es gibt nun zwei Wege, die Datenbank auf den neuen Application Catalog zu aktualisieren.

Der erste Weg ist es, den Application Catalog der Datenbank zur Laufzeit mit dem Befehl voltadmin update baralga_new.jar zu aktualisieren. Das Update zur Laufzeit gibt es jedoch nur in der Enterprise-Version von VoltDB. Die Community-Version muss mit dem zweiten Weg vorlieb nehmen.

Beim zweiten Weg wird die Datenbank heruntergefahren und anschließend eine neue Datenbank mit voltdb create baralga_new.jar gestartet. Nun können die Daten aus einem Snapshot mit voltadmin restore $HERE/voltdbroot/snapshots/ „states“ wiederhergestellt werden.

Durch den vorkompilierten Application Catalog ist das Schema in VoltDB nicht so flexibel wie in anderen Datenbanken. NoSQL-Datenbanken haben meist gar kein fest definiertes Schema. Klassische relationale Datenbanken haben ein Schema, erlauben aber Schemaänderungen zur Laufzeit per SQL.

Zusammenfassung

Hohe Performance und gute Skalierbarkeit sind Anforderungen, auf die klassische relationale Datenbanken für viele Anwendungen keine passende Antwort mehr haben. NoSQL ist eine Antwort, aber nur unter gewissen Voraussetzungen. Für Anwendungen, die ACID-Transaktionen brauchen und die Queries und Joins über viele Daten durchführen, sind sie nicht die beste Lösung. NewSQL-Datenbanken wie VoltDB glänzen bei Queries und Joins mit SQL, garantieren ACID und sind trotzdem performant und gut skalierbar.

NewSQL sehe ich als dritten Weg neben OldSQL und NoSQL. Den OldSQL-Elefanten ist die NewSQL-Datenbank VoltDB aus meiner Sicht klar überlegen, da sie dieselben Anforderungen auf Basis einer neuen Architektur besser und zeitgemäß umsetzt. Das Bekenntnis zu SQL bringt VoltDB viele Vorteile. Das bestehende SQL-Know-how der Mitarbeiter kann genutzt werden, und auch das Tooling funktioniert wie gewohnt. Wer bereits unter Oracle mit Stored Procedures gearbeitet hat, seien diese in PL/SQL oder in Java geschrieben, wird sich in VoltDB schnell heimisch fühlen. Nicht zuletzt ist die Migration einer klassischen Datenbankpersistenz auf VoltDB wesentlich einfacher als der Umstieg auf NoSQL.

Die Entscheidung für eine Datenbank war noch nie so schwer wie heute. Die Welt der Datenbanken ist unglaublich vielfältig geworden, und für jede Anwendung gilt es, die passende Datenbank auszuwählen. Ich hoffe, dieser Artikel hat die Entscheidung um eine Facette bereichert – und ein Stück schwerer gemacht.

Aufmacherbild: Intense electrical discharge and shine on a dark background von Shutterstock.com / Urheberrecht: In Green

Verwandte Themen:

Geschrieben von
Jan Stamer

Jan Stamer ist Senior-Softwareentwickler bei red6 in Hamburg, einem Spin-off der Hanse-Merkur-Versicherung. red6 entwickelt innovative Insurance-Lösungen mit zeitgemäßen Technologien mit Schwerpunkt auf Java und Node.js.

Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "NewSQL mit VoltDB"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Ralf Renz
Gast

„NoSQL-Datenbanken garantieren im Allgemeinen nicht die ACID-Eigenschaften, und SQL sprechen sie schon per Definition nicht.“
Falsch! NoSQL steht für „not only SQL“. Damit ist SQL nicht per Definition ausgeschlossen.