Damals, als jemand MySQL sagte, gab es nur MySQL. Sie konnten verschiedene Versionen (4.0, 4.1) auswählen, aber der Anbieter war derselbe. Dies änderte sich um MySQL 5.0/5.1 herum, als Percona beschloss, eine eigene Variante von MySQL zu veröffentlichen – Percona Server. Etwas später kam MariaDB mit MariaDB 5.1 hinzu und der Spaß (oder die Verwirrung) nahm zu. Welche Version sollte ich verwenden? Was ist der Unterschied zwischen MySQL 5.1, Percona Server 5.1 und MariaDB 5.1? Welche ist schneller? Welche ist stabiler? Welche hat überlegene Funktionalität? Mit der Zeit wurde dies schlimmer, da mehr und mehr Änderungen in jedem der Geschmacksrichtungen eingeführt wurden. Dieser Blogbeitrag ist unser Versuch, die wichtigsten Merkmale zusammenzufassen, die sie voneinander unterscheiden. Wir werden auch versuchen, Ihnen einige Vorschläge zu machen, welche Geschmacksrichtung für eine bestimmte Art von Projekt am besten geeignet ist. Fangen wir an.
Oracle-MySQL
Früher war es MySQL, jetzt ist es der Upstream. Der größte Teil der Entwicklung beginnt hier, jede Version ab 5.6 löst einige interne Konflikte und bringt eine bessere Leistung. Auch neue Features werden regelmäßig hinzugefügt. MySQL 5.6 brachte uns (unter anderem) GTID und eine erste Implementierung der parallelen Replikation. Es gab uns auch die Möglichkeit, die meisten ALTERs online auszuführen. Werfen wir einen Blick auf die Funktionen der neuesten MySQL-Version – MySQL 5.7
Merkmale von MySQL 5.7
Eine der wichtigsten Änderungen sind Änderungen im Bereitstellungsprozess – anstelle verschiedener Skripts können Sie einfach mysqld --initialize ausführen, um MySQL von Grund auf neu einzurichten. Eine weitere sehr wichtige Änderung – parallele Replikation basierend auf logischer Uhr. Schließlich können wir die parallele Replikation in allen Fällen verwenden - egal, ob Sie mehrere Schemas verwenden oder nicht. Eine weitere Verbesserung der Replikation ist die Replikation aus mehreren Quellen – ein 5.7-Slave kann mehrere Master haben – eine großartige Funktion, wenn Sie einen Aggregations-Slave erstellen und beispielsweise Daten aus mehreren separaten Clustern kombinieren möchten.
InnoDB begann mit der Unterstützung räumlicher Typen, der InnoDB-Pufferpool kann endlich zur Laufzeit geändert werden, Online-ALTERs wurden verbessert, um mehr Fälle wie Partitionierung und No-Op-ALTERs zu unterstützen.
MySQL hat damit begonnen, JSON-Datentypen nativ zu unterstützen, zusammen mit mehreren neuen Funktionen, die sich darauf konzentrieren, Funktionen rund um JSON hinzuzufügen. Die Sicherheit Ihrer Daten ist heutzutage sehr wichtig, MySQL 5.7 unterstützt Data-at-Rest-Verschlüsselung für File-per-Table-Tablespaces. Einige Verbesserungen wurden auch bei der SSL-Unterstützung hinzugefügt (SSL wird konfiguriert, wenn Schlüssel vorhanden sind, ein Skript ist enthalten, das zum Erstellen von Zertifikaten verwendet werden kann). Aus Sicht der Benutzerverwaltung wurde die Einrichtung der Kennwortlebensdauer hinzugefügt, was das Design von Kennwortablaufrichtlinien etwas einfacher machen sollte.
Eine weitere Funktion, die DBAs unterstützen soll, ist das „sys“-Schema, eine Reihe von Ansichten, die die Verwendung des Performance-Schemas vereinfachen sollen. Es ist standardmäßig in MySQL 5.7 enthalten.
Schließlich wurde MySQL Group Replication (und schließlich MySQL InnoDB Cluster) zu MySQL 5.7 hinzugefügt. Es funktioniert als Plugin und ist in neueren Versionen des 5.7-Zweigs enthalten, aber das ist ein eigenes Thema. Kurz gesagt, die Gruppenreplikation ermöglicht Ihnen den Aufbau eines „virtuell“ synchronen Clusters.
Dies ist definitiv keine vollständige Liste der Funktionen - wenn Sie an allen interessiert sind, können Sie die MySQL 5.7-Dokumentation zu Rate ziehen.
Percona-Server
Am Anfang gab es eine Reihe von Patches für den MySQL-Quellcode, die einige Leistungsverbesserungen und Funktionen hinzufügten. Irgendwann beschloss Percona, einen eigenen Build von MySQL zu veröffentlichen, der diese Patches enthielt. Mit der Zeit wurden mehr Entwicklungsressourcen verfügbar, sodass immer mehr Funktionen hinzugefügt wurden.
Im Allgemeinen können Sie Percona Server als die neueste MySQL-Version mit mehreren Patches/Verbesserungen ansehen. Mit der Zeit werden einige der Funktionsverbesserungen von Percona Server durch Funktionen von Upstream ersetzt – immer dann, wenn Oracle eine Funktion entwickelt, die eine der in Percona Server hinzugefügten Funktionen ersetzt. Solange die Implementierung auf Augenhöhe ist, entfernt Percona ihren eigenen Code zugunsten von Code aus dem Upstream. Dies macht Percona Server im Grunde zu einem Drop-in-Ersatz für MySQL von Oracle. Einer der Bereiche, in denen große Leistungsverbesserungen vorgenommen wurden, ist InnoDB. Es wurde erheblich genug modifiziert, um es als XtraDB zu brandmarken. Derzeit ist es vollständig kompatibel mit InnoDB, aber das war nicht immer so. Beispielsweise waren einige Funktionen in Percona Server 5.5 nicht mit MySQL 5.5 kompatibel. Dies gilt auch für neuere Versionen von Percona Server. Wichtig ist, dass Percona Server standardmäßig mit allen inkompatiblen Funktionen deaktiviert ist – es macht es einfach, es zu testen und bei Bedarf auf MySQL von Oracle zurückzusetzen. Unter Berücksichtigung des oben Gesagten sollten Sie trotzdem Vorsicht walten lassen, wenn Sie planen, von Percona Server zu MySQL zu migrieren – jemand könnte eine der inkompatiblen Funktionen aktiviert haben.
Hervorzuheben ist, dass Percona bestrebt ist, Unternehmensfunktionen des Upstreams neu zu implementieren. Beispiele für MySQL sind die Implementierung eines Thread-Pools oder eines PAM-Authentifizierungs-Plugins. Werfen wir einen kurzen Blick auf einige der Funktionen des Percona-Servers.
Funktionen von Percona Server 5.7
Eines der Hauptmerkmale von XtraDB ist die verbesserte Pufferpool-Skalierbarkeit – obwohl es aufgrund der Arbeit, die Oracle an jeder MySQL-Version leistet, immer weniger Konflikte gibt, ist das Engineering-Team von Percona bestrebt, die Leistung noch weiter zu steigern und zusätzliche Mutexe zu entfernen, die die Leistung einschränken können. Zusätzlich werden mehr Daten in Bezug auf Konflikte innerhalb von InnoDB in den InnoDB-Monitor (zugänglich über SHOW ENGINE INNODB STATUS) geschrieben – z. B. wurde ein Abschnitt über Semaphoren hinzugefügt.
Eine weitere Reihe von Verbesserungen wurden im Bereich I/O vorgenommen. In InnoDB können Sie eine Flush-Methode nur für InnoDB-Tablespaces festlegen, was zu einer doppelten Pufferung für InnoDB-Redo-Logs führt. XtraDB ermöglicht es, O_DIRECT auch für diese Dateien zu verwenden. Außerdem werden der Ausgabe von SHOW ENGINE INNODB STATUS weitere Daten zum Checkpointing hinzugefügt. Darüber hinaus wurden ein paralleler Doublewrite-Puffer und ein Multithread-LRU-Flusher implementiert, um Konflikte bei I/O-Operationen innerhalb von InnoDB zu reduzieren.
Thread-Pool ist eine weitere Funktion, die von Percona Server zur Verfügung gestellt wird. In Oracle MySQL ist es nur in der Enterprise Edition verfügbar. Hier können Sie die Implementierung von Percona kostenlos verwenden. Im Allgemeinen reduziert der Thread-Pool Konflikte, während er eine große Anzahl von Verbindungen von der Anwendung bedient, indem vorhandene Verbindungen zur Datenbank wiederverwendet werden.
Zwei weitere Funktionen sind direkte Ersetzungen von Funktionen aus der Enterprise-Version von MySQL. Eines davon ist das von Percona entwickelte PAM-Authentifizierungs-Plugin, das die Verwendung vieler verschiedener Authentifizierungsoptionen wie LDAP, RSA SecurID oder anderer von PAM unterstützter Methoden ermöglicht. Die zweite Funktion bezieht sich auch auf die Sicherheit - das Audit-Log-Plugin. Es wird eine Datei mit einer Aufzeichnung der auf dem Datenbankserver durchgeführten Aktionen erstellt.
Von Zeit zu Zeit führt Percona signifikante Verbesserungen an anderen Speicher-Engines ein, wie z. B. die Änderungen, die sie an der MEMORY-Engine vorgenommen haben, die es ermöglichten, Daten vom Typ VARCHAR oder BLOB zu verwenden.
Die Einführung von Backup-Sperren war ebenfalls eine ziemlich signifikante Verbesserung. In Oracle und MariaDB war die einzige Methode zum Sperren der Tabelle, um eine konsistente Sicherung zu erhalten, die Verwendung von FLUSH TABLES WITH READ LOCK (FTWRL). Es ist ziemlich schwer und zwingt MySQL, alle geöffneten Tabellen zu schließen. Sicherungssperren hingegen verwenden einen leichteren Ansatz von Metadatensperren. In vielen Fällen von stark ausgelasteten Servern, die FTWRL ausführen, dauert es zu lange (und sperrt den Server zu lange), um als machbar angesehen zu werden, während Backup-Sperren es ermöglichen, ein Backup mit mysqldump oder xtrabackup zu erstellen.
Percona ist auch offen für die Portierung von Funktionen anderer Anbieter. Ein solches Beispiel ist die Portierung von MariaDBs START TRANSACTION WITH CONSISTENT SNAPSHOTS. Diese Funktion bezieht sich auch auf Backups - mit ihrer Hilfe können Sie ein konsistentes logisches Backup (mit mysqldump) erstellen, ohne FLUSH TABLE WITH READ LOCK auszuführen.
Abschließend drei Features, die die Beobachtbarkeit verbessern - erstens:Benutzerstatistiken. Dies ist eine ziemlich leichte Funktion, die Daten über Benutzer, Indizes, Tabellen und Threads sammelt. Damit können Sie ungenutzte Indizes finden oder feststellen, welcher Benutzer für die Last auf dem Server verantwortlich ist. Derzeit ist es teilweise redundant zu performance_schema, aber es ist etwas leichter und wurde in den Tagen von MySQL 5.0 - 5.1 erstellt, als niemand auch nur von performance_schema träumte.
Zweitens – erweitertes Protokoll für langsame Abfragen. Wieder wurde es in Zeiten hinzugefügt, in denen die höchste Granularität von long_query_time 1 Sekunde war. Mit dieser Ergänzung hatten Sie Mikrosekunden-Granularität und eine Reihe zusätzlicher Daten über InnoDB-Statistiken pro Abfrage oder seine allgemeinen Leistungsmerkmale. Hat es eine temporäre Tabelle erstellt? Wurde ein Index verwendet? Wurde es im MySQL-Abfrage-Cache zwischengespeichert?
Drittes Feature, das wir oben ein paar Mal erwähnt haben – Percona Server legt deutlich mehr Daten in SHOW ENGINE INNODB STATUS offen als im Upstream. Es hilft definitiv, die Arbeitsbelastung besser zu verstehen und mehr Probleme zu erkennen, bevor sie sich entfalten.
Natürlich ist dies keine vollständige Liste - wenn Sie an weiteren Details interessiert sind, können Sie die Dokumentation von Percona Server lesen.
MariaDB
MariaDB begann als Fork von MySQL, aber nachdem ein Teil des ursprünglichen MySQL-Entwicklungsteams zu MariaDB kam, konzentrierte es sich schnell darauf, Funktionen hinzuzufügen. In MariaDB 5.3 wurden dem Optimierer viele Funktionen hinzugefügt:Batch Key Access, MultiRange Read, Index Condition Pushdown, um nur einige zu nennen. Dies ermöglichte es MariaDB, sich bei einigen Workloads zu übertreffen, bei denen MySQL oder Percona Server Probleme hatten. Bis jetzt wurden einige dieser Funktionen zu MySQL hinzugefügt (hauptsächlich in MySQL 5.6), aber einige sind immer noch einzigartig für MariaDB.
Ein weiteres wichtiges Feature, das von MariaDB eingeführt wurde, war die Global Transaction ID. Nicht viel später veröffentlichte Oracle seine eigene Implementierung, aber MariaDB war die erste, die sie hatte. Ähnlich verhält es sich mit einer anderen Replikationsfunktion – Multisource-Replikation:MariaDB hatte sie vor Oracle. Jetzt enthält die kürzlich veröffentlichte MariaDB 10.2 auch Funktionen, die in MySQL 8.0 verfügbar gemacht werden, das sich noch in der Entwicklung befindet. Wir sprechen zum Beispiel von rekursiven allgemeinen Tabellenausdrücken oder Fensterfunktionen.
Merkmale von MariaDB 10.2
Wie bereits erwähnt, führt MariaDB 10.2 Fensterfunktionen und rekursive allgemeine Tabellenausdrücke ein – Erweiterungen in SQL, die Entwicklern helfen sollen, effizientere SQL-Abfragen zu schreiben.
Eine sehr wichtige Änderung ist, dass MariaDB 10.2 InnoDB verwendet. Bis 10.1 wurde XtraDB als Standardspeicher verwendet. Dies macht leider Funktionen, die in der neuesten Version von XtraDB hinzugefügt wurden, für Benutzer von MariaDB 10.2 nicht verfügbar.
In virtuellen Spalten wurden Verbesserungen vorgenommen – in 10.2 wurden weitere Einschränkungen aufgehoben.
Schließlich wurde Unterstützung für mehrere Trigger für dasselbe Ereignis hinzugefügt – jetzt können Sie mehrere, zum Beispiel ON UPDATE-Trigger, für dieselbe Tabelle erstellen.
Entwickler sollten von der JSON-Unterstützung profitieren, zusammen mit einigen damit verbundenen Funktionen. Sie sollten auch neue Funktionen mögen, mit denen sie Geodaten in das GeoJSON-Format exportieren können. Apropos JSON, es wurden Verbesserungen an der EXPLAIN FORMAT=JSON-Ausgabe vorgenommen – es werden mehr Daten angezeigt.
An der Sicherheitsfront wurde Unterstützung für OpenSSL 1.1 und LibreSSL hinzugefügt.
Natürlich ist diese Liste nicht vollständig, und wenn Sie daran interessiert sind, was zu MySQL 10.2 hinzugefügt wurde, können Sie die Dokumentation konsultieren.
Zusätzlich zu den neuen Funktionen profitiert MariaDB 10.2 von Funktionen, die in früheren Versionen implementiert wurden. Wir gehen die wichtigsten durch.
Die wichtigsten Funktionen von MariaDB 10.1
Zunächst einmal wird MariaDB seit 10.1 mit dem Galera-Cluster gebündelt geliefert - es müssen keine zusätzlichen Bibliotheken installiert werden, alles ist einsatzbereit.
MariaDB 10.1 brachte die Implementierung der Data-at-Rest-Verschlüsselung. Im Vergleich zu der in MySQL von Oracle implementierten Funktion ist MariaDB erweitert. Es verschlüsselt nicht nur Tablespaces, sondern auch Redo-Logs, temporäre Dateien und Binärlogs. Dies ist mit einigen Problemen verbunden - CLI-Tools wie mysqldump oder xtrabackup können nicht auf Binärprotokolle zugreifen und haben möglicherweise Probleme beim Sichern verschlüsselter Instanzen (dies gilt insbesondere für xtrabackup - MariaDB hat kürzlich eine xtrabackup-Verzweigung namens MariaDB Backup erstellt, die ruhende Daten unterstützt Verschlüsselung).
Okay, welche Geschmacksrichtung soll ich verwenden?
Wie so oft wäre die richtige Antwort:„Kommt drauf an“ :-) . Wir werden einige unserer Beobachtungen teilen, die Ihnen bei der Entscheidung helfen können oder auch nicht, aber am Ende liegt es an Ihnen, Benchmarks durchzuführen und herauszufinden, welche Option für Ihre Umgebung und Anwendung am besten geeignet ist.
Lassen Sie uns zunächst über den Fluss sprechen. Oracle veröffentlicht neue Version – sagen wir mal MySQL 5.7. In Bezug auf die Leistung ist dies derzeit die schnellste MySQL-Variante auf dem Markt. Denn nur Oracle hat genug Ressourcen, um an der Verbesserung von InnoDB in diesem Umfang zu arbeiten. Innerhalb weniger Monate (im Falle von 5.7 waren es 4 Monate) veröffentlicht Percona Percona Server 5.7 mit einer Reihe von Verbesserungen - je nach Art der Arbeitslast kann es sogar eine bessere Leistung als der Upstream liefern. Schließlich übernimmt MariaDB die neue Upstream-Version und baut ihre neue Version darauf auf.
So sah es in einem Kalender aus (wir reden immer noch von MySQL 5.7).
MySQL 5.7 GA:21. Oktober 2015
Percona Server 5.7 GA:23. Februar 2016
MariaDB 10.2 GA:23. Mai 2017
Bitte beachten Sie, wie lange es gedauert hat, bis MariaDB eine auf MySQL 5.7 basierende Version veröffentlicht hat – alle vorherigen Versionen basierten auf MySQL 5.6 und lieferten offensichtlich eine geringere Leistung als MySQL 5.7. Andererseits wurde MariaDB 10.2 veröffentlicht, wobei InnoDB XtraDB ersetzt. Es stimmt zwar, dass Oracle die Leistungslücke zwischen MySQL und Percona Server größtenteils geschlossen hat, aber es ist immer noch nur „meistens“. Infolgedessen kann MariaDB 10.2 in einigen Fällen eine niedrigere Leistung als die von Percona Server liefern (und in einigen anderen Fällen eine bessere - aufgrund der Optimierungsarbeit in MariaDB 5.3, von denen einige noch nicht in MySQL neu erstellt wurden).
In Bezug auf die Funktionen ist es komplexer. MariaDB hat viele Funktionen hinzugefügt, wenn Sie also an einigen davon interessiert sind, sollten Sie auf jeden Fall die Verwendung von MariaDB in Betracht ziehen. Es gibt auch einen Nachteil. Percona Server hatte viele Funktionen, die es von Upstream-MySQL unterschieden, aber als Oracle begann, sie in MySQL zu implementieren, entschied Percona, ihre Implementierungen zugunsten der Verwendung der Implementierung von Upstream abzuwerten. Dies reduzierte die Menge an Code, die sich zwischen MySQL und Percona Server unterscheidet, erleichtert die Wartung des Codes von Percona Server und, was am wichtigsten ist, macht Percona Server zu 100 % kompatibel mit MySQL.
Dies gilt leider nicht für MariaDB. MariaDB führte zuerst GTID ein, das stimmt, aber nachdem Oracle seine Version von GTID entwickelt hatte, beschloss MariaDB, an ihrer eigenen Implementierung festzuhalten. Dieser Blog ist nicht der Ort, um zu entscheiden, welche Implementierung besser ist, aber als Ergebnis müssen wir zwei verschiedene, inkompatible GTID-Systeme verwalten – es erhöht die Belastung für jedes Tool, das die Replikation verwaltet, und verringert die Interoperabilität. Bleiben Sie bei der Replikation – Gruppen-Commit und parallele Replikation:Sowohl Oracle als auch MariaDB haben ihre eigene Implementierung, und wenn Sie mit beiden arbeiten, müssen Sie beide lernen, um die erforderliche Abstimmung anzuwenden – die Knöpfe sind unterschiedlich und funktionieren auf unterschiedliche Weise. Ähnlich verhält es sich mit der Unterstützung virtueller Spalten – zwei verschiedene, nicht 100 % kompatible Implementierungen, die es im Ergebnis nicht möglich machten, Daten einfach aus MariaDB zu sichern und in MySQL von Oracle zu laden (und umgekehrt), da die Syntax etwas anders ist. Sollten Sie sich also entscheiden, eine Version von MariaDB für eine brandneue Funktion zu verwenden, bleiben Sie möglicherweise damit hängen, selbst wenn Sie zurück zu MySQL migrieren möchten, um die Implementierung von Oracle zu verwenden. Im besten Fall würde die Migration viel mehr Aufwand erfordern. Natürlich, wenn Sie die ganze Zeit in der einen Umgebung bleiben, kann es Sie nicht ernsthaft beeinträchtigen. Aber selbst dann wird Ihnen ein Mangel an Kompatibilität auffallen, und sei es nur, wenn Sie Blogs im Internet lesen und Lösungen finden, die nicht wirklich auf Ihre MySQL-Geschmacksrichtung anwendbar sind.
Also, um es zusammenzufassen - wenn Sie daran interessiert sind, die Kompatibilität mit MySQL aufrechtzuerhalten, wäre Percona Server (oder natürlich MySQL selbst) wahrscheinlich der richtige Weg. Wenn Sie an Leistung interessiert sind, ist dies möglicherweise der richtige Weg, solange Percona Server auf dem neuesten MySQL aufbaut. Natürlich möchten Sie vielleicht MariaDB bewerten und sehen, ob Ihre Arbeitslast nicht von einigen Optimierungen profitieren kann, die immer noch einzigartig für MariaDB sind. In Bezug auf den Betrieb ist es wahrscheinlich gut, sich an eine der Umgebungen (Oracle/Percona oder MariaDB) zu halten, je nachdem, welche für Sie besser geeignet ist. MySQL oder Percona Server haben den Vorteil, dass sie häufiger verwendet werden und es etwas einfacher ist, sie mit externen Tools zu integrieren (da nicht alle Tools alle MariaDB-Funktionen unterstützen). Wenn Sie von einer neuen und glänzenden Funktion profitieren würden, die gerade in MariaDB implementiert wurde, sollten Sie dies in Betracht ziehen und dabei mögliche Kompatibilitätsprobleme und eine mögliche geringere Leistung berücksichtigen.
Wir hoffen, dass dieser Blogbeitrag Ihnen einige Ideen zu verschiedenen Möglichkeiten in der MySQL-Welt und zu verschiedenen Blickwinkeln gegeben hat, aus denen Sie sie vergleichen können. Am Ende des Tages wird es Ihre Aufgabe sein, zu entscheiden, was das Beste für Ihr Setup ist. Es ist vielleicht nicht einfach, aber wir sollten trotzdem dankbar sein, dass wir die Wahl haben und uns aussuchen können, was für uns am besten funktioniert.
