Bases de données

Là où un site est rapide ou lent : sa base de données.

Nous installons, optimisons, répliquons et sauvegardons la base de données de votre application, et nous prouvons les sauvegardes en les restaurant.

Demander un devis Voir les offres d'hébergement

Fonctionne sur et construit avec

MySQL
MariaDB
PostgreSQL
Redis
MongoDB
Elasticsearch

Sept moteurs, dessinés comme un seul schéma

Chaque boîte est une base de données que nous installons, optimisons et sauvegardons. Les lignes montrent comment elles travaillent ensemble dans les systèmes que nous exploitons - la plupart des applications en utilisent deux ou trois, pas une seule.

SQLiteembarquée

Usage: Applications et outils avec un seul fichier de données et un seul rédacteur à la fois
Nous réglons: journal_mode=WAL
Sauvegardes: Une copie à chaud du fichier, jamais la copie d'un fichier en cours d'utilisation

MySQLrelationnelle

Usage: Boutiques, WordPress et la plupart des applications PHP
Nous réglons: innodb_buffer_pool_size
Sauvegardes: Sauvegardes complètes et journaux binaires, jusqu'à n'importe quel instant

Pourquoi nous utilisons MySQL

Redisen mémoire

Usage: Cache, sessions, files d'attente et compteurs
Nous réglons: maxmemory-policy
Sauvegardes: Instantanés et fichier append-only

PostgreSQLrelationnelle

Usage: Comptabilité, ERP, rapports et requêtes complexes
Nous réglons: shared_buffers · work_mem
Sauvegardes: Sauvegardes de base et WAL archivé, jusqu'à n'importe quel instant

MariaDBrelationnelle

Usage: Les mêmes usages que MySQL, plus les clusters Galera
Nous réglons: innodb_buffer_pool_size
Sauvegardes: mariabackup et journaux binaires, jusqu'à n'importe quel instant

OpenSearch · Elasticsearchrecherche

Usage: Recherche dans les produits et les articles, filtres, journaux
Nous réglons: JVM heap · shards
Sauvegardes: Instantanés ; l'index peut être reconstruit depuis la base principale

MongoDBdocuments

Usage: Des enregistrements dont la forme change : événements, catalogues, contenus
Nous réglons: wiredTiger cacheSizeGB
Sauvegardes: Un replica set, avec l'oplog pour un instant précis

Quand une application dépasse un seul fichier, elle passe à un serveur de base de données.
MariaDB est né d'un fork de MySQL ; la plupart des applications passent de l'un à l'autre sans changement.
Redis se place devant : les réponses répétées et les sessions restent en mémoire.
Le même cache devant les applications PostgreSQL.
L'index de recherche est alimenté par la base principale, jamais l'inverse.
Le JSONB de PostgreSQL couvre bien des usages documentaires avant qu'il faille MongoDB.

Quelle base de données pour quel usage

C'est généralement l'application qui décide, et nous la suivons. Quand le choix est ouvert, voici comment nous choisissons.

L'usage	Notre premier choix	Convient aussi	Pourquoi
Une boutique, un site WordPress ou une application PHP	MySQL · MariaDB	PostgreSQL	Ce sur quoi l'application a été construite et testée, avec le support le plus large.
Comptabilité, ERP et rapports aux jointures lourdes	PostgreSQL	MySQL 8	Des transactions strictes, des fonctions de fenêtrage et un planificateur fait pour les requêtes complexes.
Cache, sessions, files d'attente et limitation de débit	Redis	Memcached	Des réponses depuis la mémoire. N'y gardez que ce qui peut être reconstruit en cas de perte.
Recherche dans les produits ou les articles	OpenSearch · Elasticsearch	MySQL · PostgreSQL full-text	Pertinence, fautes de frappe, filtres et facettes qu'une requête LIKE ne peut offrir. Pour un petit catalogue, la recherche plein texte de la base suffit.
Une application mobile, un outil de bureau ou un petit service interne	SQLite	—Aucune autre	Aucun serveur à faire tourner : un fichier, sauvegardé en le copiant de façon sûre.
Événements, journaux ou enregistrements dont la forme change	MongoDB	PostgreSQL JSONB	Des documents souples ; PostgreSQL quand il faut aussi des jointures et des transactions.
Des lectures qui dépassent un seul serveur	MySQL · MariaDB · PostgreSQL replicas	—Aucune autre	Les lectures réparties sur des répliques, les écritures sur un seul serveur principal.

Cinq moteurs côte à côte

Ce que chaque moteur fait lui-même, d'après sa propre documentation. Le mot à côté de chaque repère dit jusqu'où il va.

Comparaison de MySQL, MariaDB, PostgreSQL, Redis et MongoDB
Capacité	MySQL	MariaDB	PostgreSQL	Redis	MongoDB
Usage	Boutiques, WordPress et la plupart des applications PHP	Les mêmes usages que MySQL, plus les clusters Galera	Comptabilité, ERP, rapports et requêtes complexes	Cache, sessions, files d'attente et compteurs	Des enregistrements dont la forme change : événements, catalogues, contenus
Modèle de données	Tables et lignes, interrogées en SQL.	Tables et lignes, interrogées en SQL.	Tables et lignes, interrogées en SQL, avec un type JSONB pour les documents.	Des clés qui contiennent des chaînes, des hachages, des listes, des ensembles, des ensembles triés ou des flux.	Des documents de type JSON dans des collections, avec le langage de requête propre à MongoDB.
Transactions	Pris en charge InnoDB, le moteur par défaut : validation, annulation et reprise après incident.	Pris en charge InnoDB est aussi le moteur par défaut ici.	Pris en charge Chaque modification est une transaction qui est validée ou annulée.	En partie Un bloc de commandes s'exécute d'un trait, l'une après l'autre, mais il n'y a pas d'annulation.	Pris en charge Sur plusieurs documents, avec des jeux de réplicas et des clusters shardés.
Où vivent les données de travail	Sur disque ; InnoDB garde en mémoire un pool de tampons avec les données les plus sollicitées.	Sur disque ; InnoDB garde en mémoire un pool de tampons avec les données les plus sollicitées.	Sur disque ; les tampons partagés gardent en mémoire les données les plus sollicitées.	En mémoire ; des instantanés et un fichier en ajout seul l'écrivent sur disque.	Sur disque ; WiredTiger garde en mémoire un cache des données les plus sollicitées.
Réplication intégrée	Pris en charge De la source vers les réplicas, en asynchrone ou en semi-synchrone.	Pris en charge De la source vers les réplicas, plus Galera Cluster pour du multi-primaire synchrone.	Pris en charge Réplication en flux ; les réplicas en attente active peuvent répondre aux requêtes de lecture.	Pris en charge Du leader vers les réplicas, asynchrone par défaut ; les réplicas peuvent servir les lectures.	Pris en charge Jeux de réplicas : plusieurs serveurs qui détiennent les mêmes données, avec basculement automatique.
Répartir les données sur plusieurs serveurs	Complément NDB Cluster, un moteur à part qui partitionne les données automatiquement.	Complément Le moteur de stockage Spider, qui répartit les tables sur plusieurs serveurs MariaDB (sharding).	En partie Le partitionnement par plage, liste ou hachage découpe une table à l'intérieur d'un seul serveur.	Pris en charge Redis Cluster répartit les clés entre plusieurs nœuds.	Pris en charge Le sharding est intégré, par collection.
Restauration à un instant précis	Pris en charge à toute seconde couverte par le journal	Pris en charge à toute seconde couverte par le journal	Pris en charge à toute seconde couverte par le journal	En partie jusqu'à la dernière écriture du fichier append-only	Pris en charge à toute seconde couverte par le journal

Faites défiler sur le côté pour voir les cinq moteurs.

Pris en charge le moteur le fait lui-même
En partie avec une réserve
Complément un composant ou un moteur distinct

Les fonctions varient selon la version, et la documentation de la version que vous utilisez fait foi.

Sources : MySQL Reference Manual MariaDB Knowledge Base PostgreSQL Documentation Redis Documentation MongoDB Manual

Pourquoi nous utilisons MySQL

Cinq niveaux où une base de données gagne en vitesse

Une base lente se répare rarement en un seul endroit. Voici les niveaux, dans l'ordre où on les examine d'habitude : le changement le moins coûteux d'abord, le plus coûteux en dernier.

Les numéros indiquent l'ordre habituel du travail.

Requêtes
Le journal des requêtes lentes désigne les pires requêtes, et EXPLAIN montre pourquoi chacune est lente.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Schéma et index
Une table conçue pour les questions qu'on lui pose, et le bon index, transforment la lecture de chaque ligne en une recherche courte - l'exemple plus bas est un index qui fait exactement cela.
CREATE INDEX · ADD INDEX
Réglages du moteur
La mémoire est répartie entre la base, l'application et le système, puis les tampons de chaque moteur sont réglés en conséquence.
innodb_buffer_pool_size · shared_buffers · work_mem · wiredTiger cacheSizeGB
Cache
Les réponses répétées et les sessions restent en mémoire, si bien que la base est sollicitée moins souvent.
maxmemory-policy
Matériel
Plus de mémoire, des disques plus rapides ou plus de cœurs de processeur, une fois les niveaux du dessus épuisés.
RAM · CPU · disk I/O

Optimiser aussi le côté PHP

Une requête lente, trouvée et corrigée

La plupart des pages lentes tiennent à une requête. Le journal des requêtes lentes la nomme, EXPLAIN montre pourquoi elle est lente, et un seul index suffit souvent à tout corriger.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;

Une requête d'exemple sur une table d'exemple

Avant

type: ALL
key: NULL
Extra: Using where; Using filesort

Lit chaque ligne de la table, puis trie ce qu'elle a trouvé.

La correction : un index

ALTER TABLE orders
  ADD INDEX idx_customer_created (customer_id, created_at);

Après

type: ref
key: idx_customer_created
Extra: Backward index scan

Lit seulement les lignes de ce client, déjà dans l'ordre.

Une sauvegarde ne compte qu'une fois restaurée

Une copie nocturne seule fait perdre la journée. En gardant aussi le journal des modifications, nous pouvons ramener la base à la seconde qui précède une erreur.

Sauvegarde complète nocturne00:00 Restaurée jusqu'ici14:31:59 Un DELETE sans WHERE14:32:00

Chaque modification, écrite dans le journal au moment où elle se produit Rejouée sur la sauvegarde

Une journée d'exemple. Les heures sont inventées.

Restaurer la dernière sauvegarde complète
Sur un serveur à part, pour laisser la base en production intacte pendant que nous travaillons.
Rejouer le journal jusqu'à l'instant d'avant
Les journaux binaires pour MySQL et MariaDB, le WAL archivé pour PostgreSQL, l'oplog pour MongoDB.
Vérifier, puis récupérer les données
Soit les lignes perdues sont recopiées, soit la copie restaurée prend le relais - à vous de décider, la différence sous les yeux.

La restauration à un instant précis dépend du moteur :

MySQL · MariaDB · PostgreSQL · MongoDBà toute seconde couverte par le journal
Redisjusqu'à la dernière écriture du fichier append-only
SQLitejusqu'à la dernière copie du fichier
OpenSearch · Elasticsearchjusqu'au dernier instantané, puis reconstruit depuis la source

Les tests de restauration font partie du suivi convenu avec vous : sur un serveur à part, selon un calendrier fixé, chaque résultat consigné. Une sauvegarde que personne n'a restaurée est un espoir, pas une sauvegarde.

Le reste du travail

Ce dont une base de données a besoin, du jour de son installation à celui de sa mise à niveau, et les réglages que chaque étape touche.

Installation et dimensionnement
La version que votre application prend en charge, depuis le dépôt officiel de l'éditeur. La mémoire est répartie entre la base, l'application et le système avant tout autre réglage.
innodb_buffer_pool_size · shared_buffers · maxmemory · -Xmx
Index et requêtes lentes
Le journal des requêtes lentes est lu, les pires requêtes expliquées, et les index ajoutés ou supprimés avec la raison consignée.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Réplication
Une seconde copie qui suit la première, pour répartir les lectures et prendre le relais si le serveur principal tombe.
GTID · Galera · streaming replication · replica set
Sécurité
Une écoute limitée au réseau privé, un utilisateur par application avec uniquement les droits nécessaires, et des connexions chiffrées partout où le trafic quitte le serveur.
bind-address · TLS · GRANT · SCRAM · ACL
Surveillance
Connexions, retard de réplication, espace disque et requêtes lentes, avec une alerte avant qu'une limite soit atteinte plutôt qu'après.
max_connections · Seconds_Behind_Source · pg_stat_replication
Mises à niveau
Répétées d'abord sur une copie, les répliques avant le serveur principal, et le retour arrière écrit avant de commencer.
pg_upgrade · mariadb-upgrade · rolling restart

Dites-nous ce que fait votre base de données

Quel moteur, quelle taille, où elle tourne et ce qui vous inquiète. Nous regardons d'abord, puis chiffrons la mise en place ou le suivi après un échange.

Demander un devis Voir les offres d'hébergement

Services liés

Vitesse PHP OPcache, pools PHP-FPM, caches et requêtes : où passent les millisecondes, et comment les reprendre.Service infogéré Nous exploitons le serveur pour vous : correctifs, supervision, sauvegardes, incidents.Serveurs dédiés Une machine entière, provisionnée en quelques heures, gérée par la même équipe.Laravel Des applications Laravel avec files d’attente, tâches planifiées et déploiements sans coupure.