Table des matières de l'article :
S'il y a une chose qui m'est restée à l'esprit dans la mise en scène que j'ai faite en cinquième année (il y a 23 ans) à Elettromeccanica Cognigni à Civitanova Marche, ce sont ces quelques mots significatifs "Les bons outils font déjà la moitié du travail" .
Cette phrase a été prononcée par le grand-père d'un de mes amis chers, qui avait l'habitude de venir rendre visite au propriétaire de l'entreprise et de parcourir ou de parler de ceci ou de cela, comme le font habituellement les personnes âgées qui ont le temps pendant la journée de cultiver leurs amitiés. et faire des visites ici et là.
J'étais en train de vider une armature d'un moteur électrique (un enroulement électrique) en battant le ciseau avec une pince remédiée, lorsque j'ai entendu ces mots retentissants et que j'ai ensuite été invité à utiliser un marteau.
Travail plus précis, plus rapide et plus confortable. Dans quelques semaines, le stage scolaire serait terminé et j'aurais terminé cette expérience au contact d'accumulateurs, de bobinages, de moteurs électriques, etc. précieux conseils et cette sentence solennelle prononcée à son effet est encore aujourd'hui l'une des pierres angulaires de mon métier, et plus largement de mon mode de vie.
On pourrait manger la soupe avec une fourchette, mais une cuillère c'est sûrement mieux.
Le problème avec les applications utilisant MySQL
Il y a un problème qui affecte presque tout le monde, impliquant principalement toutes les situations dans lesquelles vous devez faire face à des logiciels écrits par d'autres qui utilisent une base de données MySQL ou des forks connexes tels que MariaDB, Percona Server, qui sont en tout cas basés et dérivés de MySQL lui-même.
Lorsque nous travaillons avec des CMS tels que WordPress, WooCommerce, Magento, Prestashop et autres, nous finissons toujours par avoir affaire à un SGBDR tel que MySQL ou un dérivé, et il semble qu'il soit normal, juste et approprié d'avoir un SGBDR qui semble aussi extrêmement rapide et performant.
Le problème n'est pas un gros problème lorsque la base de données ne devient pas le goulot d'étranglement de notre application, et des performances qui affectent inévitablement l'expérience utilisateur, le référencement, le chiffre d'affaires et le profit de l'entreprise.
Bien qu'il ait pu améliorer considérablement la vitesse et les performances de MySQL au fil des ans, par exemple en passant de l'ancien moteur MyISAM vers InnoDB vous devez toujours vous demander si MySQL (ou les fourches associées) est la meilleure solution du marché en termes de fonctionnalités, de performances et de vitesse.
MySQL est extrêmement lent par rapport à PostgreSQL
Par exemple, si nous recherchions un SGBDR compatible avec SQL Standard qui soit open source, gratuit, bien supporté et documenté, multi-architecture, portable, extrêmement performant, nous exclurons sûrement les solutions commerciales et propriétaires à source fermée telles que Oracle DB, SQL Server ou DB2 d'IBM.
Cependant, nous pourrions et devrions envisager PostgreSQL ou simplement Postgres.
PostgreSQL est un puissant système de base de données relationnelle objet open source avec plus de 35 ans de développement actif qui lui a valu une solide réputation de fiabilité, de robustesse des fonctionnalités et de performances.
Aussi connu sous le nom Postgres , est un système de gestion de base de données relationnelle (RDBMS) libre et open source qui met l'accent sur l'extensibilité et la conformité SQL. Il s'appelait à l'origine POSTGRES, faisant référence à ses origines en tant que successeur de la base de données Ingres développée à l'Université de Californie à Berkeley. En 1996, le projet a été renommé PostgreSQL pour refléter sa prise en charge de SQL . Après une révision en 2007, l'équipe de développement a décidé de conserver le nom PostgreSQL et l'alias Postgres.
PostgreSQL présente transactions avec Propriétés d'atomicité, de consistance, d'isolement, de durabilité (ACID), vues actualisables automatiquement, viste matérialisés , déclencheurs , clés étrangères et procédures stockées . Il est conçu pour gérer une grande variété de charges de travail, des machines uniques aux entrepôts de données ou aux services Web avec de nombreux utilisateurs simultanés. Il s'agit de la base de données par défaut pour macOS Server et est également disponible pour Windows, Linux, FreeBSD et OpenBSD.
Mais à quel point MySQL est-il lent par rapport à PostgreSQL ?
Ou plutôt, à quel point PostgreSQL est-il plus rapide que MySQL ?
Comment ai-je comparé les bases de données ?
L'analyse comparative d'une base de données peut être une tâche délicate. Il suffit de regarder sur Internet. Il existe différents points de repère, qui mesurent différentes choses, parfois des métriques, qui ne vous disent rien de significatif.
De mon point de vue, je vois la base de données comme quelque chose qui correspond exactement à son nom. UNE base pour un filet . Rien de plus. Donc pas de logique d'application dans la base de données. La base de données doit contenir les données et effectuer deux opérations principales le plus rapidement possible : lire e écrire .
Je vois lire comme quelque chose qui ne change pas la base de données et écrire comme quelque chose qui change la base de données. Pour moi, supprimer et mettre à jour sont deux sous-ensembles de l'écriture.
De plus, lors de la lecture de la base de données, j'ai tendance à rendre mon propre selectsle plus simple possible. Je n'utilise pas la jointure sur la jointure sur la jointure sur la jointure. Je préfère lire plusieurs tables différentes aussi vite que possible, puis traiter les données en dehors de la base de données. Mais j'utilise max, avge mintrès sum. J'utilise beaucoup les choses simples et le moins possible les choses compliquées.
À mon avis, ma base de données idéale devrait bourdonner tranquillement tout le temps, servir les lectures et les écritures aussi rapidement que possible. Rien de plus.
Lorsque j'ai décidé de faire mon point de référence, je cherchais trois choses :
- Quelle base de données a les écritures les plus rapides
- Quelle base de données a les lectures les plus rapides
- Quelle base de données a le moins de mémoire et d'utilisation du processeur
Préparation
Comme j'ai fait mon benchmark il y a deux ans en 2019 (qui a conduit au passage à PostgreSQL), il sera judicieux de le répéter maintenant, en 2021.
Au début, nous devons exécuter toutes les bases de données, nous voulons les comparer. Nous pouvons exécuter toutes les principales bases de données dans Docker avec les commandes (et un peu plus d'informations) de cet article, mais retrouvez toutes ces commandes ci-dessous.
J'ai ajouté quelques fourches populaires des trois majors familles de moteurs.
Famille de moteurs Postgres : PostgreSQL, TimescaleDB
Famille de moteurs MySQL : MySQL, MariaDB, Percona
Famille de moteurs Microsoft SQL Server : SQL Server
Voici les commandes Docker pour exécuter toutes les bases de données que nous devons tester.
PostgreSQL
docker run --name postgres -e POSTGRES_PASSWORD=mot de passe -p 5433:5432 -v postgres_data:/var/lib/postgresql/data -d postgres:alpine BD d'échelle de temps
docker run --name timescale -e POSTGRES_PASSWORD=mot de passe -p 5434:5432 -v timescale_data:/var/lib/postgresql/data -d timescale/timescaledb:latest-pg12 MySQL
docker run --name mysql -e MYSQL_ROOT_PASSWORD=mot de passe -p 3306:3306 -v mysql_data:/var/lib/mysql -d mysql:latest MariaDB
docker run --name mariadb -e MYSQL_ROOT_PASSWORD=mot de passe -p 3307:3306 -v mariadb_data:/var/lib/mysql -d mariadb:latest Serveur Percona
docker run --name percona -e MYSQL_ROOT_PASSWORD=mot de passe -p 3308:3306 -v percona_data:/var/lib/mysql -d percona:ps-8 Malheureusement, grâce au CLUF de Microsoft pour SQL Server 2019, il n'est pas possible de présenter des benchmarks pour SQL Server, mais je peux vous dire que c'est dommage. Vous devez faire vos propres repères.
Première comparaison
À ce stade, vous devriez avoir les six bases de données en cours d'exécution. Tous les six dans leurs états par défaut. Aucune configuration.
Nous pouvons faire notre première comparaison. Nous pouvons comparer la taille de l'image de la base de données, l'utilisation initiale de la mémoire dans Docker et l'utilisation initiale du processeur.
D'après ces résultats, il apparaît que PostgreSQL est le gagnant et SQL Server le perdant. Mais nous n'avons pas encore fait de tests de lecture et/ou d'écriture.
Rédaction de repères.
Pour écrire des benchmarks, j'ai développé un programme Go simple (dépôt github en fin d'article). Ce programme crée une table appelée benchmark_dataavec 6 colonnes. Vous devez créer la base de données benchmarkmanuellement à l'aide create database benchmark.
Ce programme insère 10.000 XNUMX lignes dans cette table, une par une. Pas d'insertions par lot, juste des insertions simples.
Le benchmark sera exécuté sur Macbook Pro 2019, avec le bureau Docker en cours d'exécution, toutes les applications inutiles sont fermées.
Cette première partie du benchmark mesurera le temps nécessaire à la réalisation de ces inserts. De mon point de vue, le temps consacré à une opération est la seule mesure raisonnable qui puisse être prise. En fin de compte, vous voulez toujours savoir Combien de temps cela prend-il o ce qui a été fait dans un temps déterminé.
Dans ce benchmark, j'ai exécuté 5 lots d'insertion consécutifs, chacun de 10.000 XNUMX lignes. De toute évidence, PostgreSQL est le gagnant et Percona est le perdant.
PostgreSQL est environ deux fois plus rapide que Percona, en ce qui concerne les insertions. Ce qui me frappe ici, c'est la différence entre MariaDB et MySQL, car ils appartiennent tous les deux à même famille de moteur. Il semble que les personnes derrière MariaDB aient fait de la magie.
Un simple constat : la famille de moteurs Postgres est environ deux fois plus rapide dans la famille de moteurs MySQL, à l'exception de MariaDB.
Repères de lecture.
Ce benchmark de lecture a été fait comme ceci : 2 000 cycles avec deux lectures dans chaque cycle : averagee sumdi datacolonne. Encore une fois, je l'ai fait 5 fois.
Voici les résultats. PostgreSQL est le gagnant, Percona est le perdant. MariaDB est le deuxième pire.
La famille de moteurs Postgres est environ deux fois plus rapide que la famille de moteurs MySQL.
Pourquoi MySQL est-il plus utilisé et populaire que PostgreSQL ?
MySQL est l'un des systèmes de gestion de bases de données les plus populaires au monde, bien que ses performances ne soient pas comparables à d'autres bases de données telles que PostgreSQL. Il y a plusieurs raisons pour lesquelles MySQL est plus populaire que PostgreSQL, malgré les performances supérieures de ce dernier.
En premier lieu, MySQL a une histoire plus longue que PostgreSQL et a donc eu plus de temps pour se répandre et devenir populaire. MySQL est sorti pour la première fois en 1995, tandis que PostgreSQL est sorti en 1996. Cela signifie que MySQL avait un an de plus pour se répandre et se faire connaître des programmeurs et des professionnels de l'industrie.
De plus, MySQL est souvent inclus comme composant par défaut dans de nombreux systèmes d'exploitation et piles de développement, ce qui le rend facilement accessible à quiconque a besoin d'une base de données. De plus, MySQL dispose d'une documentation très complète et d'une forte présence en ligne, ce qui le rend facile à apprendre et à utiliser pour les programmeurs novices.
Enfin, MySQL est souvent choisi par les entreprises en raison de sa simplicité et de sa capacité à traiter de grandes quantités de données. MySQL ne nécessite pas de connaissances avancées en administration système et peut facilement gérer de grandes quantités de données, ce qui le rend idéal pour les entreprises qui ont besoin d'une base de données évolutive et facile à gérer.
Impact environnemental de PostgreSQL par rapport à MySQL.
L'utilisation de PostgreSQL au lieu de MySQL pourrait avoir un impact positif sur l'environnement. PostgreSQL est connu pour son efficacité et sa rapidité, ce qui signifie qu'il peut gérer de grandes quantités de données avec moins de consommation de ressources que MySQL. Cela peut entraîner une réduction des émissions de CO2, car les serveurs utiliseront moins d'énergie pour effectuer les mêmes tâches.
L'utilisation de PostgreSQL plutôt que MySQL pourrait signifier, par exemple, réduire le nombre de serveurs au sein d'une organisation, éviter l'utilisation de clusters MySQL pour compenser les problèmes de performances, ainsi qu'éviter un remplacement ou une mise à niveau du matériel à la fois pour la mise à l'échelle verticale (augmentation des ressources sur une seule machine), et pour la mise à l'échelle horizontale, c'est-à-dire l'augmentation des nœuds et des machines.
Conclusions.
Nous avons vu comment, sur la base des benchmarks mentionnés ci-dessus, PostgreSQL est décidément meilleur et plus recommandé pour une série d'avantages à la fois en termes de performances et de vitesse et dans l'utilisation plus efficace de la mémoire, sans avoir à renoncer à l'open source ou à un système de licence libre qui permet de l'adopter sans restriction sur les logiciels et applications libres.
On se demande donc pourquoi et pourquoi de nombreuses réalités, y compris les CMS les plus utilisés tels que WordPress, Prestashop, Magento, Joomla, ont décidé de continuer à utiliser un SGBD tel que MySQL et dérivés qui en fait n'a pas ce calibre et ces exigences telles que make il est agréable au goût par rapport à l'homologue PostgreSQL.
De nombreuses considérations concernant l'efficacité du logiciel ainsi que l'impact sur la consommation et sur l'environnement reviendraient si l'on considère ce raisonnement appliqué à grande échelle, permettant par exemple de réduire le nombre de nœuds dans un cluster ou d'éviter dans certains cas de mise à l'échelle horizontale ou verticale pour remédier à l'inefficacité de la base de données.
Cependant, à l'exception de quelques projets sporadiques plutôt immatures à utiliser en production avec les garanties nécessaires, il ne semble toujours pas y avoir d'avenir pour que PostgreSQL soit utilisé comme backend pour les CMS les plus populaires mentionnés ci-dessus.
Vraiment dommage quand on sait que le degré de maturité de PostgreSQL est si élevé qu'il n'a pratiquement pas de rival (sauf peut-être Oracle DB).
