Dr. Martin Kleppmann ist Forscher für verteilte Systeme an der Universität von Cambridge und Autor des hochgelobten
"Designing Data-Intensive Applications" (O'Reilly Media, 2017).
Kevin Scott, CTO bei Microsoft
, sagte einmal : „Dieses Buch sollte für Softwareentwickler unbedingt gelesen werden müssen. "Das Entwerfen datenintensiver Anwendungen ist eine seltene Ressource, die Theorie und Praxis miteinander verbindet, um Entwicklern beim Entwerfen und Implementieren von Dateninfrastrukturen und -systemen zu helfen, kluge Entscheidungen zu treffen."
Martins Forschungsschwerpunkte sind Collaboration-Software, CRDTs und die formale Verifizierung verteilter Algorithmen. Zuvor war er Softwareentwickler und Unternehmer bei verschiedenen Internetunternehmen, darunter LinkedIn und Rapportive, wo er an einer großen Dateninfrastruktur arbeitete.
Vadim Tsesko (
@incubos ) ist ein führender Softwareentwickler bei
Odnoklassniki, der im Core Platform-Team arbeitet. Zu den wissenschaftlichen und technischen Interessen von Vadim gehören verteilte Systeme, Data Warehouses und die Überprüfung von Softwaresystemen.
Inhalt:
- Übergang von der Wirtschaft zur akademischen Forschung;
- Diskussion über "Entwerfen datenintensiver Anwendungen";
- Gesunder Menschenverstand gegen künstlichen Hype und aggressives Marketing;
- Fallstricke des GAP-Theorems und anderer Branchenfehler;
- Vorteile der Dezentralisierung;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Neue CRDTs. Formale Überprüfung mit Isabelle;
- Event-Sourcing. Low-Level-Ansatz. XA-Transaktionen
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Wie man all diese Werkzeuge auf das wirkliche Leben anwendet;
- Erwartete Zielgruppe von Martins Vorträgen und der Hydra-Konferenz.
Übergang von der Wirtschaft zur akademischen Forschung
Vadim : Die erste Frage, die ich Ihnen stellen möchte, ist wirklich wichtig für mich. Sie haben Go Test It und Rapportive gegründet und bei LinkedIn schon seit einiger Zeit Großsysteme entworfen und entwickelt. Dann haben Sie sich entschieden, vom Wirtschaftsingenieurwesen zum akademischen Bereich zu wechseln. Könnten Sie bitte die Motivation für diese Entscheidung erläutern? Was hast du gewonnen und was musstest du opfern?
Martin : Es war ein sehr interessanter Prozess. Wie Sie anscheinend andeuten, wechseln nicht viele Menschen in diese Richtung. Viele Menschen gehen von der Wissenschaft in die Industrie, aber nicht so viele zurück. Das ist verständlich, denn ich musste ziemlich viel bezahlen, um wieder in die Wissenschaft zu gehen. Was ich an der Forschung wirklich liebe, ist die Freiheit, an Themen zu arbeiten, die ich interessant finde und die ich für wichtig halte, auch wenn diese Themen nicht innerhalb der nächsten 6 Monate zu einem wirtschaftlich tragfähigen Produkt führen. Natürlich muss sich das, was Sie bauen, in einem Unternehmen in ein Produkt verwandeln, das in der einen oder anderen Form verkauft werden kann. Andererseits sind die Dinge, an denen ich gerade arbeite, Themen, die für die Zukunft der Entwicklung von Software und der Funktionsweise des Internets wirklich wichtig sind. Aber wir verstehen diese Themen noch nicht gut genug, um kommerzielle Produkte zu entwickeln: Wir sind immer noch auf der Ebene, um herauszufinden, wie diese Technologien grundsätzlich aussehen müssen. Und da dies Grundlagenforschung ist, wurde mir klar, dass es besser ist, dies an einer Universität zu tun, als es in einem Unternehmen zu versuchen, weil ich an einer Universität frei bin, an Dingen zu arbeiten, die für weitere zehn Jahre möglicherweise nicht wirtschaftlich werden, und das ist OK Es ist in Ordnung, mit einem viel längeren Zeithorizont zu arbeiten, wenn Sie in der Forschung sind.
„Entwerfen datenintensiver Anwendungen“
Vadim : Wir werden auf jeden Fall auf Ihre aktuellen Forschungsinteressen zurückkommen. Lassen Sie uns in der Zwischenzeit über Ihr aktuelles Buch
Entwerfen datenintensiver Anwendungen sprechen. Ich bin ein großer Fan Ihres Buches und ich glaube, es ist einer der besten Anleitungen zum Aufbau moderner verteilter Systeme. Sie haben fast alle bemerkenswerten Erfolge auf dem neuesten Stand behandelt.
Martin : Danke, ich bin froh, dass du es nützlich findest.
Vadim : Könnten Sie bitte nur für die unglücklichen Leser, die Ihr Buch noch nicht gelesen haben, einige wichtige Erfolge auf dem Gebiet der verteilten Systeme nennen?
Martin : Nun, das Ziel des Buches ist nicht so sehr, eine bestimmte Technologie zu erklären. Ziel ist es vielmehr, Ihnen einen Leitfaden für die gesamte Landschaft verschiedener Systeme zu geben, die zum Speichern und Verarbeiten von Daten verwendet werden. Es gibt so viele verschiedene Datenbanken, Stream-Prozessoren, Stapelverarbeitungstools, alle Arten von Replikationstools usw., und es ist wirklich schwierig, sich einen Überblick zu verschaffen. Wenn Sie versuchen, eine bestimmte Anwendung zu erstellen, ist es sehr schwierig zu wissen, welche Datenbank Sie verwenden sollten und welche Tools für das zu lösende Problem am besten geeignet sind. Viele vorhandene Computerbücher haben dieses Problem einfach nicht zufriedenstellend beantwortet. Ich fand heraus, dass wenn Sie zum Beispiel ein Buch über Cassandra lesen, es Ihnen sagen würde, warum Cassandra wunderbar ist, aber es würde Ihnen im Allgemeinen nichts über Dinge erzählen, für die es nicht gut passt. Was ich in diesem Buch wirklich tun wollte, war, die Hauptfragen zu identifizieren, die Sie sich stellen müssen, wenn Sie versuchen, eine Art Großsystem aufzubauen. Wenn Sie diese Fragen beantworten, können Sie herausfinden, welche Technologien für das jeweilige Problem, das Sie lösen möchten, geeignet und welche weniger geeignet sind - denn im Allgemeinen gibt es keine Technologie, die für alles perfekt ist. Das Buch versucht Ihnen dabei zu helfen, die Vor- und Nachteile verschiedener Technologien in verschiedenen Umgebungen herauszufinden.
Gesunder Menschenverstand gegen künstlichen Hype und aggressives Marketing
Vadim : In der Tat gibt es oft - wenn nicht immer - viele Technologien mit überlappenden Funktionen, Merkmalen und Datenmodellen. Und Sie können all diese Marketing-Schlagworte nicht glauben. Sie müssen die Whitepaper lesen, um die Interna zu lernen, und sogar versuchen, den Quellcode zu lesen, um zu verstehen, wie er genau funktioniert.
Martin : Und ich habe festgestellt, dass Sie oft zwischen den Zeilen lesen müssen, weil Ihnen die Dokumentation oft nicht wirklich sagt, wofür eine bestimmte Datenbank scheiße ist. Die Wahrheit ist, dass jede Datenbank an irgendeiner Art von Arbeitsbelastung leidet. Die Frage ist nur, welche sie sind. Ja, manchmal müssen Sie die Bereitstellungsrichtlinien für Ops-Mitarbeiter lesen und versuchen, die tatsächlichen Vorgänge auf dem System rückzuentwickeln.
Vadim : Glauben Sie nicht, dass der Branche das gemeinsame Vokabular oder eine Reihe von Kriterien fehlt, um verschiedene Lösungen für dasselbe Problem zu vergleichen? Ähnliche Dinge werden mit unterschiedlichen Namen bezeichnet, einige Dinge werden weggelassen, die immer klar und explizit angegeben werden sollten, wie Transaktionsgarantien. Was denkst du?
Martin : Ja, ich denke, ein Problem unserer Branche ist, dass oft, wenn Leute über ein bestimmtes Werkzeug sprechen, über alles viel Hype herrscht. Das ist verständlich, da die Tools von verschiedenen Unternehmen hergestellt werden und diese Unternehmen offensichtlich für ihre Produkte werben möchten. Daher werden diese Unternehmen Menschen zu Konferenzen schicken, um darüber zu sprechen, wie wunderbar ihr Produkt im Wesentlichen ist. Es wird als Tech-Talk getarnt, aber im Grunde ist es immer noch eine Verkaufsaktivität. Als Branche könnten wir wirklich ehrlicher mit den Vor- und Nachteilen einiger Produkte umgehen. Und ein Teil davon erfordert eine gemeinsame Terminologie, weil man sonst einfach nicht gleichberechtigt vergleichen kann. Über eine gemeinsame Terminologie hinaus brauchen wir jedoch Argumentationsmöglichkeiten für Dinge, in denen bestimmte Technologien gut oder schlecht sind.
Fallstricke des CAP-Theorems und anderer Branchenfehler
Vadim : Meine nächste Frage ist ziemlich kontrovers. Könnten Sie bitte einige wichtige Fehler in der Branche nennen, auf die Sie während Ihrer Karriere gestoßen sind? Vielleicht überbewertete Technologien oder weit verbreitete Lösungen, die wir schon vor langer Zeit hätten loswerden sollen? Es mag ein schlechtes Beispiel sein, aber vergleichen Sie JSON über HTTP / 1.1 mit dem viel effizienteren gRPC über HTTP / 2. Oder gibt es eine alternative Sichtweise?
Martin : Ich denke, in vielen Fällen gibt es sehr gute Gründe, warum eine Technologie das eine und nicht das andere tut. Daher zögere ich sehr, Dinge als Fehler zu bezeichnen, da es sich in den meisten Fällen um Kompromisse handelt. In Ihrem Beispiel von JSON über HTTP / 1.1 im Vergleich zu Protokollpuffern über HTTP / 2 gibt es meiner Meinung nach durchaus vernünftige Argumente für beide Seiten. Wenn Sie beispielsweise Protokollpuffer verwenden möchten, müssen Sie Ihr Schema definieren, und ein Schema kann eine wunderbare Sache sein, da es dabei hilft, genau zu dokumentieren, welche Kommunikation stattfindet. Einige Leute finden Schemata jedoch ärgerlich, insbesondere wenn sie sich in einem frühen Entwicklungsstadium befinden und die Datenformate sehr häufig ändern. Da haben Sie es also, es geht um Kompromisse. In einigen Situationen ist einer besser, in anderen ist der andere besser.
In Bezug auf tatsächliche Fehler, die ich für einfach schlecht halte, gibt es nur eine relativ kleine Anzahl von Dingen. Eine Meinung, die ich habe, ist, dass der CAP-Satz grundsätzlich schlecht und einfach nicht nützlich ist. Wenn Menschen den CAP-Satz verwenden, um Entwurfsentscheidungen zu rechtfertigen, denken sie oft, dass sie entweder falsch interpretieren, was CAP tatsächlich sagt, oder das Offensichtliche auf eine Art und Weise angeben. CAP als Theorem hat das Problem, dass es wirklich nur das Offensichtliche sagt. Darüber hinaus handelt es sich nur um ein sehr eng definiertes Konsistenzmodell, nämlich die Linearisierbarkeit, und ein sehr eng definiertes Verfügbarkeitsmodell: Sie möchten, dass jedes Replikat für Lese- und Schreibvorgänge vollständig verfügbar ist, auch wenn es nicht mit anderen Replikaten kommunizieren kann. Dies sind vernünftige Definitionen, aber sie sind sehr eng gefasst, und viele Anwendungen fallen einfach nicht in den Fall, dass genau diese Definition der Konsistenz oder genau diese Definition der Verfügbarkeit benötigt wird. Und für alle Anwendungen, die eine andere Definition dieser Wörter verwenden, sagt Ihnen der CAP-Satz überhaupt nichts. Es ist einfach eine leere Aussage. Ich denke, das ist ein Fehler.
Und während wir schimpfen, wenn Sie mich bitten, Fehler zu nennen, ist ein weiterer großer Fehler, den ich in der Technologiebranche sehe, der Abbau von Kryptowährungen, was ich für eine ungeheure Verschwendung von Elektrizität halte. Ich kann einfach nicht verstehen, warum die Leute das für eine gute Idee halten.
Vadim : In Bezug auf das CAP-Theorem sind viele Speichertechnologien tatsächlich abstimmbar, beispielsweise in Bezug auf AP oder CP. Sie können den Modus auswählen, in dem sie arbeiten.
Martin : Ja. Darüber hinaus gibt es viele Technologien, die nach der strengen Definition des GAP-Theorems weder konsistent noch verfügbar sind. Sie sind buchstäblich nur P! Nicht CP, nicht CA, nicht AP, nur P. Niemand sagt das, denn das würde schlecht aussehen, aber ehrlich gesagt könnte dies eine durchaus vernünftige Designentscheidung sein. Es gibt viele Systeme, für die das eigentlich völlig in Ordnung ist. Dies ist tatsächlich einer der Gründe, warum ich denke, dass CAP eine so wenig hilfreiche Art ist, über Dinge zu sprechen: weil es einen großen Teil des Designraums gibt, den es einfach nicht erfasst, wo es absolut vernünftige gute Designs für Software gibt, die es gibt erlaubt dir einfach nicht darüber zu reden.
Vorteile der Dezentralisierung
Vadim : Wenn Sie heute über datenintensive Anwendungen sprechen, welche anderen großen Herausforderungen, ungelösten Probleme oder aktuellen Forschungsthemen können Sie nennen? Soweit ich weiß, sind Sie ein wichtiger Befürworter der dezentralen Berechnung und Speicherung.
Martin : Ja. Eine der Thesen hinter meiner Forschung ist, dass wir uns im Moment zu sehr auf Server und Zentralisierung verlassen. Wenn Sie darüber nachdenken, wie das Internet ursprünglich zu dem Zeitpunkt entwickelt wurde, als es sich aus ARPANET entwickelte, war es als sehr belastbares Netzwerk gedacht, in dem Pakete über mehrere verschiedene Routen gesendet werden konnten und dennoch zum Ziel gelangen. Und wenn eine Atombombe eine bestimmte amerikanische Stadt treffen würde, würde der Rest des Netzwerks immer noch funktionieren, da er nur die ausgefallenen Teile des Systems umrunden würde. Dies war ein Entwurf des Kalten Krieges.
Und dann haben wir beschlossen, alles in die Cloud zu stellen, und jetzt muss im Grunde alles über eines der AWS-Rechenzentren wie us-east-1 irgendwo in Virginia gehen. Wir haben dieses Ideal, dezentral verschiedene Teile des Netzwerks dezentral nutzen zu können, aufgehoben und diese Server eingebaut, auf die sich alles stützt, und jetzt ist es extrem zentralisiert. Ich bin also an Dezentralisierung interessiert, in dem Sinne, dass ein Teil der Macht und Kontrolle über Daten von diesen Servern weg und zurück zu den Endbenutzern verlagert wird.
Eine Sache, die ich in diesem Zusammenhang hinzufügen möchte, ist, dass viele Leute, die über Dezentralisierung sprechen, über Dinge wie Kryptowährungen sprechen, weil sie auch eine Form der Dezentralisierung versuchen, bei der die Kontrolle von einer zentralen Behörde wie einer Bank in ein Netzwerk verlagert wird von kooperierenden Knoten. Aber das ist nicht wirklich die Art von Dezentralisierung, die mich interessiert: Ich finde, dass diese Kryptowährungen tatsächlich immer noch extrem zentralisiert sind, in dem Sinne, dass Sie eine Bitcoin-Transaktion im Bitcoin-Netzwerk durchführen müssen - Sie müssen das Netzwerk von Bitcoin verwenden, damit alles in diesem bestimmten Netzwerk zentralisiert ist. Die Art und Weise, wie es aufgebaut ist, ist dezentralisiert in dem Sinne, dass es keinen einzigen Steuerknoten hat, aber das Netzwerk als Ganzes ist extrem zentralisiert, da jede Transaktion, die Sie durchführen müssen, über dieses Netzwerk erfolgen muss. Sie können es nicht anders machen. Ich denke, dass es immer noch eine Form der Zentralisierung ist.
Im Fall einer Kryptowährung kann diese Zentralisierung unvermeidlich sein, da Sie beispielsweise doppelte Ausgaben vermeiden müssen. Dies ist ohne ein Netzwerk schwierig, das einen Konsens darüber erzielt, welche Transaktionen genau stattgefunden haben und welche nicht. Und genau das macht das Bitcoin-Netzwerk. Es gibt jedoch viele Anwendungen, für die keine Blockchain erforderlich ist, die tatsächlich mit einem viel flexibleren Datenmodell umgehen kann, das durch das System fließt. Und das ist die Art von dezentralem System, die mich am meisten interessiert.
Vadim : Könnten Sie bitte vielversprechende oder unterbewertete Technologien im Bereich dezentraler Systeme außer Blockchain nennen? Ich benutze IPFS seit einer Weile.
Martin : Für IPFS habe ich mich ein bisschen damit befasst, obwohl ich es selbst nicht benutzt habe. Wir haben einige Arbeiten mit dem
Dat- Projekt durchgeführt, das
IPFS in dem Sinne ähnlich ist, dass es auch eine dezentrale Speichertechnologie ist. Der Unterschied besteht darin, dass an IPFS
Filecoin , eine Kryptowährung, angehängt ist, um die Speicherressourcen zu bezahlen, während an Dat keine Blockchain angehängt ist. Es handelt sich lediglich um eine Möglichkeit, Daten auf mehreren Computern auf P2P-Weise zu replizieren.
Für das Projekt, an dem ich gearbeitet habe, war Dat eine gute Lösung, da wir eine Collaboration-Software erstellen wollten, in der mehrere verschiedene Benutzer jeweils ein Dokument oder eine Datenbank bearbeiten konnten und alle Änderungen an diesen Daten an jeden gesendet wurden sonst wer braucht eine Kopie dieser Daten. Wir können Dat verwenden, um diese Replikation auf P2P-Weise durchzuführen, und Dat kümmert sich um alle Dinge auf Netzwerkebene, wie z. B. NAT-Traversal und Durchlaufen von Firewalls - es ist ein ziemlich schwieriges Problem, nur die Pakete von einem Ende zum anderen zu bringen . Darüber hinaus haben wir mithilfe von CRDTs eine Ebene erstellt, mit der mehrere Personen ein Dokument oder einen Datensatz bearbeiten und diese Änderungen auf effiziente Weise austauschen können. Ich denke, Sie können diese Art von Dingen wahrscheinlich auch auf IPFS aufbauen: Sie können wahrscheinlich den Filecoin-Aspekt ignorieren und nur den P2P-Replikationsaspekt verwenden, und es wird wahrscheinlich genauso gut funktionieren.
Vadim : Sicher, obwohl die Verwendung von IPFS zu einer geringeren Reaktionsfähigkeit führen kann, da das zugrunde liegende WebRTC-Dat P2P-Knoten direkt verbindet und IPFS wie eine verteilte Hash-Tabelle funktioniert.
Martin : Nun, WebRTC befindet sich auf einer anderen Ebene des Stacks, da es hauptsächlich dazu gedacht ist, zwei Personen miteinander zu verbinden, die möglicherweise einen Videoanruf haben. Tatsächlich verwendet die Software, die wir derzeit für dieses Interview verwenden, möglicherweise WebRTC. Und WebRTC bietet Ihnen einen Datenkanal, über den Sie beliebige Binärdaten senden können. Darüber hinaus ist der Aufbau eines vollständigen Replikationssystems jedoch noch ein ziemlicher Arbeitsaufwand. Und das tun Dat oder IPFS bereits.
Sie haben die Reaktionsfähigkeit erwähnt - das ist sicherlich eine Sache, über die Sie nachdenken sollten. Angenommen, Sie möchten die nächsten Google Text & Tabellen dezentral erstellen. Bei Google Text & Tabellen ist die Einheit der Änderungen, die Sie vornehmen, ein einziger Tastendruck. Jeder einzelne Buchstabe, den Sie auf Ihrer Tastatur eingeben, wird möglicherweise in Echtzeit an Ihre Mitarbeiter gesendet. Dies ist im Hinblick auf eine schnelle Zusammenarbeit in Echtzeit hervorragend. Es bedeutet aber auch, dass sich beim Schreiben eines großen Dokuments möglicherweise Hunderttausende dieser Einzelzeichenbearbeitungen ansammeln, und viele dieser Technologien sind derzeit nicht sehr gut darin, diese Art von Bearbeitungsdaten zu komprimieren. Sie können alle Änderungen beibehalten, die Sie jemals an Ihrem Dokument vorgenommen haben, aber selbst wenn Sie nur hundert Bytes für jeden einzelnen Tastendruck senden und ein etwas größeres Dokument mit beispielsweise 100.000 Tastenanschlägen schreiben, sind Sie jetzt plötzlich Sie haben 10 MB Daten für ein Dokument, das normalerweise nur einige zehn Kilobyte groß ist. Wir haben also diesen enormen Aufwand für die Datenmenge, die gesendet werden muss, es sei denn, wir können Änderungen klüger komprimieren und verpacken.
Anstatt jemandem die vollständige Liste aller Zeichen zu senden, die jemals eingegeben wurden, senden wir möglicherweise nur den aktuellen Status des Dokuments und anschließend alle Aktualisierungen, die seitdem aufgetreten sind. Viele dieser Peer-to-Peer-Systeme haben jedoch noch keine Möglichkeit, diese Status-Snapshots so zu erstellen, dass sie effizient genug sind, um sie für Google Text & Tabellen zu verwenden. Dies ist eigentlich ein Bereich, an dem ich aktiv arbeite und versuche, bessere Algorithmen für die Synchronisierung verschiedener Benutzer für so etwas wie ein Textdokument zu finden, in dem wir nicht jeden einzelnen Tastendruck beibehalten möchten, da dies zu teuer wäre und wir möchten um die Netzwerkbandbreite effizienter zu nutzen.
Neue CRDTs. Formale Überprüfung mit Isabelle
Vadim : Haben Sie es geschafft, diese Tastendruckdaten erheblich zu komprimieren? Haben Sie neue CRDTs oder ähnliches erfunden?
Martin : Ja. Bisher haben wir nur Prototypen dafür, es ist noch nicht vollständig implementiert, und wir müssen noch einige Experimente durchführen, um zu messen, wie effizient es tatsächlich in der Praxis ist. Wir haben jedoch einige Komprimierungsschemata entwickelt, die sehr vielversprechend aussehen. In meinem Prototyp habe ich ihn von ungefähr 100 Bytes pro Bearbeitung auf ungefähr 1,7 Bytes Overhead pro Bearbeitung reduziert. Und das ist natürlich viel vernünftiger. Aber wie gesagt, diese Experimente dauern noch an und die Anzahl könnte sich noch leicht ändern. Aber ich denke, das Fazit ist, dass es dort noch viel Raum für Optimierungen gibt, so dass wir es noch viel besser machen können.
Vadim : Also darum geht es in Ihrem Vortrag auf der
Hydra-Konferenz , habe ich recht?
Martin : Ja genau. Ich werde eine kurze Einführung in den Bereich CRDTs, kollaborative Software und einige der Probleme geben, die in diesem Zusammenhang auftreten. Dann werde ich einige der Forschungen beschreiben, die wir in diesem Bereich durchgeführt haben. Es hat ziemlich viel Spaß gemacht, weil die Forschung, die wir durchgeführt haben, eine ganze Reihe verschiedener Anliegen betraf. Auf der sehr angewandten Seite haben wir eine JavaScript-Implementierung dieser Algorithmen, und wir verwenden diese, um echte Softwareteile zu erstellen, und versuchen, diese Software selbst zu verwenden, um zu sehen, wie sie sich verhält. Am anderen Ende des Spektrums haben wir mit formalen Methoden gearbeitet, um die Richtigkeit dieser Algorithmen zu beweisen, da einige dieser Algorithmen sehr subtil sind und wir sehr sicher sein möchten, dass die von uns hergestellten Systeme tatsächlich korrekt sind, d. H. Sie erreichen immer einen konsistenten Zustand. In der Vergangenheit gab es viele Algorithmen, die dies tatsächlich nicht geschafft haben, was einfach falsch war, das heißt, in bestimmten Randfällen blieben sie dauerhaft inkonsistent. Um diese Probleme zu vermeiden, die Algorithmen in der Vergangenheit hatten, haben wir formale Methoden verwendet, um die Richtigkeit unserer Algorithmen zu beweisen.
Vadim : Wow. Verwenden Sie wirklich Theorembeweiser wie Coq oder Isabelle oder irgendetwas anderes?
Martin : Genau dafür haben wir Isabelle benutzt.
Sie können an Martins Vortrag "Korrektheitsnachweise verteilter Systeme mit Isabelle" auf der The Strange Loop-Konferenz im September teilnehmen.
Vadim : Hört sich toll an! Werden diese Beweise veröffentlicht?
Martin : Ja, unsere ersten Beweise sind bereits öffentlich. Wir haben
das vor anderthalb Jahren veröffentlicht: Es war ein Framework zur Überprüfung von CRDTs, und wir haben drei bestimmte CRDTs innerhalb dieses Frameworks überprüft, von denen das wichtigste RGA (
Replicated Growable Array ) war, ein CRDT für die kollaborative Textbearbeitung. Es ist zwar nicht sehr kompliziert, aber ein ziemlich subtiler Algorithmus, und daher ist es ein guter Fall, in dem Beweise benötigt werden, da es nicht offensichtlich ist, dass es wirklich richtig ist. Und so gibt uns der Beweis die zusätzliche Gewissheit, dass es wirklich richtig ist. Unsere frühere Arbeit dort bestand darin, einige vorhandene CRDTs zu verifizieren, und unsere jüngste Arbeit in diesem Bereich befasst sich mit unseren eigenen CRDTs für neue Datenmodelle, die wir entwickelt haben, und dem Nachweis, dass unsere eigenen CRDTs korrekt sind.
Vadim : Wie viel größer ist der Beweis im Vergleich zur Beschreibung des Algorithmus? Weil es manchmal ein Problem sein kann.
Martin : Ja, das ist ein Problem - die Beweise sind oft viel Arbeit. Ich denke in unserem neuesten Beispiel ... Lassen Sie mich einen kurzen Blick auf den Code werfen. Die Beschreibung des Algorithmus und der Datenstrukturen umfasst etwa 60 Codezeilen. Es ist also ein ziemlich kleiner Algorithmus. Der Beweis ist über 800 Zeilen. Wir haben also ein Verhältnis von ungefähr 12: 1 zwischen dem Proof und dem Code. Und das ist leider ganz typisch. Der Beweis ist eine große Menge zusätzlicher Arbeit. Auf der anderen Seite haben wir, sobald wir den Beweis haben, sehr starke Gewissheit über die Richtigkeit des Algorithmus gewonnen. Darüber hinaus haben wir als Menschen den Algorithmus viel besser verstanden. Oft stelle ich fest, dass wir durch den Versuch, es zu formalisieren, das, was wir zu formalisieren versuchen, viel besser verstehen als zuvor. Und das an sich ist tatsächlich ein nützliches Ergebnis dieser Arbeit: Neben dem Beweis selbst gewinnen wir ein tieferes Verständnis, und das ist oft sehr hilfreich, um bessere Implementierungen zu schaffen.
Vadim : Könnten Sie bitte die Zielgruppe Ihres Vortrags beschreiben, wie hardcore wird es sein? Was ist das vorläufige Wissen, das Sie vom Publikum erwarten?
Martin : Ich mag es, meine Vorträge mit möglichst wenig Vorkenntnissen zugänglich zu machen, und ich versuche, alle auf das gleiche Niveau zu bringen. Ich decke viel Material ab, aber ich beginne bei einer niedrigen Basis. Ich würde erwarten, dass die Leute über allgemeine Erfahrungen mit verteilten Systemen verfügen: Wie können Sie Daten über ein Netzwerk mit TCP senden oder vielleicht eine ungefähre Vorstellung davon, wie Git funktioniert, was für diese Dinge ein recht gutes Modell ist. Aber das ist wirklich alles, was Sie brauchen. Dann ist es eigentlich nicht allzu schwierig, die Arbeit zu verstehen, die wir darüber hinaus geleistet haben. Ich erkläre alles anhand eines Beispiels und verwende Bilder, um alles zu veranschaulichen. Hoffentlich kann jeder mitmachen.
Event-Sourcing. Low-Level-Ansatz. XA-Transaktionen
Vadim : Hört sich wirklich toll an. Eigentlich haben wir etwas Zeit und ich möchte einen Ihrer
letzten Artikel über die Online-Ereignisverarbeitung diskutieren. Sie sind ein großartiger Befürworter der Idee des Event-Sourcing. Ist das richtig?
Martin : Ja sicher.
Vadim : Heutzutage gewinnt dieser Ansatz an Dynamik, und um alle Vorteile eines global geordneten Betriebsprotokolls zu nutzen, versuchen viele Ingenieure, ihn überall einzusetzen. Könnten Sie bitte einige Fälle beschreiben, in denen Event-Sourcing nicht die beste Option ist? Nur um seinen Missbrauch und mögliche Enttäuschungen mit dem Ansatz selbst zu verhindern.
Martin : Es gibt zwei verschiedene Schichten des Stapels, über die wir zuerst sprechen müssen. Event Sourcing, wie von Greg Young und einigen anderen vorgeschlagen, ist als Mechanismus für die Datenmodellierung gedacht, dh wenn Sie ein Datenbankschema haben und die Kontrolle darüber verlieren, weil es so viele verschiedene Tabellen gibt und diese Wenn alle Ereignisse durch unterschiedliche Transaktionen geändert werden, ist Event Sourcing eine Möglichkeit, dieses Datenmodell klarer zu gestalten, da die Ereignisse sehr direkt ausdrücken können, was auf Unternehmensebene geschieht. Welche Aktion hat der Benutzer ausgeführt? Die Konsequenzen dieser Aktion können dann darin bestehen, dass verschiedene Tabellen usw. aktualisiert werden. Mit Event Sourcing trennen Sie die Aktion (das Ereignis) effektiv von ihren Auswirkungen, die irgendwo stromabwärts auftreten.
Ich bin aus einem etwas anderen Blickwinkel in diesen Bereich gekommen, was eine untergeordnete Sichtweise der Verwendung von Systemen wie Kafka zum Erstellen hochskalierbarer Systeme darstellt. Diese Ansicht ist in dem Sinne ähnlich, dass Sie, wenn Sie etwas wie Kafka verwenden, Ereignisse verwenden, aber dies bedeutet nicht, dass Sie unbedingt Ereignisbeschaffung verwenden. Umgekehrt müssen Sie Kafka nicht verwenden, um Event-Sourcing durchzuführen. Sie können Event-Sourcing in einer regulären Datenbank durchführen oder eine spezielle Datenbank verwenden, die speziell für Event-Sourcing entwickelt wurde. Diese beiden Ideen sind also ähnlich, aber keine erfordert die andere, sie haben nur eine gewisse Überlappung.
Der Grund für die Verwendung eines Systems wie Kafka ist hauptsächlich das Argument der Skalierbarkeit: In diesem Fall gehen einfach so viele Daten ein, dass Sie sie nicht realistisch in einer Datenbank mit einem einzelnen Knoten verarbeiten können, sodass Sie sie in einige partitionieren müssen Wenn Sie ein Ereignisprotokoll wie Kafka verwenden, können Sie diese Arbeit auf mehrere Computer verteilen. Es bietet eine gute, prinzipielle Möglichkeit zur Skalierung von Systemen. Dies ist besonders nützlich, wenn Sie mehrere verschiedene Speichersysteme integrieren möchten. Wenn Sie beispielsweise nicht nur Ihre relationale Datenbank aktualisieren möchten, sondern beispielsweise auch einen Volltextsuchindex wie Elasticsearch oder ein Caching-System wie Memcached oder Redis oder ähnliches, und Sie möchten, dass ein Ereignis eine hat Wenn Sie den Effekt auf all diese verschiedenen Systeme aktualisieren, ist so etwas wie Kafka sehr nützlich.
In Bezug auf die von Ihnen gestellte Frage (in welchen Situationen würde ich diesen Event-Sourcing- oder Event-Log-Ansatz nicht verwenden) - Ich denke, es ist schwierig, genau zu sagen, aber als Faustregel würde ich sagen: Verwenden Sie das Einfachste . Das heißt, was der Domäne, die Sie implementieren möchten, am nächsten kommt. Wenn Sie also versuchen, eine relationale Datenbank, in die Sie nur einige Zeilen einfügen und aktualisieren und löschen, sehr gut zuzuordnen, verwenden Sie einfach eine relationale Datenbank und fügen Sie einige Zeilen ein und aktualisieren und löschen Sie sie. Es ist nichts Falsches daran, relationale Datenbanken so zu verwenden, wie sie sind. Sie haben lange Zeit gut für uns gearbeitet und tun dies auch weiterhin. Wenn Sie sich jedoch in einer Situation befinden, in der Sie wirklich Schwierigkeiten haben, diese Art von Datenbank zu verwenden, beispielsweise weil die Komplexität des Datenmodells außer Kontrolle gerät, ist es sinnvoll, auf so etwas wie eine Ereignisbeschaffung umzusteigen Ansatz.
Wenn Sie auf der unteren Ebene (Skalierbarkeit) die Größe Ihrer Daten so festlegen, dass Sie sie einfach auf einem einzelnen Computer in PostgreSQL einfügen können, ist dies wahrscheinlich in Ordnung. Verwenden Sie PostgreSQL einfach auf einem einzelnen Computer. Wenn Sie jedoch an einem Punkt angelangt sind, an dem eine einzelne Maschine Ihre Last nicht mehr bewältigen kann, müssen Sie über ein großes System skalieren. Dann ist es sinnvoll, sich mit verteilten Systemen wie Kafka zu befassen. Ich denke, das allgemeine Prinzip hier lautet: Verwenden Sie das, was für die jeweilige Aufgabe, die Sie lösen möchten, am einfachsten ist.
Vadim : Es ist wirklich ein guter Rat. Während sich Ihr System weiterentwickelt, können Sie die Entwicklungsrichtung, alle Abfragen, Muster und Datenflüsse nicht genau vorhersagen.
Martin : Genau und für solche Situationen sind relationale Datenbanken erstaunlich, weil sie sehr flexibel sind, insbesondere wenn Sie die JSON-Unterstützung einbeziehen, die sie jetzt haben. PostgreSQL unterstützt JSON jetzt ziemlich gut. Sie können einfach einen neuen Index hinzufügen, wenn Sie auf andere Weise abfragen möchten. Sie können einfach das Schema ändern und mit den Daten in einer anderen Struktur weiterarbeiten. Wenn also die Größe des Datensatzes nicht zu groß und die Komplexität nicht zu groß ist, funktionieren relationale Datenbanken gut und bieten ein hohes Maß an Flexibilität.
Vadim : Lassen Sie uns ein bisschen mehr über Event Sourcing sprechen. Sie haben ein interessantes Beispiel erwähnt, bei dem mehrere Verbraucher Ereignisse aus einer Warteschlange basierend auf Kafka oder ähnlichem konsumieren. Stellen Sie sich vor, dass neue Dokumente veröffentlicht werden und mehrere Systeme Ereignisse verbrauchen: ein auf Elasticsearch basierendes Suchsystem, das die Dokumente durchsuchbar macht, ein Caching-System, das sie in einen auf Memcached basierenden Schlüsselwert-Cache legt, und ein relationales Datenbanksystem, das einige aktualisiert Tabellen entsprechend. Ein Dokument kann ein Autoverkaufsangebot oder eine Immobilienanzeige sein. Alle diese verbrauchenden Systeme arbeiten gleichzeitig und gleichzeitig.
Martin : Ihre Frage ist also, wie Sie mit der Tatsache umgehen, dass bei mehreren Verbrauchern möglicherweise einige aktualisiert wurden, die anderen jedoch noch kein Update gesehen haben und immer noch leicht zurückbleiben.
Vadim : Ja genau. Ein Benutzer kommt auf Ihre Website, gibt eine Suchanfrage ein, erhält einige Suchergebnisse und klickt auf einen Link. Sie erhält jedoch den 404-HTTP-Statuscode, da die Datenbank keine solche Entität enthält, die das Dokument noch nicht verwenden und beibehalten konnte.
Martin : Ja, das ist eigentlich eine Herausforderung. Im Idealfall möchten Sie das, was wir als "kausale Konsistenz" zwischen diesen verschiedenen Speichersystemen bezeichnen würden. Wenn ein System einige Daten enthält, von denen Sie abhängig sind, enthalten die anderen Systeme, die Sie betrachten, auch diese Abhängigkeiten. Leider ist es sehr schwierig, diese Art von kausaler Konsistenz über verschiedene Speichertechnologien hinweg zusammenzustellen, und dies ist nicht wirklich die Schuld der Ereignisbeschaffung, da Sie unabhängig davon, welchen Ansatz oder welches System Sie verwenden, um die Aktualisierungen an die verschiedenen Systeme zu senden kann immer zu Problemen mit der Parallelität führen.
In your example of writing data to both Memcached and Elasticsearch, even if you try to do the writes to the two systems simultaneously you might have a little bit of network delay, which means that they arrive at slightly different times on those different systems, and get processed with slightly different timing. And so somebody who's reading across those two systems may see an inconsistent state. Now, there are some research projects that are at least working towards achieving that kind of causal consistency, but it's still difficult if you just want to use something like Elasticsearch or Memcached or so off the shelf.
A good solution here would be that you get presented, conceptually, with a consistent point-in-time snapshot across both the search index and the cache and the database. If you're working just within a relational database, you get something called snapshot isolation, and the point of snapshot isolation is that if you're reading from the database, it looks as though you've got your own private copy of the entire database. Anything you look at in the database, any data you query will be the state as of that point in time, according to the snapshot. So even if the data has afterwards been changed by another transaction, you will actually see the older data, because that older data forms part of a consistent snapshot.
And so now, in the case where you've got Elasticsearch and Memcached, really what you would ideally want is a consistent snapshot across these two systems. But unfortunately, neither Memcached nor Redis nor Elasticsearch have an efficient mechanism for making those kinds of snapshots that can be coordinated with different storage systems. Each storage system just thinks for itself and typically presents you the latest value of every key, and it doesn't have this facility for looking back and presenting a slightly older version of the data, because the most recent version of the data is not yet consistent.
I don't really have a good answer for what the solution would look like. I fear that the solution would require code changes to any of the storage systems that participate in this kind of thing. So it will require changes to Elasticsearch and to Redis and to Memcached and any other systems. And they would have to add some kind of mechanism for point-in-time snapshots that is cheap enough that you can be using it all the time, because you might be wanting the snapshot several times per second — it's not just a once-a-day snapshot, it's very fine-grained. And at the moment the underlying systems are not there in terms of being able to do these kinds of snapshots across different storage systems. It's a really interesting research topic. I'm hoping that somebody will work on it, but I haven't seen any really convincing answers to that problem yet so far.
Vadim : Yeah, we need some kind of shared
Multiversion Concurrency Control .
Martin : Exactly, like the distributed transaction systems. XA distributed transactions will get you some of the way there, but unfortunately XA, as it stands, is not really very well suited because it only works if you're using locking-based concurrency control. This means that if you read some data, you have to take a lock on it so that nobody can modify that data while you have that lock. And that kind of locking-based concurrency control has terrible performance, so no system actually uses that in practice nowadays. But if you don't have that locking then you don't get the necessary isolation behavior in a system like XA distributed transactions. So maybe what we need is a new protocol for distributed transactions that allows snapshot isolation as the isolation mechanism across different systems. But I don't think I've seen anything that implements that yet.
Vadim : Yes, I hope somebody is working on it.
Martin : Yes, it would be really important. Also in the context of microservices, for example: the way that people promote that you should build microservices is that each microservice has its own storage, its own database, and you don't have one service directly accessing the database of another service, because that would break the encapsulation of the service. Therefore, each service just manages its own data.
For example, you have a service for managing users, and it has a database for the users, and everyone else who wants to find out something about users has to go through the user service. From the point of view of encapsulation that is nice: you're hiding details of the database schema from the other services for example.
But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.
Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.
Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.
Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?
Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.
Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.
Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.
What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.
Vadim : It's a different point of view to building systems.
Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.
Professional growth and development
Vadim : Do you think that conferences like
Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.
Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to
think about the systems they are building.
Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?
Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.
So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.
Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?
Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.
A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people
interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.
Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.
Martin : No problem, yeah, it's been nice talking to you.
Vadim : Let's meet
at the conference .