À l'époque où quelqu'un disait MySQL, il n'y avait que MySQL. Vous pouviez choisir différentes versions (4.0, 4.1) mais le fournisseur était le même. Cela a changé autour de MySQL 5.0/5.1 lorsque Percona a décidé de publier sa propre version de MySQL - Percona Server. Un peu plus tard, MariaDB a rejoint MariaDB 5.1 et le plaisir (ou la confusion) a augmenté. Quelle version dois-je utiliser ? Quelle est la différence entre MySQL 5.1, Percona Server 5.1 et MariaDB 5.1 ? Laquelle est la plus rapide ? Laquelle est la plus stable ? Lequel a des fonctionnalités supérieures ? Avec le temps, cela s'est aggravé à mesure que de plus en plus de changements étaient introduits dans chacune des saveurs. Ce billet de blog sera notre tentative de résumer les principales caractéristiques qui les différencient. Nous essaierons également de vous donner quelques suggestions sur la saveur qui pourrait être la meilleure pour un type de projet donné. Commençons.
Oracle MySQL
C'était le MySQL, maintenant c'est l'amont. La plupart du développement commence ici, chaque version à partir de la 5.6 résout certains conflits internes et apporte de meilleures performances. De nouvelles fonctionnalités sont également ajoutées régulièrement. MySQL 5.6 nous a apporté (entre autres) GTID et une première implémentation de la réplication parallèle. Cela nous a également permis d'exécuter la plupart des ALTER en ligne. Jetons un coup d'œil aux fonctionnalités de la dernière version de MySQL - MySQL 5.7
Fonctionnalités de MySQL 5.7
L'un des changements majeurs concerne les changements dans le processus de déploiement - au lieu de différents scripts, vous pouvez simplement exécuter mysqld --initialize pour configurer MySQL à partir de zéro. Un autre changement très important - la réplication parallèle basée sur l'horloge logique. Enfin, nous pouvons utiliser la réplication parallèle dans tous les cas, que vous utilisiez plusieurs schémas ou non. Une autre amélioration de la réplication est la réplication multi-source - un esclave 5.7 peut avoir plusieurs maîtres - c'est une fonctionnalité intéressante si vous souhaitez créer un esclave d'agrégation et, disons, combiner des données provenant de plusieurs clusters distincts.
InnoDB a commencé à prendre en charge les types spatiaux, le pool de mémoire tampon InnoDB peut enfin être redimensionné au moment de l'exécution, les ALTER en ligne ont été améliorés pour prendre en charge davantage de cas comme le partitionnement et les ALTER sans opération.
MySQL a commencé à prendre en charge les types de données JSON de manière native, ainsi que plusieurs nouvelles fonctions axées sur l'ajout de fonctionnalités autour de JSON. La sécurité de vos données est très importante de nos jours, MySQL 5.7 prend en charge le chiffrement des données au repos pour les tablespaces fichier par table. Certaines améliorations ont également été ajoutées au support SSL (SSL sera configuré si les clés sont en place, un script est inclus qui peut être utilisé pour créer des certificats). Du point de vue de la gestion des utilisateurs, la configuration de la durée de vie du mot de passe a été ajoutée, ce qui devrait faciliter un peu la conception des politiques d'expiration des mots de passe.
Une autre fonctionnalité destinée à aider les administrateurs de bases de données est le schéma « sys », un ensemble de vues conçues pour faciliter l'utilisation du schéma de performances. Il a été inclus par défaut dans MySQL 5.7.
Enfin, MySQL Group Replication (et éventuellement MySQL InnoDB Cluster) a été ajouté à MySQL 5.7. Il fonctionne comme un plugin et est inclus dans les versions récentes de la branche 5.7, mais c'est un sujet à part entière. En bref, la réplication de groupe vous permet de construire un cluster "virtuellement" synchrone.
Ce n'est certainement pas une liste complète des fonctionnalités - si vous êtes intéressé par chacune d'entre elles, vous pouvez consulter la documentation de MySQL 5.7.
Serveur Percona
Au début, il y avait un ensemble de correctifs à appliquer au code source de MySQL qui ajoutait quelques améliorations de performances et de fonctionnalités. À un moment donné, Percona a décidé de publier sa propre version de MySQL qui incluait ces correctifs. Avec le temps, plus de ressources de développement sont devenues disponibles, donc de plus en plus de fonctionnalités ont été ajoutées.
En général, vous pouvez voir Percona Server comme la dernière version de MySQL avec plusieurs correctifs/améliorations. Avec le temps, certaines des améliorations des fonctionnalités de Percona Server sont remplacées par des fonctionnalités en amont - chaque fois qu'Oracle développe une fonctionnalité qui remplace l'une des fonctionnalités ajoutées à Percona Server. Tant que l'implémentation est à la hauteur, Percona supprime son propre code au profit du code de l'amont. Cela fait de Percona Server un remplacement direct pour MySQL d'Oracle. L'un des domaines dans lesquels des améliorations de performances majeures ont été apportées est InnoDB. Il a été suffisamment modifié pour le marquer comme XtraDB. Actuellement, il est entièrement compatible avec InnoDB, mais cela n'a pas toujours été le cas. Par exemple, certaines fonctionnalités de Percona Server 5.5 n'étaient pas compatibles avec MySQL 5.5. C'est également vrai pour les versions plus récentes de Percona Server. Ce qui est important, c'est que, par défaut, Percona Server est livré avec toutes les fonctionnalités incompatibles désactivées - il est facile de le tester et de revenir à MySQL d'Oracle si nécessaire. Compte tenu de tout ce qui précède, vous devez toujours faire preuve de prudence lorsque vous envisagez de migrer de Percona Server vers MySQL :quelqu'un a peut-être activé l'une des fonctionnalités incompatibles.
Ce qui mérite d'être souligné, c'est que Percona s'efforce de réimplémenter les fonctionnalités d'entreprise de l'amont. Dans le cas de MySQL, des exemples sont l'implémentation d'un pool de threads ou d'un plugin d'authentification PAM. Jetons un coup d'œil à certaines des fonctionnalités du serveur Percona.
Fonctionnalités de Percona Server 5.7
L'une des principales caractéristiques de XtraDB est l'amélioration de l'évolutivité du pool de mémoire tampon - même s'il y a de moins en moins de conflits en raison du travail effectué par Oracle sur chaque version de MySQL, l'équipe d'ingénierie de Percona s'efforce de pousser les performances encore plus loin et de supprimer les mutex supplémentaires qui peuvent limiter les performances. De plus, plus de données sont écrites dans le moniteur InnoDB (accessible via SHOW ENGINE INNODB STATUS) concernant les conflits au sein d'InnoDB - par exemple, une section sur les sémaphores a été ajoutée.
Une autre série d'améliorations a été apportée dans le domaine des E/S. Dans InnoDB, vous pouvez définir une méthode de vidage uniquement pour les espaces de table InnoDB, ce qui entraîne une double mise en mémoire tampon pour les journaux redo InnoDB. XtraDB permet d'utiliser également O_DIRECT pour ces fichiers. Il ajoute également plus de données concernant les points de contrôle à la sortie de SHOW ENGINE INNODB STATUS. De plus, un tampon à double écriture parallèle et un vidage LRU multithread ont été implémentés pour réduire les conflits dans les opérations d'E/S au sein d'InnoDB.
Le pool de threads est une autre fonctionnalité mise à disposition par Percona Server. Dans Oracle MySQL, il n'est disponible que dans l'édition Enterprise. Ici, vous pouvez utiliser gratuitement l'implémentation de Percona. En général, le pool de threads réduit les conflits tout en servant un nombre élevé de connexions à partir de l'application en réutilisant les connexions existantes à la base de données.
Deux autres fonctionnalités remplacent directement les fonctionnalités de la version Enterprise de MySQL. L'un d'eux est le plugin d'authentification PAM qui a été développé par Percona et est conçu pour permettre l'utilisation de nombreuses options d'authentification différentes comme LDAP, RSA SecurID ou toute autre méthode prise en charge par PAM. La deuxième fonctionnalité est également liée à la sécurité - plug-in de journal d'audit. Il créera un fichier avec un enregistrement des actions prises sur le serveur de base de données.
De temps en temps, Percona introduit des améliorations significatives sur d'autres moteurs de stockage, comme les modifications qu'ils ont apportées au moteur MEMORY, qui permettaient d'utiliser le type de données VARCHAR ou BLOB.
L'introduction de verrous de sauvegarde était également une amélioration assez significative. Dans Oracle et MariaDB, la seule méthode de verrouillage de la table pour obtenir une sauvegarde cohérente consistait à utiliser FLUSH TABLES WITH READ LOCK (FTWRL). C'est assez lourd et cela oblige MySQL à fermer toutes les tables ouvertes. Les verrous de sauvegarde, en revanche, utilisent une approche plus légère des verrous de métadonnées. Dans de nombreux cas, un serveur lourdement chargé exécutant FTWRL prend trop de temps (et verrouille le serveur trop longtemps) pour être considéré comme faisable, tandis que les verrous de sauvegarde permettent d'effectuer une sauvegarde à l'aide de mysqldump ou xtrabackup.
Percona est également ouvert au portage des fonctionnalités d'autres fournisseurs. Un tel exemple est le port de START TRANSACTION WITH CONSISTENT SNAPSHOTS de MariaDB. Cette fonctionnalité est également liée aux sauvegardes - avec son aide, vous pouvez effectuer une sauvegarde logique cohérente (en utilisant mysqldump) sans exécuter FLUSH TABLE WITH READ LOCK.
Enfin, trois fonctionnalités qui améliorent l'observabilité - premièrement :les statistiques d'utilisation. Il s'agit d'une fonctionnalité assez légère qui collecte des données sur les utilisateurs, les index, les tables et les threads. Il permet de retrouver les index inutilisés ou de déterminer quel utilisateur est responsable de la charge sur le serveur. Actuellement, il est partiellement redondant avec performance_schema mais il est un peu plus léger et il a été créé à l'époque de MySQL 5.0 - 5.1, où personne ne rêvait même du performance_schema.
Deuxième - journal des requêtes lentes amélioré. Encore une fois, il a été ajouté à des moments où la granularité la plus élevée de long_query_time était de 1 seconde. Avec cet ajout, vous disposiez d'une granularité à la microseconde et d'un tas de données supplémentaires sur les statistiques InnoDB par requête ou sur ses caractéristiques de performances globales. A-t-il créé une table temporaire ? A-t-il utilisé un index ? A-t-il été mis en cache dans le cache des requêtes MySQL ?
Troisième fonctionnalité que nous avons mentionnée plusieurs fois ci-dessus - Percona Server expose beaucoup plus de données dans SHOW ENGINE INNODB STATUS qu'en amont. Cela aide certainement à mieux comprendre la charge de travail et à détecter davantage de problèmes avant qu'ils ne surviennent.
Bien sûr, ce n'est pas une liste complète - si vous êtes intéressé par plus de détails, vous pouvez consulter la documentation de Percona Server.
MariaDB
MariaDB a commencé comme un fork de MySQL mais, avec une partie de l'équipe de développement MySQL originale qui a rejoint MariaDB, elle s'est rapidement concentrée sur l'ajout de fonctionnalités. Dans MariaDB 5.3, de nombreuses fonctionnalités ont été ajoutées à l'optimiseur :Batch Key Access, MultiRange Read, Index Condition Pushdown pour n'en nommer que quelques-unes. Cela a permis à MariaDB d'exceller dans certaines charges de travail où MySQL ou Percona Server auraient du mal. Jusqu'à présent, certaines de ces fonctionnalités ont été ajoutées à MySQL (principalement dans MySQL 5.6), mais certaines sont toujours propres à MariaDB.
Une autre fonctionnalité importante introduite par MariaDB était l'ID de transaction global. Peu de temps après, Oracle a publié sa propre implémentation, mais MariaDB a été le premier à l'avoir. Une histoire similaire concerne une autre fonctionnalité de réplication - la réplication multisource :MariaDB l'avait avant Oracle. Désormais, MariaDB 10.2, récemment publié, contient également des fonctionnalités qui seront disponibles dans MySQL 8.0, qui est toujours en cours de développement. Nous parlons, par exemple, d'expressions de table communes récursives ou de fonctions de fenêtre.
Fonctionnalités de MariaDB 10.2
Comme nous l'avons mentionné, MariaDB 10.2 introduit des fonctions de fenêtre et des expressions de table communes récursives - des améliorations dans SQL qui devraient aider les développeurs à écrire des requêtes SQL plus efficaces.
Le changement très important est que MariaDB 10.2 utilise InnoDB. Jusqu'à 10.1, XtraDB a été utilisé comme stockage par défaut. Ceci, malheureusement, rend les fonctionnalités ajoutées dans le dernier XtraDB indisponibles pour les utilisateurs de MariaDB 10.2.
Des améliorations ont été apportées aux colonnes virtuelles - d'autres limitations ont été levées dans la version 10.2.
Enfin, la prise en charge de plusieurs déclencheurs pour le même événement a été ajoutée - vous pouvez désormais créer plusieurs déclencheurs, par exemple, ON UPDATE sur la même table.
Les développeurs devraient bénéficier du support JSON, ainsi que de quelques fonctions qui y sont liées. Ils devraient également aimer les nouvelles fonctions qui leur permettent d'exporter des données spatiales au format GeoJSON. En parlant de JSON, des améliorations ont été apportées à la sortie EXPLAIN FORMAT=JSON - plus de données sont affichées.
Sur le plan de la sécurité, la prise en charge d'OpenSSL 1.1 et de LibreSSL a été ajoutée.
Bien sûr, cette liste n'est pas complète et si vous êtes intéressé par ce qui a été ajouté à MySQL 10.2, vous pouvez consulter la documentation.
En plus des nouvelles fonctionnalités, MariaDB 10.2 bénéficie des fonctionnalités implémentées dans les versions précédentes. Nous passerons en revue les plus importants.
Les fonctionnalités les plus importantes de MariaDB 10.1
Tout d'abord, MariaDB depuis 10.1 est fourni avec le cluster Galera - pas besoin d'installer des bibliothèques supplémentaires, tout est prêt à l'emploi.
MariaDB 10.1 a apporté la mise en œuvre du chiffrement des données au repos. Par rapport à la fonctionnalité implémentée dans MySQL d'Oracle, MariaDB l'a plus étendue. Non seulement il crypte les espaces de table, mais il crypte également les journaux redo, les fichiers temporaires et les journaux binaires. Cela vient avec quelques problèmes - les outils CLI comme mysqldump ou xtrabackup ne peuvent pas accéder aux journaux binaires et peuvent avoir des problèmes pour sauvegarder les instances chiffrées (ceci est particulièrement vrai pour xtrabackup - tout récemment MariaDB a créé une fourche xtrabackup appelée MariaDB Backup qui prend en charge les données au repos chiffrement).
Ok, alors quelle saveur dois-je utiliser ?
Comme d'habitude, la bonne réponse serait :"Ça dépend" :-) . Nous partagerons quelques-unes de nos observations qui peuvent ou non vous aider à prendre une décision, mais, à la fin, c'est à vous d'effectuer des tests de performance et de trouver l'option qui fonctionnera le mieux pour votre environnement et votre application.
Tout d'abord, parlons du débit. Oracle publie une nouvelle version - disons MySQL 5.7. En termes de performances, à ce moment-là, il s'agit de la version MySQL la plus rapide du marché. En effet, seul Oracle dispose de suffisamment de ressources pour travailler à l'amélioration d'InnoDB dans cette mesure. En quelques mois (dans le cas de 5.7, c'était 4 mois), Percona publie Percona Server 5.7 avec son ensemble d'améliorations - selon le type de charge de travail, il peut offrir des performances encore meilleures que l'amont. Enfin, MariaDB adopte une nouvelle version amont et construit sa nouvelle version par-dessus.
Voici à quoi cela ressemblait dans un calendrier (nous parlons toujours de MySQL 5.7).
MySQL 5.7 GA :21 octobre 2015
Percona Server 5.7 GA :23 février 2016
MariaDB 10.2 GA :23 mai 2017
Veuillez noter combien de temps il a fallu à MariaDB pour publier une version basée sur MySQL 5.7 - toutes les versions précédentes étaient basées sur MySQL 5.6 et, évidemment, offraient des performances inférieures à MySQL 5.7. D'autre part, MariaDB 10.2 a été publié avec InnoDB remplaçant XtraDB. S'il est vrai qu'Oracle a en grande partie comblé l'écart de performances entre MySQL et Percona Server, c'est encore "en grande partie". En conséquence, MariaDB 10.2 peut offrir des performances inférieures à celles de Percona Server dans certains cas (et meilleures dans d'autres cas - en raison du travail d'optimisation effectué dans MariaDB 5.3, dont certaines n'ont pas encore été recréées dans MySQL).
Au niveau des fonctionnalités, c'est plus complexe. MariaDB a ajouté de nombreuses fonctionnalités, donc si vous êtes intéressé par certaines d'entre elles, vous pouvez certainement envisager d'utiliser MariaDB. Il y a aussi un inconvénient. Percona Server possédait de nombreuses fonctionnalités le différenciant de MySQL en amont, mais lorsque Oracle a commencé à les implémenter dans MySQL, Percona a décidé de déprécier leurs implémentations au profit de l'utilisation de l'implémentation en amont. Cela a réduit la quantité de code qui diffère entre MySQL et Percona Server, facilite la maintenance du code de Percona Server et, ce qui est le plus important, rend Percona Server 100 % compatible avec MySQL.
Ce n'est malheureusement pas vrai pour MariaDB. MariaDB a introduit GTID en premier, c'est vrai, mais après qu'Oracle ait développé sa version de GTID, MariaDB a décidé de s'en tenir à sa propre implémentation. Ce blog n'est pas l'endroit pour décider quelle implémentation est la meilleure, mais par conséquent, nous devons gérer deux systèmes GTID différents et incompatibles - cela alourdit la charge de tout outil qui gère la réplication et réduit l'interopérabilité. S'en tenir à la réplication - validation de groupe et réplication parallèle :Oracle et MariaDB ont leur propre implémentation et si vous travaillez avec les deux, vous devez les apprendre tous les deux pour appliquer le réglage requis - les boutons sont différents et fonctionnent différemment. Un cas similaire est avec la prise en charge des colonnes virtuelles - deux implémentations différentes, non compatibles à 100%, ce qui, par conséquent, n'a pas permis de vider facilement les données de MariaDB et de les charger dans MySQL d'Oracle (et vice versa) car la syntaxe est légèrement différente. Ainsi, si vous décidez d'utiliser une version de MariaDB pour une toute nouvelle fonctionnalité, vous risquez de vous retrouver bloqué même si vous souhaitez migrer vers MySQL pour utiliser l'implémentation d'Oracle. Au mieux, la migration nécessiterait beaucoup plus d'efforts pour s'exécuter. Bien sûr, si vous restez tout le temps dans le même environnement, cela ne vous affectera peut-être pas gravement. Mais même dans ce cas, un manque de compatibilité sera perceptible pour vous, ne serait-ce que lorsque vous lisez des blogs sur Internet et que vous trouvez des solutions qui ne sont pas vraiment applicables à votre version de MySQL.
Donc, pour résumer, si vous souhaitez maintenir la compatibilité avec MySQL, Percona Server (ou MySQL lui-même, bien sûr) serait probablement la solution. Si vous êtes intéressé par les performances, tant que Percona Server est construit sur le dernier MySQL, cela peut être la voie à suivre. Bien sûr, vous voudrez peut-être comparer MariaDB et voir si votre charge de travail ne peut pas bénéficier de certaines des optimisations qui sont encore uniques à MariaDB. Sur le plan opérationnel, il est probablement bon de s'en tenir à l'un des environnements (Oracle/Percona ou MariaDB), celui qui vous convient le mieux. MySQL ou Percona Server ont l'avantage d'être plus couramment utilisés et il est légèrement plus facile de les intégrer à des outils externes (car tous les outils ne prennent pas en charge toutes les fonctionnalités de MariaDB). Si vous souhaitez bénéficier d'une nouvelle fonctionnalité brillante qui vient d'être implémentée dans MariaDB, vous devriez l'envisager, en gardant à l'esprit tout problème de compatibilité potentiel et une éventuelle baisse des performances.
Nous espérons que cet article de blog vous a donné quelques idées sur les différents choix que nous avons dans le monde MySQL et sur les différents angles sous lesquels vous pouvez les comparer. En fin de compte, il vous appartiendra de décider ce qui convient le mieux à votre configuration. Ce n'est peut-être pas facile, mais nous devrions quand même être reconnaissants d'avoir le choix et de pouvoir choisir ce qui nous convient le mieux.
