Designing Data-Intensive applications – Martin Kleppmann

The big ideas behind reliable, scalable and maintainable systems

Langue : anglais

5 ans. C’est le temps qu’il aura fallu à Martin pour rédiger ce livre de 550 pages. Pour respecter Martin et parce que j’ai beaucoup de choses à dire, sur ce livre, ce résumé sera assez long.

Après des études dans les grandes universités anglo-saxonnes et être passé chez des gros groupes de l’informatique, notamment LinkedIn, Martin Kleppmann est désormais blogueur et conférencier. Archétype de l’informaticien geek,, Martin est ce qu’on appelle dans le milieu une brute épaisse. Je ne sais pas à quel âge il a commencé à coder, mais c’est probablement entre l’état fœtal et la petite section.
Pour que vous ayez un peu un aperçu du niveau, voici le genre d’article qu’il publie :
https://martin.kleppmann.com/papers/curve25519.pdf 

En résumé, c’est un développeur de haut-niveau. Cependant, cet ouvrage est très bien noté (alors que souvent ce genre de personne est mauvais enseignant, car trop avancé techniquement) et est même un best-seller, ce qui m’a donné envie de l’acheter.
Ayant plus principalement travaillé sur des petites applications qui ne nécessitent pas de gros systèmes de données, j’étais curieux de découvrir comment les grosses entreprises et les gros sites informatiques gèrent un flux aussi monstrueux de données. Ce livre était parfait pour moi, car il semblait destiné aux développeurs au vu de son titre.

Concernant la forme du livre, il est en anglais bien sûr, mais dans un style parfaitement compréhensible
Le texte est rempli de références de nombreux de livres/articles, l’auteur a vraiment fait un travail très sérieux (comptez environ 80 références par chapitre de 50 pages), bon courage si vous voulez tout lire.
À chaque début de chapitre, il y a aussi une image avec les technologies dont il va parler. Ce n’est pas très utile, mais ça donne du cachet au livre et les dessins sont très réussis :

Designing Data-Intensive applications - Martin Kleppmann Map-ch11

Le vrai problème ce sont la taille des chapitres qui sont vraiment longs, la plupart font 50 pages et certains font 80 pages. De l’anglais technique, quand le sujet est précis et que l’on va aussi loin dans les détails, la fin du chapitre est souvent laborieuse.

Concernant le contenu, il faut le dire, globalement ce livre est formidable. Malgré la complexité du sujet, il n’y a jamais de code et tout reste parfaitement compréhensible. Je suis sûr qu’un non-informaticien avec une compréhension de l’informatique (qui comprend ce qu’est une base de données, les requêtes, etc.) pourrait même en tirer des choses intéressantes. Martin a réussi à aborder un sujet hautement spécialisé sans le rendre inaccessible.
Ce livre est un “must-read” pour tout développeur sérieux.

J’ai trouvé les 200 premières pages particulièrement intéressantes et je les ai carrément dévorées, les derniers chapitres étaient également très intéressants. Le milieu du livre était un peu plus fatiguant, les sujets étaient différents, mais les problèmes étaient les mêmes, ce qui le rendait un peu plus rébarbatif. C’est aussi le prix à payer pour un sujet aussi complexe.

Dans ce livre, vous apprendrez d’abord comment les données sont gérées à grande échelle, et je savais que ce sujet est important, car l’on peut expérimenter des difficultés même sur une petite application lorsque certaines fonctionnalités sont mal conçues.

On peut dire que les problèmes sont simples à résoudre lorsque les applications sont petites, mais le problème revient quand l’application grossit : qu’en est-il pour des applications comme Twitter, ou un seul utilisateur peut avoir plusieurs millions de followers ? Martin nous explique dans la première partie qu’il y a deux façons de faire : mettre du temps à la lecture des données ou mettre du temps à l’écriture.
Si vous suivez 1 million de personnes, la récupération de votre flux de tweets serait impossible, car trop lente, la solution et donc de pré-écrire votre flux quand quelqu’un que vous suivez publie un tweet : dans ce cas pré-écriture > lecture directe
Dans le cas d’un follower connu, c’est l’inverse, l’écriture serait trop complexe parce qu’il faudrait pré-publier le tweet sur le flux de millions de personnes et le tweeter en question attendrait des minutes, voire des heures pour que son tweet soit publié.
On voit donc qu’il n’existe pas forcément de bonne solution : dans le cas de Tweeter, cela dépend du nombre de follow-followers. Pour information, Tweeter utilise une solution hybride et les tweets ne sont pas traités de la même manière. Certains comptes sont traités en “hot-spot” pour signaler au système que le flux de données est plus grand à cet endroit. Bref, un beau capharnaüm.

L’auteur nous parle par la suite des différentes bases de données, notamment les bases de données qui sont apparues récemment (NoSQL, base de données cache type Redis) et comment elles fonctionnent en interne : B-tree, log, compact log, etc. Savoir la façon dont les BDD fonctionnent, même si ce n’est pas nécessaire pour les utiliser, est évidemment la clé pour comprendre le stockage de données.

Il nous présente également les formats de base de données, du SQL classique, au noSQL moderne, jusqu’aux formats spéciaux en étoiles pour les réseaux qui sont probablement utilisés par des services adaptés type Google Maps.
Cela va plus loin dans la fin du livre ou il nous parle du système de MapReduce avec Hadoop et Spark, qui sont des systèmes de stockage spéciaux utilisés par les grands groupes, le moteur de recherche de Google utilisant un système de ce type et le système de stockage de fichier Amazon S3 également. Bien sûr, il n’oublie pas les types de données en flux (streaming) en parlant des systèmes distribués type Kafka.

Tout au long du livre, j’ai été matraqué par de nouvelles technologies et de nouveaux noms dont je n’avais jamais entendu parler.
Le domaine du stockage de données était à peu près limité au quasi seul SQL il y a 10-15 ans, nous sommes en plein âge du big bang du stockage de données.

Sans aller loin dans le domaine de la Big Data, il nous présente également comment les Data scientists récupèrent et transforment les énormes quantités de données pour les exploiter du mieux possible pour faire de la Business Intelligence (analyse de données métier). Je ne connaissais pas grand-chose en big data, mais après ce livre, j’ai une vision plus claire de comment fonctionne ce domaine dans l’ensemble et du type d’outils qu’ils utilisent.

Ce livre a même eu le mérite de me faire totalement changer ma vision de la base de données : alors que je le voyais comme un simple système de stockage d’information, c’est désormais pour moi la représentation matérialisée d’un état du système entre des flux d’événements. Je l’avais toujours ressenti, mais jamais mis de mots dessus ce problème : le stockage de données classique de type SQL et même noSQL est voué à disparaître pour faire place à un système de stockage de flux d’événements. Rien que pour cela, tout développeur doit lire ce livre pour saisir cette nuance.

Non content de parler des données sur un seul ordinateur, il parle des systèmes distribués… Lorsque vous voulez augmenter la charge, il y a deux solutions : le scale-up ou augmentation verticale de la puissance (augmentation de la taille du disque dur, meilleur processeur, mémoire, etc.), mais cela a évidemment des limites physiques. La deuxième solution inévitable est donc le scale-out ou augmentation verticale de la puissance (on multiplie le nombre de serveurs).
Le problème est que votre système devient un système distribué où il faut gérer plusieurs serveurs en même temps.
Martin Kleppmann nous dresse un constat accablant : gérer des données sur plusieurs serveurs et votre système devient catastrophique et plante en permanence.
Après avoir lu ce livre, vous comprendrez pourquoi les serveurs mêmes des grosses entreprises ont des problèmes très fréquents et qu’il n’y a pas vraiment de bonne solution. En résumé, soit vous sacrifiez de la performance et votre système est plus stable et sûr, soit vous voulez de la performance et votre système devient plus instable : il n’y a pas de solution miracle et vous devez choisir ce que vous voulez.
Le plus terrible après avoir lu toute cette partie est que je vais commencer à voir des fantômes et avoir peur de problèmes qui n’arrivent pas en pratique sur un petit système ou qui sont résolus directement par les bases de données que l’on utilise. Mais qu’importe : réfléchir à ces détails permettent de concevoir des systèmes plus robustes et j’aurais aimé avoir lu ce livre pour comprendre des soucis que j’ai eus précédemment sur des projets.
Parmi les problèmes dont l’auteur nous parle dans les systèmes distribués, je citerais un assez simple, la latence du réseau (qui fait que deux personnes peuvent voir des données différentes en même temps) et un autre plus complexe, la synchronisation des horloges entre deux ordinateurs. Bref, Martin a pensé à tout même si le prix est de nous décourager (ou préparer mentalement) à construire un système distribué.

Finalement, ce livre est une mine d’or pour comprendre l’informatique à grande échelle d’aujourd’hui.

Seul point noir, il ne nous donne pas d’exemple concret, c’est un livre tres théorique, sans code, qui ne vous permettra pas de concevoir des applications. Au final le titre du livre n’a peut-être pas été très bien choisi, et le sous titre « The big ideas behind reliable, scalable and maintainable systems » explique bien mieux le contenu du livre.

Designing Data-Intensive applications - Martin Kleppmann 51zspm10