MySQL 5.6 und NoSQL

Seit der Akquisition von Sun Microsystems durch Oracle hat die quellenoffene MySQL-Datenbank, der Platzhirsch unter den SQL-Datenbanken, die eigene Position vor allem im Einstiegsbereich und im Mittelfeld für professionelle Datenbanken enorm gefestigt.

Da praktisch allen Unix-Distributionen ohne Ausnahme standardmäßig das quelloffene Webmaster-Paket bestehend aus Apache Webserver 2.4.x, PHP 5.4.x und eben MySQL 5.6 beiliegt, konnte MySQL auch die größte Verbreitung unter den SQL-Datenbanken erreichen und ist die meist genutzte quelloffene Datenbank weltweit.

Obwohl MySQL-Anwender in den letzten Jahren immer öfter an die Leistungsgrenzen von MySQL stoßen mussten, hat diese beliebte relationale Datenbank an ihrer Popularität nichts verloren und kann auf 65.000 Downloads pro Tag verweisen.

NoSQL in MySQL

Immer mehr Website-Betreiber, insbesondere im Bereich des E-Commerce, kommen mit konventionellen relationalen Datenbanken nicht mehr aus. Das explosionsartige Wachstum an Datenvolumen, die Mehrdimensionalität der Datenstrukturen, gekoppelt an die Notwendigkeit, Datenbankabfragen ungeachtet ihrer Komplexität absolut verzögerungsfrei auszuführen, lassen konventionelle RDBMS an ihre Grenzen stoßen.

Wenn es länger dauert, die Daten aus der Datenbank zu extrahieren, als diese Daten benötigt werden, wird das ganze Konzept einer Datenbank ad absurdum geführt.Traditionelle, also strukturierte, Datensätze lassen sich sehr gut in einer SQL-Datenbank erfassen und verwalten (vorausgesetzt, dass die Menge der Daten die Serverkapazitäten nicht übersteigt). Nicht strukturierte Daten wie die Messwerte einer mobilen App eines Smartphones oder die Klickströme einer Webanwendung lassen sich in relationalen Datenbanken nicht wirklich effizient handhaben.

Unhandlich große Datenbestände, im Fachjargon "Big Data" genannt, machen Website-Betreibern insbesondere im Bereich des E-Commerce neuerdings zu schaffen. Betreiber von Web-Shops sammeln detaillierte Daten über das Klickverhalten der Käufer, doch wenn die Auswertung der Daten nicht schnell genug stattfinden kann, weil die Datenbank zu lange braucht, um Abfragen auszuführen, kann man dem Webshop-Besucher nicht rechtzeitig Produktempfehlungen anzeigen, bevor er die Seite wieder verlässt.

Dadurch geht möglicherweise Umsatz verloren. Hinzu kommen Herausforderungen im Hinblick auf die Skalierbarkeit einer reinen SQL-Datenbank, insbesondere bei einer hohen Anzahl gleichzeitiger Verbindungen.

Leistungsengpässe bei RDBMs entstehen zwangsläufig dadurch, dass sich komplexe Datenstrukturen in strukturierten Tabellen einer vorab definierten Größe nicht effizient verwalten lassen. Wie konstruiert man überhaupt ein Datenbankschema, wenn noch gar nicht bekannt ist, welche Daten erfasst werden sollen? Hier kommt eben NoSQL ins Spiel.

Eine NoSQL-Datenbank benutzt kein festes, vorab definiertes Datenbankschema. Die Datensätze haben eine variable Anzahl von Einträgen, um eine höhere Effizienz im Umgang mit Ressourcen der Datenbankserver zu ermöglichen. Sowohl die Speicherkapazität als auch die Rechenleistung lassen sich durch das Hinzufügen zusätzlicher Serverknoten zur Laufzeit erweitern.

Anstatt auf die Verfügbarkeit gemeinsam genutzter Hardware (etwa eines SAN-Speichers) zu warten, greift jeder Server auf eigene, lokal vorhandene Komponenten zu und erzielt dadurch wesentlich geringere Latenzzeiten sogar auf deutlich günstigerer Hardware. Beim partitionierten Datenspeicher einer NoSQL-Datenbank handelt es sich nicht mehr um einen monolithischen, zentral zu verwaltenden Block.

Das NoSQL-Konzept bevorzugt eine extrem hohe Leistung, allerdings auf Kosten der Datenintegrität. Mit dem lange ersehnten Update von MySQL auf die Version 5.6 versucht Oracle, das Beste aus beiden Welten in einem vertrauten Produkt zu verbinden.

Rundum erneuert

Das Update auf die Version 5.6 bringt zahlreiche strategische Verbesserungen, allen voran eine NoSQL-Schnittstelle und eine deutlich höhere Abfrage-Performance.

Die neuen NoSQL-artigen memcached-APIs, die vielen nützlichen Erweiterungen der InnoDB-Funktionalität sowie wichtige Optimierungen im Bereich der Partitionierung, Replizierung und Sicherheit markieren dieses Update als einen wichtigen Meilenstein in der Evolution dieser beliebten kostenfreien Datenbank.

Auf Grund der steigenden Relevanz sozialer Netze entstehen große Mengen unstrukturierter Daten, welche sich nur schwer in relationalen Datenbanken wie MySQL handhaben lassen. Dabei ist es für die Betreiber von E-Commerce-Websites immer wichtiger, massiv viele gleichzeitige Zugriffe auf große Datenbestände in akzeptabel kurzer Zeit durchzuführen, um das Besucherverhalten in Echtzeit lenken zu können.

Um Herausforderungen, nicht strukturierte Daten und SQL-Leistungsengpässe zu entschärfen, hat Oracle MySQL in der Version 5.6 mit einer NoSQL-Schnittstelle ausgestattet.

Die wichtigsten Optimierungen in MySQL 5.6 betreffen Zugriffe über das Memcached-API auf InnoDB-Tabellen. Wer aus der NoSQL-Funktionalität in MySQL 5.6 Nutzen ziehen möchte, muss sich daher mit InnoDB anfreunden. Oracle implementierte Memcached für InnoDB als einen Daemon (einen Hintergrundprozess), der sich in Form eines Plug-ins in den MySQL-Prozess einhängt.

Das Memcached-Protokoll wurde hierbei auf die native InnoDB-API gemappt. Da der Memcached-Daemon nun aber im selben Speicherbereich wie der Hauptprozess abläuft, sind die Latenzzeiten minimal und das, obwohl MySQL die Skalierbarkeit von InnoDB bereits in der einfachsten Konfiguration der Produktionsumgebung voll ausloten kann.

Darstellungsprobleme auf Tablets beheben

Gleichzeitig kann MySQL problemlos die Auswertung von SQL-Abfragen fortsetzen, sodass dem Anwender das ganze Spektrum moderner Funktionalität der InnoDB-Speicherengine (darunter Foreign Keys, XA-Transaktionen und komplexe JOIN-Operationen) zur Verfügung steht.

InnoDB auf Hochtouren

Die wichtigsten Verbesserungen in MySQL 5.6 konzentrieren sich auf die Performance der Speicherengine InnoDB. Bereits in MySQL 5.5 avancierte InnoDB zur voreingestellten Speicherengine. Aufgrund der bisher fehlenden Volltextsuche mieden es jedoch die Anwender.

MySQL 5.6 hat diesen Mangel behoben. Anwender können nun endlich FULLTEXT-Indizes aus InnoDB-Tabellen erstellen und diese unter Verwendung von MATCH( ) ... AGAINST durchsuchen.

Bei den Indizes handelt es sich selbst um InnoDB-Tabellen. Dank der durchdachten Volltextsuche entfallen beim Einsatz von InnoDB nun endlich externe Lösungen wie Solr/Lucene oder die Sphinx-Suchmaschine.

Hinzu kamen außerdem ein neuer Nachbarschaftssuchoperator @ sowie einige neue Optionen und Tabellen vom Typ INFORMATION_SCHEMA.

In MySQL 5.6 lassen sich Webapplikationen erstellen, die über das NoSQL-API auf Daten im InnoDB-Format zugreifen. Dabei kommt der beliebte memcached-Daemon zum Einsatz, der hierzu Anfragen an Schlüssel-Wert-Paare mittels ADD, SET und GET ausführt. Diese einfachen Operationen zum Speichern und Abrufen von Daten vermeiden den SQL-Überhang.

Sie können auf dieselben Daten sowohl über das NoSQL-API als auch mittels SQL zugreifen. Es empfiehlt sich, schnelle Updates oder einfache Lookups über das NoSQL-API auszulösen und SQL bevorzugt für komplexe Abfragen und zur Abwärtskompatibilität mit Altlasten- Applikationen zu nutzen.

Praxisnahe Verbesserung

Die Daten-Replikation in MySQL 5.6 ist deutlich robuster geworden. Zuvor wurde die aktuelle Leseposition des Masters und die Änderungsposition des Slave in den Dateien relay-log.info und master.info vermerkt.

Im normalen Betrieb war diese Information nur von mäßiger Relevanz, doch nach einem Absturz konnte es schon einmal vorkommen, dass die Angaben in diesen beiden Dateien nicht mehr die Realität reflektierten. Beim nachfolgenden Neustart der Datenbank entstanden oft entweder Lücken im Datenstrom oder es wurden Duplikate bereits verzeichneter Daten neu eingefügt.

Diese Informationen über die Replikation lassen sich nun in den Datenbanktabellen sichern. Hierzu müssen die Variablen

und

auf den Wert TABLE gesetzt werden. Da der Server diese beiden Tabellen aber leider noch als MyISAM anlegt, muss der Administrator die Konvertierung ins InnoDB-Format immer noch von Hand vornehmen.

MySQL 5.6 führt außerdem eine neue globale Transaktions-ID (GTID) ein, mit deren Hilfe eine Transaktion eindeutig identifiziert werden kann. Die GTID identifiziert auch einen Master/Slave-Replikationsvorgang eindeutig für den betreffenden MySQL-Server und dürfte die Handhabung enorm vereinfachen.

Tools wie mysqlfailover, mysqlreplcheck, mysqlrpladmin und mysqlrplshow, die Oracle für MySQL bereitgestellt hat, sollen das Ganze noch weiter vereinfachen. Für Transaktionen mit Nur-Lesezugriffen hielt InnoDB bisher interne Datenstrukturen vor; diese sind nun überflüssig.

Geld verdienen mit Blogs

In der Version 5.6 kann die InnoDB-Engine in bestimmten Fällen sogar selbstständig ermitteln, dass es sich um eine nur lesende Transaktion handelt, und den Vorgang automatisch optimieren. Alternativ können Sie mit START TRANSACTION READ ONLY eine Transaktion explizit als nur lesend kennzeichnen. Dabei gilt es allerdings zu beachten, dass solche Transaktionen in der Ausgabe von SHOW ENGINE INNODB STATUS leider nicht mehr verzeichnet sind.

Schreibzugriffe auf SSD auslagern

Erstmals in MySQL 5.6 können Sie einzelne Tabellen auf bestimmte Laufwerke auslagern, sei es, um die Leistung der Datenbank zu verbessern oder den verfügbaren Platz besser nutzen zu können.

So können Sie beispielsweise besonders stark angefragte Teile der Datenbank auf SSD-Platten sichern, zum Beispiel:

Dadurch maximieren Sie den Nutzen der hohen Datentransferraten einer SSD-Platte, ohne sich gleich in hohe Kosten zu stürzen; seltener genutzte Tabellen können dann nach wie vor auf Festplatten Platz finden. Der Einsatz dieser Funktion schließt sich leider mit der Benutzung von LVM-Snapshots aus.

Um eine effizientere Nutzung von SSDs zu ermöglichen, erhielt MySQL in der Version 5.6 die Fähigkeit, mit einer geringeren Page-Größe zu arbeiten. Anstelle der standardmäßigen 16 KByte (MySQL 5.5) kommt MySQL nun auch mit einer Page-Größe von 8 KByte oder gar 4 KByte zurecht.

Eine kleinere Page-Größe macht sich insbesondere dann positiv bemerkbar, wenn die Datentransferrate zwischen dem Arbeitsspeicher und dem Dauerspeichermedium einen relevanten Engpass darstellt und die Datenbank viele gleichzeitige Zugriffe verarbeiten muss. Den benötigten Wert bestimmt der Parameter innodb_page_size.Mit der Option

können Sie einen MySQL-Server im Nur-Lesemodus betreiben. Dadurch besteht für Sie die Möglichkeit, InnoDB-Tabellen aus nicht beschreibbaren Medien wie CDs oder DVDs auszulesen, oder ein Data-Warehouse-System mit mehreren Instanzen einzurichten, die ein gemeinsames Verzeichnis benutzen.

Verbesserte Integration

MySQL-Benutzer können die Daten aus MySQL unter Verwendung von Apache Sqoop an das HDFS-Dateisystem (Hadoop Distributed File System) oder verwandte Dateisysteme wie Hive oder HBase übertragen, um verteilte Computer zu einer logischen Recheneinheit effizient zusammenzuschließen.Zum Importieren von Daten aus einer MySQL-Datenbank namens imdb in Hadoop durch den Benutzer benutzer genügt etwa ein Befehl in der Form

Hadoop sichert die Daten in Verzeichnissen, die nach der jeweiligen Tabelle benannt sind. Der Datenimport in HBase gelingt mit Sqoop unter Verwendung einer Anweisung in der Form:

Auch der umgekehrte Weg ist vorgesehen: So können Sie Daten aus Hadoop extrahieren und für einen externen Datenspeicher wie eben die relationale Datenbank MySQL ausgeben. Dank der Integration mit Apache Oozie, einer serverseitigen Workflow-Engine von Cloudera, können Benutzer diese Datenübertragungstasks zeitgesteuert ausführen.

Sqoop beinhaltet standardmäßig nicht nur eine generische JDBC- sowie eine MySQL-Schnittstelle, sondern bringt auch einen spezialisierten Connector für direkte Hochleistungsverbindungen zu MySQL mit.

Fazit

Mit der Version 5.6 der quelloffenen Datenbank MySQL legt Oracle dort nach, wo die Datenbank-Administratoren Verbesserungen dringend gefordert hatten, nämlich bei der Ausführung einer hohen Anzahl gleichzeitiger Zugriffe.

Das NoSQL-Interface in MySQL 5.6 setzt direkt auf der Storage-Engine InnoDB auf und stellt eine geschickt durchgeführte evolutionäre Verbesserung dar. So können Sie mit einfachen Anfragen unter Verwendung von Schlüssel-Wert-Paaren die SQL-Ebene umgehen, um die Zugriffsgeschwindigkeit zu maximieren, ohne die Leistungsbereitschaft des SQL-Servers zu beschneiden.