Bases de données

Ce que contient ce rayon

Des endroits où garder des données et les retrouver vite : moteurs relationnels, bases documentaires, caches clé-valeur, index de recherche, bases de séries temporelles et les services gérés qui font tourner n’importe lequel d’entre eux à votre place.

La plupart des équipes en ont besoin de moins que ne le suggèrent les éditeurs. Une seule base relationnelle suffit à la majorité des applications pendant longtemps, et ajouter un second moteur ajoute un second jeu de pannes, de sauvegardes et de personnes qui le comprennent.

L’analyse et le reporting sur ces données relèvent de l’analytique. L’endroit où tourne l’application elle-même, c’est l’hébergement et le cloud.

Choisir un moteur

Partez de la forme de vos données et des questions que vous leur poserez.

Les moteurs relationnels conviennent à tout ce qui comporte des relations, des transactions, des contraintes et du reporting, ce qui décrit la plupart des logiciels d’entreprise.

Les autres sont des spécialistes. Les bases documentaires conviennent aux enregistrements de forme variable, lus le plus souvent en entier. Les magasins clé-valeur sont faits pour la vitesse sur des recherches simples. Les index de recherche existent parce que la recherche de texte relationnelle ne suffit plus à partir d’une certaine taille, et les bases de séries temporelles parce que les métriques arrivent plus vite que tout le reste.

Le choix honnête par défaut est un moteur relationnel jusqu’à ce que quelque chose prouve qu’il est insuffisant. Les équipes qui commencent par un stockage exotique pour éviter un problème de montée en charge qu’elles n’ont pas rencontrent généralement d’abord un autre problème, pire.

La compatibilité compte plus que la marque. Un moteur qui parle un protocole largement implémenté vous donne des outils, des pilotes, du recrutement et une sortie. Une interface propriétaire vous donne un projet de migration.

Géré, auto-hébergé ou serverless

Les services gérés facturent une prime et suppriment un travail que vous feriez sinon à des heures peu commodes : correctifs, mises à niveau de version, bascule, vérification des sauvegardes.

L’auto-hébergement est moins cher sur le papier, et ne l’est en pratique que si la compétence est déjà dans la maison. Comptez honnêtement les heures, y compris celles passées le soir où un disque se remplit.

Les offres serverless adaptent la capacité à la charge et facturent peu à l’inactivité. Cela convient à un trafic irrégulier, et encore mieux aux environnements de développement. Vérifiez le comportement au démarrage à froid, les limites de connexions et la façon dont le compteur traite une tâche de fond qui ne s’arrête jamais.

Les questions qui décident de la fiabilité

• Sauvegardes : à quelle fréquence, pendant combien de temps elles sont conservées, et si vous pouvez restaurer à un instant choisi.
• Restauration : combien de temps dure une restauration complète à la taille de vos données, testée plutôt que promise.
• Bascule : automatique ou manuelle, sa durée, et ce que voit l’application pendant qu’elle se produit.
• Réplication : réplicas en lecture, copies entre régions, et le retard que votre code doit tolérer.
• Connexions : le plafond, et si le regroupement de connexions est inclus ou à faire tourner vous-même.

Menez une restauration pendant l’essai. Une sauvegarde que personne n’a restaurée est un espoir, et c’est la catégorie où l’espoir coûte le plus cher.

Croissance, migrations et ce qui fait mal plus tard

Les changements de schéma sur une grande table sont l’opération qui gâche les week-ends. Demandez comment le moteur gère l’ajout d’une colonne, le changement d’un type ou la construction d’un index pendant que le trafic continue.

Gardez les migrations sous gestion de versions, avec l’application, dès le premier jour. L’alternative, des changements appliqués à la main dans une console, produit des environnements qui diffèrent d’une manière que personne ne peut reconstituer.

Surveillez aussi l’emplacement des données. Une base dans une autre région que l’application ajoute de la latence à chaque requête, et une application qui fait cinquante requêtes par page le ressentira nettement.

Comment la facture se construit

Calcul, stockage, stockage des sauvegardes, sortie de données réseau, et sur certains services une unité pour les lectures et les écritures.

La sortie de données est la ligne qui surprend, surtout quand l’analytique ou les réplicas tirent de gros volumes entre régions. Le stockage diminue rarement de lui-même : des lignes supprimées peuvent encore être payées jusqu’au passage de la maintenance. Les copies de développement et de préproduction doublent tout, sauf si on les redimensionne ou si on les arrête la nuit.

Demandez ce que devient le prix à trois fois le volume d’aujourd’hui plutôt qu’au volume d’aujourd’hui, car c’est le chiffre que vous paierez réellement. Des habitudes voisines sont réunies dans ce que cachent les pages de tarifs.

Pratiques qui gardent une base de données ennuyeuse

Le but, dans cette catégorie, est l’absence de drame, et un petit nombre d’habitudes en produit l’essentiel.

Gardez les migrations sous gestion de versions et appliquez-les de la même façon dans chaque environnement. Les changements manuels faits dans une console produisent des écarts que personne ne peut reconstituer ensuite.

Ajoutez les index de façon délibérée et passez-les en revue de temps en temps, car ceux qui ne servent pas coûtent en performance d’écriture et en stockage tout en paraissant inoffensifs.

Surveillez les requêtes lentes en routine plutôt que pendant un incident. La requête qui prend quatre secondes aujourd’hui est la panne du trimestre prochain, quand la table aura grossi.

Et restaurez une sauvegarde selon un calendrier. Une copie qui n’a jamais été restaurée est un fichier, pas une garantie, et c’est la catégorie où le découvrir tard coûte le plus cher.