Diese skalierbaren SQL-Datenbanken bieten sowohl horizontale Skalierbarkeit als auch Unterstützung für ACID-Transaktionen - teilweise sogar auf globaler Ebene. [...]
Relationale SQL-Datenbanken, die es bereits seit den 1980er Jahren gibt, liefen historisch gesehen auf Mainframes oder einzelnen Servern – das war alles, was wir zu diesem Zeitpunkt hatten. Wenn Sie wollten, dass die Datenbank mehr Daten verarbeitet und schneller läuft, mussten Sie sie auf einen größeren Server mit mehr und schnelleren CPUs, Arbeitsspeicher und Festplatten auslagern. Mit anderen Worten, Sie haben sich dann für eine vertikale Skalierbarkeit oder „scale-up“ entschieden. Wenn Sie später die Möglichkeit eines Fail-Overs zur Verbesserung der Erreichbarkeit benötigten, konnten Sie einen Hot-Backup-Server mit dem aktiven Server in einem „aktiv-passiven“ Cluster zusammenstellen, typischerweise mit gemeinsamem Speicher.
Die vier ACID-Eigenschaften – Atomicity, Consistency, Isolation und Durability – sind erforderlich, um sicherzustellen, dass Datenbanktransaktionen immer gültig sind, auch im Falle von Netzwerkpartitionen, Stromausfällen und anderen Fehlern. Es ist relativ einfach für eine Datenbank auf einem einzelnen Server, alle vier ACID-Eigenschaften zu erfüllen; für eine verteilte Datenbank ist die Implementierung allerdings etwas schwieriger.
NoSQL-Datenbanken, die um 2009 eingeführt wurden, boten horizontale Skalierbarkeit (d.h. sie konnten auf mehreren Servern ausgeführt werden), waren aber oft nicht vollständig ACID-konform und unterstützten die SQL-Sprache als solche in der Regel nicht. NoSQL-Datenbanken führten die Idee der „eventuellen Konsistenz“ ein, was bedeutet, dass, wenn Sie von einem Server in die Datenbank geschrieben und sofort von einem anderen aus gelesen haben, Sie möglicherweise nicht die gleichen Ergebnisse erhalten, wie Sie sie von dem Server lesen würden, auf dem Sie gerade geschrieben hatten. Wenn Sie jedoch lange genug warteten, würden die neuen Daten auf alle Server im Cluster repliziert und wären dann konsistent. Die Konsistenz ist für viele Anwendungen, wie z.B. Online-Kataloge, gut genug, aber nicht gut genug für das Finanzwesen.
Vor kurzem wurden mehrere „scale-out“-SQL-Datenbanken eingeführt, die horizontal skalierbar sind. Noch besser ist, dass einige von ihnen mit geografisch verteilten Servern umgehen können, ohne die Konsistenz zu beeinträchtigen. Extrem weit entfernte Serverknoten benötigen aufgrund der Begrenzung durch die Lichtgeschwindigkeit mehr Zeit für die Aktualisierung als lokale Knoten, aber mehrere Verfahren können dieses Problem mildern, einschließlich der Verwendung von Consensus Group Quora und sehr schneller Netzwerkanbindung und Speicherung.
Im Allgemeinen sollten die von Ihnen verwendete Datenbank und die neue verteilte Datenbank, die Sie verwenden möchten, so kompatibel wie möglich sein, um die Konvertierungskosten für Schemata und Anwendungen zu minimieren. Im einfachsten Fall können Sie Ihr Schema und Ihre Daten migrieren und dann einfach eine Verbindungszeichenfolge in Ihrer Anwendung ändern. Im kompliziertesten Fall müssen Sie einen Datenkonvertierungsprozess durchlaufen, eine komplette Neuschreibung Ihrer gespeicherten Prozeduren und Trigger sowie eine umfassende Neuschreibung der Datenebenen Ihrer Anwendungen, einschließlich Ihrer SQL-Abfragen.
Amazon RDS und Amazon Aurora
Amazon RDS (Relational Database Service) ist ein Webservice, der das Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud vereinfacht. Amazon RDS unterstützt MySQL, MariaDB, PostgreSQL, Oracle-Datenbank und Microsoft SQL Server.
Amazon RDS-Datenbanken können für eine hohe Verfügbarkeit mit einer synchronen Sekundärinstanz für den Fail-Over konfiguriert werden. Leider können Sie nicht aus der Standby-Sekundärinstanz heraus lesen. Sie können MySQL, MariaDB oder PostgreSQL Read Replicas verwenden, um die Leseskalierung zu erhöhen, aber die Replikation ist asynchron, so dass der Zustand der Replik möglicherweise hinter dem Zustand der Primärinstanz liegt.
Amazon Aurora ist ein Service innerhalb von Amazon RDS, der leistungsstarke Cluster von MySQL- und PostgreSQL-Datenbanken auf schnellem, verteiltem Speicher anbietet. Sie können bis zu 15 Aurora-Replikate in Ihrem Datenbank-Cluster erstellen, um schreibgeschützte Abfragen zu unterstützen, und Sie können die Replikate in mehreren Verfügbarkeitszonen (AZ) erstellen, was eine globale Verteilung ermöglicht.
Laut Amazon kann Aurora den bis zu fünffachen Durchsatz von MySQL und den bis zu dreifachen Durchsatz von PostgreSQL liefern, ohne dass Änderungen an den meisten Ihrer bestehenden Anwendungen erforderlich sind. Amazon gibt auch eine Verzögerungszeit von ca. 20 Millisekunden für die Aktualisierung von Aurora-Readereplikaten an, was viel schneller ist als MySQL-Readereplikate.
Azure SQL Database
Azure SQL Database ist ein vollständig verwalteter relationaler Cloud-Datenbankdienst, der eine breite Kompatibilität mit der SQL Server-Engine bietet und es Ihnen ermöglicht, Datenbankressourcen dynamisch auf- und abzubauen. Azure SQL Database beinhaltet die Option, aktive Georepliken zu erstellen, die geografisch verteilte Sekundärdatenbanken sind.
Bis zu vier Sekundäre werden in den gleichen oder verschiedenen Regionen unterstützt, und die Sekundäre können auch für schreibgeschützte Abfragen verwendet werden. Wenn Sie die primäre Datenbank auf eines der Sekundärprogramme auslagern müssen, können Sie dies manuell oder über eine API tun.
ClustrixDB
ClustrixDB, jetzt im Besitz von MariaDB, ist eine skalierbare, geclusterte relationale HTAP-Datenbank (Hybrid Transaction/analytical Processing), die mit einer Shared-Nothing-Architektur entwickelt wurde. ClustrixDB ist weitgehend kompatibel mit MySQL und MariaDB. Bei der Überprüfung von ClustrixDB fehlte dem Produkt die Unterstützung für räumliche Erweiterungstypen und Volltextsuche; beide fehlten bis zum letzten Release.
Das Hinzufügen eines Knotens zu ClustrixDB skaliert sowohl Lesen als auch Schreiben. ClustrixDB ermöglicht die zonenübergreifende Bereitstellung von Clustern, um eine Fehlertoleranz bei ungeplantem Zonenausfall zu gewährleisten. In Tests, die von einem unabhängigen Labor (aber nicht von InfoWorld) durchgeführt wurden, konnte ClustrixDB 40.000 Transaktionen pro Sekunde bei 15 Millisekunden Latenzzeit mit einer Last von 90% Lese- und 10% Schreibzugriff erreichen, was ihm die „Cyber Monday“ Skalierbarkeit für E-Commerce verleiht.
CockroachDB
CockroachDB ist eine Open-Source-, horizontal skalierbare, verteilte, PostgreSQL-kompatible SQL-Datenbank, die von Ex-Googlern entwickelt wurde, die mit Google Cloud Spanner vertraut sind. CockroachDB leiht sich von Spanner den Entwurf seines Datenspeichersystems, und es verwendet einen Raft-Algorithmus, um einen Konsens zwischen seinen Knoten zu erreichen. CockroachDB benötigt keine GPS- und Atomuhren, die Spanner synchronisieren.
CockroachDB basiert auf einem transaktionalen und konsistenten Key-Value-Speicher, RocksDB. Die primären Designziele hinter CockroachDB sind die Unterstützung von ACID-Transaktionen, horizontale Skalierbarkeit und (vor allem) Überlebensfähigkeit, daher der Name. CockroachDB verwendet standardmäßig den serialisierbaren Isolationsmodus, der eine stärkere Isolation darstellt als die meisten anderen Datenbanken.
Als ich Anfang 2018 die CockroachDB überprüfte, war ihre JOIN-Performance nicht sehr gut. Das wurde inzwischen behoben. CockroachDB unterstützt die Verteilung eines Clusters über mehrere Verfügbarkeitszonen und bietet auch vollständig verwaltete Cloud-Datenbank-Cluster auf der Google Cloud Platform oder den Amazon Web Services.
Google Cloud Spanner
Google Cloud Spanner ist eine verwaltete verteilte Datenbank, die die Skalierbarkeit von NoSQL-Datenbanken bietet und gleichzeitig SQL-Kompatibilität, relationale Schemata, ACID-Transaktionen und externe Konsistenz beibehält. Spanner kommt dem Umgehen des CAP-Theorems sehr nahe.
Spanner ist zersplittert, global verteilt und repliziert und verwendet einen Paxos-Algorithmus, um einen Konsens zwischen seinen Knoten zu erreichen. Es verwendet zweiphasige Commits für eine hohe Konsistenz, betrachtet Paxos-Gruppen jedoch als Mitglieder der Transaktion. Jede Paxos-Gruppe benötigt nur ein Quorum, um verfügbar zu sein, nicht 100 Prozent ihrer Mitglieder.
Im internen Einsatz bei Google hat Spanner eine Verfügbarkeit von mehr als fünf Neunen gezeigt, d.h. besser als 99,999 Prozent, was weniger als fünf Minuten Ausfallzeit pro Jahr bedeutet. Das ist gut genug, dass sich die meisten Programmierer normalerweise nicht die Mühe machen, Code zu schreiben, um Fehler bei der Verfügbarkeit des Schlüssels zu beheben.
Spanner verwendet Google Common SQL, einen Dialekt von ANSI 2011 SQL. Common SQL ist nicht genau dasselbe wie die SQL-Dialekte, die von PostgreSQL, MySQL, SQL Server oder Oracle Database verwendet werden, die sich etwas in den Datentypen und dramatisch im Bereich der Datenmanipulation unterscheiden.
*Martin Heller ist Mitredakteur und Reviewer der InfoWorld. Früher Berater für Web- und Windows-Programmierung, entwickelte er von 1986 bis 2010 Datenbanken, Software und Websites. Zuletzt war er als VP für Technologie und Ausbildung bei Alpha Software und als Chairman und CEO bei Tubifi tätig.
Be the first to comment