Martin Kleppman est chercheur à l'Université de Cambridge et travaille sur le CRDT et la vérification formelle des algorithmes. Son livre
Designing Data-Intensive Applications , publié en 2017, est devenu un best-seller du stockage et du traitement des données.
Kevin Scott (CTO chez Microsoft) a
déclaré un jour : «Ce livre devrait être un must pour les ingénieurs de développement. Il s'agit d'une ressource rare alliant théorie et pratique, aidant les développeurs à approfondir la conception et la mise en œuvre des infrastructures et des systèmes de traitement des données. " Quelque chose de similaire a été dit par Jay Kreps, le créateur d'Apache Kafka et PDG Confluent.
Avant de commencer la recherche universitaire, Martin a travaillé dans l'industrie et a cofondé deux startups à succès: Rapportive (acheté par LinkedIn en 2012) et Go Test It (acheté par RedGate).
Cet habrapost est une interview détaillée de Martin. Exemples de sujets de discussion:
- Transition de la recherche commerciale à la recherche universitaire;
- Prérequis pour l'écriture de la conception d'applications à forte intensité de données;
- Bon sens contre le battage médiatique artificiel et les outils publicitaires;
- Théorèmes CAP inutiles et autres erreurs de l'industrie;
- L'utilité de la décentralisation;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Nouveau CRDT. Vérification formelle chez Isabelle;
- Discussion sur la recherche d'événements. Approche de bas niveau. Transactions XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Tout utiliser dans la vraie vie;
- Le seuil pour entrer les rapports de Martin et la conférence Hydra.
L'interview a été réalisée par
Vadim Tsesko (
@incubos ) - un développeur de premier plan dans l'équipe de la société Odnoklassniki Platform. Les intérêts scientifiques et techniques de Vadim concernent les systèmes distribués et les entrepôts de données, ainsi que la vérification des systèmes logiciels.
De la recherche commerciale à la recherche universitaire
Vadim : Je voudrais commencer par une question qui est très importante pour moi personnellement. Vous avez fondé Go Test It et Rapportive, et vous êtes depuis longtemps engagé dans le développement de grands systèmes sur LinkedIn, mais vous avez ensuite décidé de quitter le développement commercial et de faire des recherches à l'université. Pourriez-vous me dire ce qui vous a poussé à cela? Quels sont les avantages de travailler dans une université et qu'avez-vous sacrifié?
Martin : Ce fut une transition très intéressante. Si je comprends bien, vous êtes intéressé par ma décision étant donné que beaucoup de gens partent pour la recherche académique du développement commercial, beaucoup plus souvent il y a un mouvement dans la direction opposée. Cela est compréhensible, car les revenus dans les universités sont nettement inférieurs à ceux des entreprises. Je suis personnellement attiré par le poste de chercheur par le fait que je peux décider par moi-même sur quels sujets travailler, et je fais ce choix sur la base de ce qui me semble intéressant et important, même si travailler sur un sujet ne promet pas de faire du profit dans les 6 prochains mois. Tout ce pour quoi vous travaillez dans une entreprise doit être vendu sous une forme ou une autre. En ce moment, je travaille sur des sujets qui sont importants pour l'avenir d'Internet et des logiciels, mais notre compréhension d'eux n'est pas encore assez profonde pour créer un produit fini. Jusqu'à présent, nous n'avons même pas une idée générale du fonctionnement de ces technologies. Puisque ces études sont fondamentales, j'ai décidé qu'il valait mieux les mener à l'université, et non à l'entreprise: l'université a plus de liberté, là on peut faire des choses qui ne rapporteront aucun profit avant 10 ans. L'horizon de planification est beaucoup plus large.
Book Designing Data-Intensive Applications
Vadim : Nous reviendrons certainement sur le sujet de la recherche, mais pour l'instant parlons de votre livre,
Designing Data-Intensive Applications . À mon avis, c'est l'un des meilleurs guides sur les systèmes distribués modernes, presque une encyclopédie: il répertorie toutes les réalisations les plus importantes qui existent aujourd'hui.
Martin : Merci, je suis content que ce soit utile.
Vadim : Il est peu probable que nos lecteurs ne le connaissent pas encore, mais juste au cas où, discutons des réalisations les plus importantes dans le domaine des systèmes distribués que vous écrivez.
Martin : En fait, en écrivant ce livre, je n'avais pas fixé d'objectif pour décrire certaines technologies. Je voulais plutôt faire un guide à travers le monde des systèmes utilisés pour stocker et traiter les données. Il existe maintenant un grand nombre de bases de données, de processeurs de flux, d’outils de traitement par lots, de toutes sortes d’outils de réplication, etc. Il est donc très difficile de composer une image globale de cette zone. Et si vous avez besoin d'une base de données pour résoudre un problème spécifique, il est difficile de choisir l'un des nombreux existants. De nombreux livres écrits sur de tels systèmes sont tout simplement inutiles dans ce cas. Par exemple, dans un livre sur Apache Cassandra, il peut être écrit sur la beauté de Cassandra, mais rien ne sera dit sur les tâches pour lesquelles il ne convient pas. Par conséquent, dans mon livre, j'essaie d'identifier les questions de base que vous devez vous poser lors de l'écriture de grands systèmes. Les réponses à ces questions aideront à déterminer quelles technologies sont bien adaptées pour résoudre le problème actuel et lesquelles ne sont pas très bonnes. L'essentiel est qu'aucune technologie ne peut tout faire. J'essaie de montrer quels sont les avantages et les inconvénients des différentes technologies dans différents contextes.
Vadim : En effet, de nombreuses technologies ont des caractéristiques et des fonctionnalités communes et fournissent le même modèle de données. En même temps, on ne peut pas se fier à la publicité, et pour comprendre la structure interne du système, il faut lire non seulement les rapports techniques et la documentation, mais même les codes sources.
Bon sens contre battage publicitaire artificiel et publicité sur les outils
Martin : De plus, il faut souvent lire entre les lignes, car la documentation ne dit pas pour quelles tâches la base de données n'est pas très adaptée. En fait, toute base de données a ses propres limites, vous devez donc toujours savoir lesquelles. Souvent, vous devez lire les guides de déploiement et reconstruire le fonctionnement interne du système.
Vadim : Oui, c'est un excellent exemple. Ne pensez-vous pas que dans ce domaine, il n'y a pas suffisamment de vocabulaire commun ou un ensemble unique de critères, à l'aide desquels il serait possible de comparer différentes solutions pour un problème? Désormais, des noms différents sont utilisés pour les mêmes choses, et de nombreux aspects qui doivent être clairement et clairement énoncés ne sont pas du tout mentionnés - par exemple, les garanties de transactionnalité.
Martin : Oui, vraiment. Malheureusement, dans notre industrie, il y a très souvent une excitation excessive autour de différents instruments. Ce qui est compréhensible, car ces outils sont créés par des entreprises qui souhaitent promouvoir leurs produits. Par conséquent, ces entreprises envoient des personnes à des conférences et elles parlent essentiellement de ce que ces produits sont formidables. Cela se fait passer pour des rapports techniques, mais, en substance, c'est une publicité. En tant qu'industrie, cela ne nous ferait pas de mal d'être plus honnête au sujet des avantages et des inconvénients de nos produits. Une des conditions pour cela est la terminologie générale; sans elle, il est impossible de comparer les choses. Mais en plus de cela, des méthodes sont nécessaires pour analyser les avantages et les inconvénients de diverses technologies.
Théorèmes de la PAC inutiles et autres erreurs de l'industrie
Vadim : Ma prochaine question est assez sensible. Pourriez-vous nous parler des erreurs courantes dans notre industrie que vous avez rencontrées au cours de votre carrière? Par exemple, à propos d'une technologie surfaite ou d'une solution largement utilisée dont vous auriez dû vous débarrasser il y a longtemps? Ce n'est peut-être pas le meilleur exemple, mais il me vient à l'esprit d'utiliser JSON sur HTTP / 1.1 au lieu de gRPC sur HTTP / 2. Ou peut-être ne partagez-vous pas ce point de vue?
Martin : Le plus souvent, lors de la création de systèmes, pour réaliser une chose, il faut sacrifier autre chose, et ici je préfère ne pas parler d'erreurs. Dans le cas d'un choix entre JSON sur HTTP / 1.1 et, disons, les tampons de protocole sur HTTP / 2, les deux options ont le droit d'exister. Si vous décidez d'utiliser des tampons de protocole, vous devez définir un schéma, et il peut être très utile, car il permet de déterminer avec précision le comportement du système. Mais dans certaines situations, un tel schéma ne cause rien d'autre que de la gêne, en particulier dans les premiers stades de développement, lorsque les formats de données changent assez souvent. Encore une fois, ici, pour atteindre un certain objectif, il faut sacrifier quelque chose, et dans certaines situations, cela est justifié, mais dans d'autres non. Il n'y a pas tellement de solutions qui peuvent vraiment être qualifiées de mauvaises. Mais puisque nous en parlons, parlons du théorème de la PAC - à mon avis, il n'y a absolument aucun avantage. Lorsqu'il est utilisé dans la conception de systèmes, soit il y a un malentendu sur la signification du théorème de la PAC, soit des déclarations évidentes sont corroborées à l'aide de celui-ci. Il utilise un modèle de cohérence très étroitement défini - linéarisation et un modèle d'accessibilité très étroitement défini - chaque réplique doit être entièrement accessible, même si elle ne peut pas établir de connexion avec une autre réplique. D'une part, ces définitions sont tout à fait correctes, mais, d'autre part, elles sont trop étroites: de nombreuses applications n'ont tout simplement pas besoin d'une telle définition de cohérence ou d'accessibilité. Et si l'application utilise une définition différente de ces mots, le théorème CAP lui est inutile. Je ne vois donc pas grand-chose à l'appliquer. Soit dit en passant, depuis que nous avons commencé à parler d'erreurs dans notre industrie, admettons honnêtement que l'extraction de crypto-monnaie est un gaspillage d'électricité. Je ne comprends pas comment vous pouvez le faire sérieusement.
Vadim : De plus, la plupart des technologies de stockage sont désormais personnalisables pour une tâche spécifique, c'est-à-dire Vous pouvez sélectionner le mode de fonctionnement approprié en présence de pannes.
Martin : C'est vrai. De plus, une partie importante des technologies ne relèvent pas de la définition stricte de cohérence et d'accessibilité du théorème CAP, c'est-à-dire qu'elles ne sont pas CP, ni AP ni CA, mais seulement P. Personne n'écrira directement sur ce logiciel, mais en réalité il peut Être une stratégie de développement parfaitement rationnelle. C'est l'une des raisons pour lesquelles je pense que le CAP lors de l'analyse de logiciels est plus nuisible que bon: une partie importante des décisions de conception ne sont pas présentées de quelque manière que ce soit, et ce peuvent être des solutions tout à fait rationnelles, mais le CAP ne permet pas de les décrire.
Les avantages de la décentralisation
Vadim : Quels sont les problèmes les plus aigus dans le développement d'applications à forte intensité de données actuellement? Quels sujets sont les plus activement explorés? Pour autant que je sache, vous êtes partisan de l'informatique décentralisée et de l'entreposage de données décentralisé.
Martin : Oui. Un des points que je prouve dans mes recherches est que pour le moment nous comptons trop sur les serveurs et la centralisation. À ses débuts, quand il a évolué à partir d'ARPANET, il a été conçu comme un réseau très stable dans lequel des paquets peuvent être envoyés le long de diverses routes, et ils atteignent toujours leur objectif. En cas d'explosion nucléaire dans n'importe quelle ville d'Amérique, la partie survivante du réseau continuerait de fonctionner, des itinéraires alternatifs seraient simplement utilisés pour contourner les sections défaillantes. C'était un plan généré par la guerre froide. Mais ensuite, nous avons décidé de tout placer dans le cloud, alors maintenant presque tout passe en quelque sorte par l'un des centres AWS quelque part en Virginie, dans l'est des États-Unis. À un moment donné, nous avons abandonné l'idéal d'une utilisation décentralisée des différentes parties du réseau et identifié les services dont dépend désormais tout. Je considère qu'il est important de revenir à une approche décentralisée, dans laquelle plus de contrôle sur les données n'appartiendrait pas aux services, mais aux utilisateurs finaux.
En matière de décentralisation, ils signifient très souvent des choses comme les crypto-monnaies, car ils ont des réseaux d'agents en interaction sur lesquels il n'y a pas d'autorité centralisée unique comme une banque. Mais ce n'est pas la décentralisation dont je parle, car, à mon avis, les crypto-monnaies sont également extrêmement centralisées: si vous devez conclure un accord avec Bitcoin, cela doit être fait via le réseau Bitcoin, donc tout est centralisé autour de ce réseau. La structure du réseau est décentralisée en ce sens qu'elle n'a pas de centre organisateur unique, mais le réseau dans son ensemble est extrêmement centralisé, car chaque transaction doit être effectuée via ce réseau et rien d'autre. Je pense que c'est aussi une forme de centralisation. Dans le cas des crypto-monnaies, cela est inévitable, car il est nécessaire de garantir l'absence de double coût, ce qui est difficile à réaliser sans un réseau qui fournit un consensus sur les transactions qui ont été effectuées, etc. Mais il existe de nombreuses applications qui ne nécessitent pas de système comme une blockchain; elles peuvent fonctionner avec un modèle de données beaucoup plus flexible. Ce sont ces systèmes décentralisés qui m'intéressent le plus.
Vadim : Puisque vous avez évoqué la blockchain, pouvez-vous nous parler de technologies prometteuses ou peu connues dans le domaine des systèmes décentralisés? J'ai moi-même joué avec IPFS, mais vous avez beaucoup plus d'expérience dans ce domaine.
Martin : En fait, je ne suis pas activement en train de suivre de telles technologies. J'ai lu un peu sur IPFS, mais je ne l'ai pas utilisé moi-même. Nous avons un peu travaillé avec
Dat , qui, comme
IPFS , est une technologie de stockage décentralisé. La différence est que la
crypto -
monnaie Filecoin est liée à IPFS, et elle est utilisée pour payer le stockage des données, et aucune blockchain n'est liée à Dat. Dat vous permet uniquement de répliquer des données sur plusieurs machines sur une base P2P, et pour le projet sur lequel nous travaillions, Dat est génial. Nous avons écrit un logiciel permettant aux utilisateurs de collaborer sur un document, des données ou une base de données, et chaque modification de ces données est envoyée à tous ceux qui ont une copie des données. Dans un tel système, Dat peut être utilisé selon le principe P2P, de sorte qu'il assure un fonctionnement au niveau du réseau, c'est-à-dire NAT Traversal et passant par des pare-feu, ce qui est une tâche assez difficile. En plus de cela, nous avons écrit un niveau à partir du CRDT, avec l'aide duquel plusieurs personnes pouvaient éditer un document ou un jeu de données et qui permettait de partager rapidement et facilement des modifications. Je pense qu'un système similaire pourrait être écrit sur IPFS, tout en ignorant Filecoin et en utilisant uniquement la réplication P2P.
Vadim : Mais un tel système ne serait-il pas devenu moins réactif, car WebRTC connecte directement les nœuds entre eux, et IPFS est plus une table de hachage distribuée.
Martin : Le fait est que WebRTC est un niveau de pile légèrement différent. Il est principalement destiné aux appels vidéo - avec une forte probabilité, il est utilisé dans le logiciel par lequel nous communiquons maintenant. De plus, WebRTC fournit un canal par lequel vous pouvez envoyer des données binaires arbitraires. Mais créer un système de réplication par-dessus peut être difficile. Mais dans Dat et IPFS, vous n'avez rien à faire pour cela.
Vous avez mentionné la réactivité, et c'est un facteur très important à garder à l'esprit. Supposons que nous voulons décentraliser le prochain Google Docs. Dans Google Docs, l'unité de modification est une seule frappe et chaque nouveau personnage peut être envoyé en temps réel à d'autres personnes qui travaillent avec le même document. D'une part, cela garantit une collaboration rapide, d'autre part, cela signifie que lors de l'écriture d'un document volumineux, vous devez envoyer des centaines de milliers de modifications à un caractère, et de nombreuses technologies existantes effectuent mal la compression de ce type de données. Même si nous supposons que pour chaque frappe, il est nécessaire d'envoyer uniquement une centaine d'octets, alors pour un document de 100000 caractères, il sera nécessaire d'envoyer 10 Mo de données, bien qu'un tel document ne prenne généralement pas plus de plusieurs dizaines de kilo-octets. Jusqu'à ce qu'une méthode ingénieuse de compression ait été inventée, une telle synchronisation des données nécessite un énorme coût supplémentaire de ressources. De nombreux systèmes P2P ne disposent pas encore d'un moyen efficace de créer des instantanés de l'état qui leur permettraient d'être utilisés pour un système comme Google Docs. C'est ce problème sur lequel je travaille actuellement, en essayant de créer un algorithme pour une synchronisation plus efficace des documents pour plusieurs utilisateurs. Il doit s'agir d'un algorithme qui ne stockerait pas chaque frappe, car cela nécessite trop de ressources et devrait permettre une utilisation plus efficace du réseau.
Nouveau CRDT, vérification formelle chez Isabelle
Vadim : Pourriez-vous nous en dire plus à ce sujet? Avez-vous réussi à réaliser plus de 100 fois la compression des données? Parlez-vous de nouvelles techniques de compression ou de CRDT spéciaux?
Martin : Oui. Jusqu'à présent, nous n'avons qu'un prototype, il n'est pas encore complètement implémenté. Des expériences supplémentaires doivent être effectuées pour découvrir son efficacité dans la pratique. Mais certaines de nos méthodes sont prometteuses. Dans mon prototype, j'ai pu réduire la taille d'une seule modification de 100 à 1,7 octets. Mais, je le répète, ce n'est qu'une version expérimentale jusqu'à présent, cet indicateur peut changer légèrement. D'une manière ou d'une autre, il existe de grandes opportunités d'optimisation dans ce domaine.
Vadim : Donc votre rapport à la conférence Hydra en parlera?
Martin : Oui. J'aurai une courte introduction sur le CRDT, les logiciels de collaboration et certains problèmes qui se posent dans ce contexte. Je parlerai ensuite des recherches que nous effectuons dans ce domaine - elles traitent de nombreux problèmes différents. Côté application, nous avons une implémentation de ces algorithmes en JavaScript, à partir de cela nous créons des programmes fonctionnels pour mieux comprendre le comportement des algorithmes. Dans le même temps, nous travaillons également sur des méthodes formelles pour prouver l'exactitude de ces algorithmes, car certains d'entre eux sont assez peu évidents, et nous voulons nous assurer qu'ils atteignent toujours un état cohérent. De nombreux algorithmes développés précédemment ne fournissent pas de cohérence dans certains cas limites. Pour éviter cela, nous nous sommes tournés vers des méthodes formelles pour prouver l'exactitude.
Vadim : Utilisez-vous des preuves théoriques comme Coq ou Isabelle pour ce système?
Martin : Oui,
Isabelle .
Note de la rédaction: Martin lira une conférence sur Isabelle à The Strange Loop.
Vadim :
Envisagez -vous de publier ces preuves?
Martin : Oui, le premier ensemble de preuves que nous avons
publié il y a un an et demi, ainsi que le cadre de vérification du CRDT. Nous avons testé trois CRDT à l'aide de ce cadre, dont le plus important était RGA (
Replicated Growable Array ), CRDT pour la coédition de texte. Cet algorithme n'est pas trop compliqué, mais plutôt non évident, il n'est pas immédiatement clair s'il est correct, une preuve formelle était donc nécessaire. Nous avons également travaillé à prouver l'exactitude de plusieurs CRDT existants, et la dernière chose que nous avons faite dans ce domaine a été de créer nos propres CRDT pour de nouveaux modèles de données.
Vadim : Combien coûte plus le volume de la preuve formelle que la taille du code de l'algorithme lui-même? Il y a parfois des difficultés avec cela.
Martin : Vraiment assez de difficultés, nous devons beaucoup travailler avec des preuves. : 60 , , 800 . , 12 . , . , . , . . , .
: , ? ?
: , . , . : TCP, Git . , , . , . . , .
Event sourcing, , XA-
:
, . , event sourcing. , - . event sourcing ? - , .
: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .
event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.
, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .
: . , , , , .
: , , JSON (, PostgreSQL ) . , . . , .
: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .
: , , , — ?
: . , , , , , 404, .
: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .
: ,
Multiversion Concurrency Control .
: , . XA-, , , . , , . , , . XA . , , . .
: , - .
: , . , , , . , . - , . , . - , : , , , . . , .
: , . , . - , , , - .
: . . , , . , .
: , . event sourcing. , , , . , . , , , . , , , , , . ?
: , . , , . , , , , . . , . , , .
: , , , .
: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .
: . .
: .
: , , . , — , . .
Hydra 2019,
: , Hydra? , , , .
: , , , , « » « ». . . , , - ; , , , , .
: , , , ? . , , ?
: , . , . , . - . , - , - . , . : , . — , — . , , , .
: . ? , - , , ?
: . . , . , , , . - — . , , . : . , , Slack ,
. , , . , , , .
: .
: , .
: ,
!
Je vous rappelle qu'il s'agit d'une interview préenregistrée. Lorsque vous écrivez des commentaires, n'oubliez pas que Martin ne les lira pas. Nous ne pouvons transmettre que quelque chose de plus intéressant. Si vous voulez vraiment parler avec l'auteur, il fera une présentation «Synchroniser les données entre les appareils des utilisateurs pour une collaboration distribuée» lors de la conférence Hydra 2019, qui se tiendra les 11 et 12 juillet 2019 à Saint-Pétersbourg. Les billets peuvent être achetés sur le site officiel .