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

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.

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