Designing Data-Intensive Applications

1Vous êtes déjà un concepteur de systèmes de données

Les catégories d'outils ont fusionné sans prévenir personne : Redis est un datastore qui sert de file de messages, Kafka est une file de messages avec des garanties de durabilité de base de données. Dès que votre application combine une base, un cache et un index de recherche synchronisés par votre code, Kleppmann est formel : « vous n'êtes plus seulement développeur d'application, vous êtes aussi concepteur de systèmes de données » (p. 5). Le titre n'est pas honorifique, il vient avec les responsabilités : c'est votre code applicatif qui garantit (ou pas) que le cache est invalidé au bon moment. Le livre entier découle de ce constat : puisque vous assemblez des systèmes de données, autant comprendre ce qu'il y a dedans.

2Décrire la charge avant de la subir : le fan-out de Twitter

« X est scalable » ne veut rien dire ; la vraie question est « si la charge grandit de telle façon, quelles sont nos options ? ». L'exemple fil rouge du livre : Twitter en 2012, 4 600 tweets postés par seconde, mais 300 000 lectures de timeline par seconde. Pré-calculer chaque timeline à l'écriture transforme 4 600 tweets/s en 345 000 écritures/s, et un compte à 30 millions de followers déclenche 30 millions d'écritures pour un seul tweet (p. 11-13). La solution finale est hybride : fan-out pour tout le monde, sauf les célébrités, fusionnées à la lecture. La leçon dépasse Twitter : identifiez votre « load parameter » (ici, la distribution des followers) avant de choisir une architecture. Et mesurez en percentiles, pas en moyennes : Amazon spécifie ses services au 99,9e percentile parce que les requêtes les plus lentes frappent les clients aux comptes les plus remplis, donc les plus précieux (p. 15).

3La base de données la plus simple du monde tient en deux fonctions bash

db_set () {
    echo "$1,$2" >> database
}
db_get () {
    grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

Écriture en temps constant (on ajoute à la fin du fichier), lecture catastrophique (on relit tout). C'est l'ouverture du chapitre 3, et tout moteur de stockage réel n'est qu'une réponse à ce déséquilibre, résumée en une loi : « des index bien choisis accélèrent les lectures, mais chaque index ralentit les écritures » (p. 71). De là, deux familles : les LSM-trees (Cassandra, RocksDB), qui gardent l'esprit append-only et compactent en arrière-plan, rapides en écriture ; les B-trees (PostgreSQL, MySQL), qui écrasent des pages en place, rapides et prévisibles en lecture. Kleppmann refuse de trancher à votre place : « il n'y a pas de règle simple et rapide […] ça vaut la peine de tester empiriquement » (p. 85).

4NoSQL est un remake : le match s'est déjà joué en 1970

IMS, la base de données d'IBM développée à l'origine pour la gestion de stock du programme Apollo (1968), rangeait les données en arbres imbriqués qui ressemblent étrangement au JSON des bases documentaires modernes. Mêmes forces (le one-to-many est naturel), mêmes impasses : les relations many-to-many sont pénibles et les jointures inexistantes. « Ces problèmes des années 1960-70 ressemblent furieusement à ceux que les développeurs rencontrent aujourd'hui avec les bases documentaires » (p. 36). Le modèle relationnel de Codd a gagné le « grand débat » des années 70 précisément en cachant l'implémentation derrière une interface propre. Quant au « schemaless », Kleppmann le démonte en une analogie : schema-on-read, c'est du typage dynamique ; schema-on-write, du typage statique. Le schéma existe toujours, la seule question est qui le fait respecter.

5Répliquer, c'est facile. Répliquer ce qui change, c'est tout le problème

« Toute la difficulté de la réplication tient dans la gestion des changements apportés aux données répliquées » (p. 151). Un leader reçoit les écritures, des followers le suivent avec un retard variable : ce « replication lag » fabrique des anomalies que le chapitre nomme une par une. Vous postez un commentaire, vous rechargez, il a disparu (lecture sur un follower en retard : read-your-own-writes). Une réponse apparaît avant sa question (violation de causalité : consistent prefix reads, illustrée par un dialogue digne de Pratchett entre Mr. Poons et Mrs. Cake, p. 165). Et le failover n'est pas gratuit : chez GitHub, un follower MySQL en retard promu leader a réutilisé des clés primaires déjà distribuées, et comme ces clés indexaient aussi un store Redis, des données privées sont parties chez les mauvais utilisateurs (p. 157). Chaque garantie supplémentaire a un coût ; faire semblant que la réplication asynchrone est synchrone, c'est « la recette assurée de problèmes futurs » (p. 167).

6« ACID est malheureusement devenu surtout un terme marketing »

La phrase est de Kleppmann (p. 223), et il la documente : le C de Consistency a été « ajouté pour que l'acronyme fonctionne » selon Joe Hellerstein, et c'est de toute façon une propriété de votre application, pas de la base. Pire, les niveaux d'isolation portent les mêmes noms partout en désignant des choses différentes : le « serializable » d'Oracle est en réalité de la snapshot isolation, si bien que « personne ne sait vraiment ce que repeatable read signifie » (p. 242). Le chapitre 7 vaut à lui seul le livre pour sa galerie d'anomalies nommées. La plus sournoise : le write skew. Alice et Bob, médecins de garde, consultent chacun le planning, voient « 2 médecins de garde », et se désinscrivent tous les deux en même temps. Aucun conflit détecté, deux transactions valides, zéro médecin de garde (p. 246-248). Seule l'isolation sérialisable l'empêche, et presque aucune base ne l'active par défaut.

7Le réseau ment, l'horloge ment, et votre process aussi

Le chapitre 8 est le plus célèbre du livre, et le plus contre-intuitif. Dans un système distribué, une requête sans réponse ne dit pas si la requête s'est perdue, si le serveur est mort, ou s'il est juste en pause garbage collector (des pauses « stop-the-world » qui peuvent durer plusieurs minutes, p. 296). Les horloges dérivent : Google budgète 200 ppm pour ses serveurs, soit 17 secondes d'écart par jour sans resynchronisation (p. 289). Un thread peut vérifier qu'il détient un verrou, se figer 15 secondes, puis écrire en croyant être encore leader ; la parade, le fencing token, est un simple compteur croissant que le stockage vérifie. La litanie des pannes réelles citées va des requins qui mordent les câbles sous-marins au conducteur en hypoglycémie qui encastre son pickup dans la climatisation d'un datacenter (p. 275, 279). D'où la devise du chapitre : « dans les systèmes distribués, la suspicion, le pessimisme et la paranoïa paient » (p. 277).

8Oubliez le théorème CAP, apprenez le mot « linéarisable »

Le CAP façon « cohérence, disponibilité, tolérance aux partitions : choisissez-en deux » est trompeur, dit Kleppmann : une partition réseau n'est pas un choix d'architecte, c'est une panne qui vous arrivera de toute façon. Son verdict est sec : « mieux vaut éviter CAP » (p. 337). Le concept utile à la place : la linéarisabilité, l'illusion qu'il n'existe qu'une seule copie de la donnée. L'exemple du livre est limpide : Alice et Bob regardent la finale de la Coupe du monde 2014, Alice rafraîchit et annonce le score final ; Bob rafraîchit après l'avoir entendue et son téléphone, tombé sur un réplica en retard, affiche encore « match en cours » (p. 325). Cette garantie de fraîcheur coûte cher en latence ; le livre vous apprend à savoir quand vous en avez vraiment besoin, et quand la cohérence causale suffit.

9L'état de votre application est l'intégrale de son flux d'événements

La plus belle idée de la fin du livre se formule en une phrase : l'état, c'est ce qu'on obtient en intégrant un flux d'événements dans le temps ; le flux de changements, c'est la dérivée de l'état (p. 460). Concrètement : au lieu d'écrire dans la base ET dans le cache ET dans l'index (trois écritures qui peuvent se contredire), on écrit dans un log ordonné (Kafka), et tout le reste en dérive dans le même ordre. C'est le Change Data Capture, et c'est l'idée que Kleppmann a baptisée « database inside-out ». Son rêve inachevé : pouvoir écrire mysql | elasticsearch comme un pipe Unix, l'équivalent « unbundled » de CREATE INDEX (p. 503). Aujourd'hui, des produits entiers (Debezium, Materialize) vivent de cette idée.