--- title: Bases de données source: https://synapx.fr/blog/bases-de-donnees/ date: 2026-06-26 category: Bases de données site: SynapxLab --- # Bases de données MariaDB est un système de gestion de bases de données relationnelles (SGBDR). Il s'agit d'un fork de MySQL, c'est-à-dire d'une solution développée à partir de son code source. - Moteurs de stockage : Aria, ColumnStore, MyRocks, InnoDB, MyISAM. - Entièrement distribué sous licence GPL, garantissant que toutes les versions sont open source et libres d'utilisation. PostgreSQL est un autre système de gestion de bases de données relationnelles (SGBDR) open source, reconnu pour sa robustesse et sa richesse fonctionnelle. ## Comparatif en un coup d'œil | Critère | MySQL | MariaDB | PostgreSQL | | --- | --- | --- | --- | | Licence | GPL v2 + offre commerciale (Oracle) | GPL v2, entièrement libre | PostgreSQL License (permissive) | | Moteurs de stockage | InnoDB, MyISAM, Memory | InnoDB, Aria, MyRocks, ColumnStore, MyISAM | Moteur unique intégré | | Transactions (ACID) | Oui (InnoDB) | Oui (InnoDB) | Oui (natif, MVCC) | | Types d'index | B-tree, Hash, Fulltext, spatial | B-tree, Hash, Fulltext, spatial | B-tree, Hash, GIN, GiST, SP-GiST, BRIN | | JSON | Type `JSON` | `JSON` | `JSON` et `JSONB` indexable | | Réplication | Asynchrone, Group Replication | Asynchrone, Galera (multi-maître) | Streaming (physique), logique | | Cas d'usage typique | Web, LAMP, WordPress | Remplacement direct de MySQL, souveraineté | Données complexes, analytique, géospatial | ## Indexation - MySQL et MariaDB : support B-tree, Hash et autres types d'index. - PostgreSQL : prend en charge les index B-tree, Hash, GIN (Generalized Inverted Index), GiST (Generalized Search Tree), SP-GiST et BRIN (Block Range Indexes), avec une grande souplesse pour les cas d'utilisation complexes. ## Cas d'utilisation - MySQL et MariaDB : applications web courantes, CMS comme WordPress, stack LAMP (Linux, Apache, MySQL, PHP/Perl/Python). - PostgreSQL : applications nécessitant des fonctionnalités avancées, des transactions complexes et une conformité stricte aux standards SQL. ## Transactions et propriétés ACID Une transaction regroupe plusieurs opérations dans une même unité de travail : soit elles sont toutes appliquées, soit aucune ne l'est. Elle débute généralement avec `BEGIN`, se termine par `COMMIT` pour valider les changements, ou par `ROLLBACK` pour les annuler en cas d'erreur. Ce mécanisme repose sur les propriétés ACID : l'**atomicité** garantit le tout-ou-rien ; la **cohérence** maintient la base dans un état valide ; l'**isolation** évite que des transactions concurrentes n'interfèrent ; la **durabilité** assure qu'une donnée validée résiste à une panne. ```sql BEGIN; UPDATE comptes SET solde = solde - 50 WHERE id = 1; UPDATE comptes SET solde = solde + 50 WHERE id = 2; COMMIT; ``` Avec MySQL ou MariaDB, ces garanties nécessitent le moteur transactionnel InnoDB. L'ancien moteur MyISAM ne prend en charge ni les transactions ni les clés étrangères. PostgreSQL est nativement transactionnel et s'appuie sur le MVCC, ou contrôle de concurrence multiversion : les lectures peuvent ainsi se poursuivre sans bloquer les écritures concurrentes. ## Limites théoriques de MySQL Taille maximale limitée par le système de fichiers ; les systèmes courants comme ext4 ont une limite de taille de fichier de 16 To. - Taille maximale d'une table : 64 To pour le moteur de stockage InnoDB. - Taille maximale d'un enregistrement : 64 Ko pour les lignes, mais des données plus volumineuses peuvent être stockées dans des colonnes BLOB ou TEXT. - Nombre maximal de colonnes par table : 1017 pour InnoDB. - Nombre maximal d'index par table : 64 pour InnoDB. ## Limites théoriques de PostgreSQL Taille maximale limitée par le système de fichiers et le matériel. - Taille maximale d'une table : 32 To. - Taille maximale d'un enregistrement : 1.6 To. - Nombre maximal de colonnes par table : 1600. ## Calcul d'enregistrements Estimation de la taille d'un enregistrement : pour chaque champ, on retient une taille moyenne. En MySQL, les types `VARCHAR` ajoutent 1 ou 2 octets pour stocker la longueur du champ ; dans l'exemple ci-dessous, 1 octet est retenu car les valeurs restent inférieures à 255 caractères. Les autres types de données ont des tailles fixes. ```text Nom : 50 caractères = 51 octets Prénom : 50 caractères = 51 octets Adresse : 100 caractères = 101 octets Code Postal : 10 caractères = 11 octets Ville : 50 caractères = 51 octets Date de Naissance = 3 octets (type DATE) Numéro de Téléphone : 15 = 16 octets Email : 50 caractères = 51 octets Taille d'un enregistrement = 51+51+101+11+51+3+16+51 = 335 octets Population de la France : environ 68 millions de personnes. ``` Pour calculer la taille totale nécessaire au stockage, il suffit de multiplier la taille d'un enregistrement par le nombre d'individus : ```text Taille totale = 335 octets/enregistrement × 68 000 000 enregistrements Taille totale = 22 780 000 000 octets ``` La taille nécessaire pour stocker les informations de l'ensemble de la population française, en supposant environ 335 octets par enregistrement, serait d'environ 21.2 Go. Cette estimation ne prend toutefois pas en compte l'espace supplémentaire requis pour les index, les surcharges de stockage et les autres métadonnées. Pour affiner l'évaluation : - Indexation : les index peuvent ajouter une surcharge significative. Avec une surcharge estimée à 50 %, cela ajouterait environ 10.6 Go. - Marge de sécurité : ajouter 10 % pour les métadonnées et les autres besoins de stockage. En arrondissant, il est raisonnable de prévoir **environ 34 Go de stockage** ; ce volume tient sur une clé USB achetée 15 €. Pour la population mondiale, il faut compter environ 3.9 To. ## Retour d'expérience : la base Habilo Après avoir estimé théoriquement qu'il faudrait environ 34 Go pour stocker toute la population française, nous avons voulu confronter cet ordre de grandeur à un cas concret. Chez SynapxLab, le projet Habilo est un moteur de recherche B2B construit à partir des données publiques SIRENE, le registre des entreprises françaises, puis enrichi d'un graphe de savoir-faire et de compétences. Sa base MariaDB illustre bien ce que représente une base de données nationale en conditions réelles. Habilo rassemble environ 73 millions d'entités SIRENE : 43,7 millions de lignes dans la table `etablissement` et 29,8 millions dans `unite_legale`. L'ensemble occupe environ 28,3 Go sur 129 tables, avec près de 13,1 Go de données et 15,1 Go d'index. Le détail est parlant : `etablissement` représente à elle seule environ 7,8 Go de données et 10,3 Go d'index ; `unite_legale` approche 8,3 Go au total. Les index pèsent donc davantage que les données elles-mêmes : c'est le prix assumé de la rapidité de recherche. L'estimation « à la main » n'était donc pas loin de la réalité : plusieurs dizaines de millions d'enregistrements administratifs tiennent bien dans quelques dizaines de gigaoctets. Mais le volume disque ne résume pas le sujet. À cette échelle, la qualité de l'indexation détermine directement l'expérience d'utilisation. | Requête | Temps | | --- | ---: | | Lookup d'un établissement par son SIRET, sur clé primaire indexée | ~0,3 milliseconde | | Jointure filtrée `etablissement` ⋈ `unite_legale` sur les établissements actifs d'un préfixe de SIREN | ~0,97 seconde | | `COUNT` des établissements actifs, soit 16,8 millions de lignes, via un index | ~17 secondes | | `COUNT(*)` sur les 43,7 millions de lignes, en balayage intégral sans index utilisable | ~56 secondes | La leçon est simple : un accès indexé reste sous la milliseconde, alors qu'un parcours complet du même ordre de volume approche la minute. En production, Habilo évite donc les full scans : les requêtes s'appuient sur les index, les comptages sont pré-agrégés et mis en cache lorsque c'est pertinent. Pour la recherche sémantique de savoir-faire, nous explorons aussi des approches au-delà du relationnel pur, notamment [la vectorisation des données](/blog/vectorisation-des-donnees/), MariaDB proposant désormais un type `VECTOR` natif. Pour naviguer dans les relations profondes du graphe de compétences, les bases orientées graphes comme Neo4j constituent également une piste complémentaire. ## SQL, NoSQL et les autres familles de bases de données MySQL, MariaDB et PostgreSQL appartiennent à la famille relationnelle, dite SQL. Elles organisent les données en tables reliées par des clés et appliquent un schéma strict. SQL permet d'exprimer des requêtes riches, tandis que les contraintes et les transactions ACID favorisent la cohérence des données. SQLite est également relationnelle, mais embarquée : toute la base tient dans un simple fichier, sans serveur à administrer. Le terme NoSQL recouvre plusieurs modèles. Les bases documentaires stockent des documents JSON ou BSON à schéma souple, comme MongoDB et CouchDB. Les magasins clé-valeur, tels que Redis et Memcached, sont très rapides et souvent utilisés en mémoire. Les bases à colonnes larges, comme Cassandra et HBase, visent de très gros volumes distribués. Enfin, les bases orientées graphes, par exemple Neo4j, représentent efficacement des relations complexes, notamment pour les réseaux sociaux ou les recommandations. | Famille | Modèle de données | Exemples | Usage typique | |---|---|---|---| | Relationnel | Tables et relations | MySQL, MariaDB, PostgreSQL, SQLite | Cohérence forte et requêtes riches | | Documents | Documents JSON/BSON | MongoDB, CouchDB | Schéma souple | | Clé-valeur | Paires clé-valeur | Redis, Memcached | Cache et accès très rapides | | Colonnes larges | Colonnes distribuées | Cassandra, HBase | Très gros volumes distribués | | Graphes | Nœuds et relations | Neo4j | Réseaux sociaux et recommandations | La ligne de partage est donc une question de priorités. Le relationnel privilégie le schéma strict et les garanties ACID. Le NoSQL privilégie la souplesse du schéma et la mise à l'échelle horizontale, parfois avec une cohérence à terme (*eventual consistency*). Pour une cohérence forte et des requêtes riches, le relationnel est souvent adapté ; pour un volume massif, un schéma mouvant ou un cache, une solution NoSQL peut convenir. Dans de nombreuses architectures, les deux approches sont combinées.