TigerBeetle ist die interessanteste Datenbank der Welt
(amplifypartners.com)- Die Finanztransaktionsdatenbank TigerBeetle ist eine neue Datenbank mit nativer Unterstützung für Debit und Credit. Während bestehende SQL-Datenbanken für eine einzelne Transaktion 10–20 Abfragen benötigen, verarbeitet sie 8.190 Transaktionen in einem einzigen Roundtrip
- Während viele Systeme auf schnelles Coden und immer mehr Abhängigkeiten setzen, hält dieses Projekt an kontraintuitiven Strategien fest wie Code langsam schreiben, Deterministic Simulation Testing (DST) und Zero Dependencies
- Im Unterschied zu bestehenden OLTP-Datenbanken, die auf Single-Node-Architekturen beruhen, sind Distributed by default, Clock-Fault-Tolerance (Cluster Time) und Storage-Fault-Tolerance fest in das Design eingebaut; durch die Wahl von Viewstamped Replication und Zig wurden Einfachheit und Transparenz der Implementierung erreicht
- Mit der von NASAs Power of Ten inspirierten TigerStyle-Methodik werden strenge Coding-Standards eingehalten, darunter im Schnitt mehr als zwei Assertions pro Funktion, erzwungene statische Speicherzuweisung und aktivierte Assertions selbst in der Produktionsumgebung
- Die Architektur ist auf das Zeitalter der Hyper-Transaktionalisierung mit Echtzeitzahlungen, Gaming und Energieabrechnung ausgelegt, setzt einen neuen Maßstab für Performance und Genauigkeit im OLTP der nächsten Generation und entwickelt sich zu einem Transaktionsverarbeitungssystem der nächsten Generation, das 20–30 Jahre alte SQL-Datenbanken ersetzen kann
Warum eine auf Debit/Credit ausgerichtete Datenbank nötig ist
- TigerBeetle ist eine „Finanztransaktionsdatenbank“, die Debit und Credit als zentrale Primitive verwendet
- Das Wesen der Transaktion, wie Jim Gray es 1985 definierte, war keine SQL-Transaktion, sondern eine Business-Transaktion (Debit/Credit)
- Auch 20 Jahre später definierte Gray standardisierte Transaktionsverarbeitung als „DebitCredit“: ein Konto belasten, doppelte Buchführung ausführen und dann dem Terminal antworten
- Debit und Credit sind nicht nur für Buchhaltung oder Banken gedacht, sondern eine gemeinsame Sprache, die das Wesen von Transaktionen ausdrückt, und der Grund, warum Garantien wie ACID bereitgestellt werden
- Probleme bei der Umsetzung von Debit/Credit mit bestehenden SQL-Datenbanken
- Für einen einzelnen Debit/Credit-Vorgang sind 10–20 SQL-Abfragen nötig: Kontostand abrufen, Zeile sperren, auf Entscheidungslogik im Code warten, Debit/Credit protokollieren usw.
- Während der Netzwerk-Roundtrips müssen Zeilensperren gehalten werden, und das Hot-Row-Problem verschärft sich, wenn viele Transaktionen auf dasselbe „House Account“ zugreifen
- Durch sofortige Zahlungen mit zig Milliarden Vorgängen pro Monat in Indien und Brasilien, US FedNow sowie Echtzeitabrechnung in Energie, Gaming und Cloud ist die Welt innerhalb von zehn Jahren mindestens um drei Größenordnungen transaktionszentrierter geworden, doch die heute verwendeten SQL-Datenbanken basieren auf 20–30 Jahre alter Technik
- Wodurch sich TigerBeetle unterscheidet
- Debit und Credit sind als Primitive erster Klasse entworfen, sodass in einer einzelnen 1MiB-Abfrage 8.190 Transaktionen in einem Roundtrip verarbeitet werden können
- Gründer Joran nennt das eine „1000x-Performance-Idee“, sagt aber zugleich, es sei „nichts Besonderes“
- Normalerweise dauert der Bau einer Datenbank zehn Jahre, doch TigerBeetle war nach 3,5 Jahren fertig und bestand Jepsen-Tests
- Im Juni 2025 konnte Kyle Kingsbury die Grundlagen von TigerBeetle nicht brechen, obwohl er auf allen Maschinen an unterschiedlichsten Stellen Schäden verursachte; gefunden wurde nur ein einziger Korrektheitsfehler in der Read-Query-Engine, der die Haltbarkeit nicht betraf
Modernes Datenbankdesign
Verteilte Architektur als Standard
- Als Postgres und MySQL entstanden, dominierte das Single-Node-Paradigma, doch im heutigen Zeitalter gemeinsam genutzter Cloud-Hardware ist das verteilte Paradigma der Standard
- Moderne Datenbanken müssen strikte Serialisierbarkeit bieten und Transaktionen zwischen Maschinen replizieren, um Redundanz, Fehlertoleranz und hohe Verfügbarkeit sicherzustellen
- Einige der heute populärsten OLTP-Datenbanken verlassen sich noch immer stark auf Single-Node-Architekturen; teils ist automatisches Failover nicht standardmäßig integriert
- Das verteilte Design von TigerBeetle
- Es wurde von Grund auf verteilt gebaut: Man installiert einfach das Binary auf so vielen Maschinen im Cluster, wie man möchte
- Asynchrone Replikation, Zookeeper usw. sind nicht nötig; stattdessen wurde in die Umsetzung des wegweisenden Konsensprotokolls Viewstamped Replication vom MIT investiert
- Abgesehen von der Zig-Toolchain werden Zero Dependencies beibehalten, und in alle zentralen Abhängigkeiten wird direkt investiert
Toleranz gegenüber Uhrfehlern
- Für TigerBeetle als Transaktionsdatenbank ist die Genauigkeit physischer Zeitstempel für Audit und Compliance wichtig
- Unter Linux gibt es mehrere Uhren:
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - Wegen physischer Unvollkommenheit von Hardware-Uhren laufen Uhren mit unterschiedlicher Geschwindigkeit, was Drift-Fehler verursacht, die sich in kurzer Zeit zu Skew-Fehlern aufaddieren
- Normalerweise korrigiert NTP diese Fehler, aber wenn NTP bei partiellen Netzwerkausfällen stillschweigend ausfällt, kann ein hochverfügbarer Konsens-Cluster im Blindflug laufen
- Unter Linux gibt es mehrere Uhren:
- Umsetzung von Cluster Time
- Durch die Kombination der Mehrzahl der Uhren im Cluster wird eine fehlertolerante Uhr namens „Cluster Time“ gebildet
- Bei Bedarf wird die Systemzeit eines Servers neu ausgerichtet; wenn zu viele Uhren defekt sind, wird sicher heruntergefahren
- Es erkennt tatsächlich, wenn Chrony, PTP oder NTP nicht mehr funktionieren, und warnt Operatoren
- Versetzte Uhrzeiten zwischen Servern werden verfolgt und gesampelt, anschließend wird mit dem Marzullo-Algorithmus das genaueste Intervall geschätzt
Umgang mit Speicherfehlern
-
Annahmen bestehender Datenbanken
- Es wird angenommen, dass ein Datenträger bei einem Defekt vorhersehbar mit einer Fehlermeldung ausfällt
- In der SQLite-Dokumentation heißt es: „SQLite fügt der Datenbankdatei keine Redundanz hinzu, um Beschädigungen oder I/O-Fehler zu erkennen, und geht davon aus, dass gelesene Daten exakt den zuvor geschriebenen Daten entsprechen.“
-
Reale Szenarien bei Speicherfehlern
- Festplatten können stillschweigend beschädigte Daten zurückliefern, I/O in die falsche Richtung leiten (Lese-/Schreibpfad) oder als Gray Failure plötzlich langsam werden, ohne Fehlercode auszugeben
-
Die Speicherausfalltoleranz von TigerBeetle
- Mit Protocol Aware Recovery bleibt die Verfügbarkeit erhalten, solange nicht Datenkopien auf allen Replikaten beschädigt sind
- Alle Daten sind unveränderlich, und Checksummen sowie Hash-Chains geben starke Garantien gegen Beschädigung oder Manipulation
- Ein eigener Page Cache, Schreiben auf den Datenträger per
O_DIRECTund direkter Betrieb auf rohen Blockgeräten ohne Dateisystem minimieren die Schichten zwischen Datenträger und Software - Statt eines Standard-LSM wird ein selbst implementierter LSM Forest verwendet, bestehend aus etwa 20 LSM-Trees
- TigerBeetle behauptet Speicherausfalltoleranz nicht nur, sondern ist die einzige verteilte Datenbank, deren Eigenschaften in dieser Hinsicht durch Jepsen verifiziert wurden
- Selbst wenn auf einer lokalen Maschine nur ein einzelner Festplattensektor ausfällt, ist die Storage Engine mit dem globalen Konsens verbunden und heilt sich über den Cluster selbst
Warum die Programmiersprache Zig gewählt wurde
-
Die Sprachen bestehender Datenbanken
- Postgres ist in C geschrieben (1970er), MySQL in C und C++ (1979), MSSQL ebenfalls in C und C++
- Programmiersprachen haben sich in den letzten 40 Jahren stark weiterentwickelt; würde man heute modern bauen, kämen Rust oder Zig infrage
-
Warum TigerBeetle Zig gewählt hat
- Das gesamte C-Ökosystem kann genutzt werden, dazu kommen eine hervorragende Toolchain und ein starker Compiler
- Die Sprache ist leicht zu schreiben und besonders leicht zu lesen, in manchen Fällen so einfach wie TypeScript, aber viel schneller
- Statische Speicherallokation ist möglich, ein Kernprinzip von TigerBeetle
- Sehr gute Developer Experience und schnelle Lernbarkeit, wodurch der Einstieg in den TigerBeetle-Quellcode leichtfällt
- Frühere Rust-Teammitglieder wie Matklad (Schöpfer von Rust Analyzer) und Brian Anderson (Mitgründer von Rust zusammen mit Graydon) arbeiten bei TigerBeetle
- In Rust ohne dynamische Speicherallokation zu arbeiten ist „Hard Mode“, in Zig dagegen einfach
Deterministic Simulation Testing und VOPR
Grundkonzept von DST
-
Deterministic Simulation Testing (DST) ist eine innovative Testtechnik, die vom FoundationDB-Team (heute Teil von Apple) populär gemacht wurde
- Sie wird genutzt, um sicherere, fehlerärmere verteilte Datenbanken in kürzerer Zeit zu entwickeln als zuvor
- In verteilten Systemen gibt es unendlich viele Kombinationen von Nebenläufigkeitsproblemen: Nachrichtenverlust, unvorhersehbare Thread-Ausführungsreihenfolgen usw.
- Klassische Unit- und Integrationstests reichen nicht aus, und formale Verifikation ist teuer und langsam
-
Wie DST funktioniert
- Ein Simulator, der auf einer bestimmten Zeitlinie fast alle möglichen Szenarien deterministisch ausführt, denen ein System begegnen kann
- Dabei werden auch externe Faktoren wie OS-, Netzwerk- und Festplattenprobleme oder unterschiedliche Latenzen berücksichtigt
- Liefert in kurzer Zeit Tests über Jahre hinweg, da selbst die Zeit deterministisch wird und
while true-Schleifen möglich sind - Besonders gut geeignet für Datenbanken, die I/O-intensiv und nicht compute-intensiv sind
- Jepsen-Tests sind eine Teilmenge dessen, was DST leisten kann
VOPR von TigerBeetle
-
Überblick über VOPR (Viewstamped Operation Replicator)
- Ein selbst entwickelter Test-Cluster, benannt nach dem WOPR-Simulator aus dem Film WarGames
- TigerBeetle wird kontinuierlich unter zahllosen Bedingungen getestet, von Leader-Election bis zu individuellen Zustands- und Netzwerkausfällen
- Ein kompletter verteilter Cluster kann virtuell in einem einzigen Thread simuliert werden
-
Der Maßstab von VOPR
- Der größte DST-Cluster der Welt, betrieben auf 1.000 CPU-Kernen
- Hetzner schickte sogar eine spezielle E-Mail, um nachzufragen, ob wirklich so viele Kerne gewünscht seien
- VOPR-1000 läuft 24x7x365, um vor der Produktion selbst möglichst seltene Bedingungen einzufangen
- Im Simulator ist Zeit deterministisch abstrahiert und etwa 700-fach beschleunigt, sodass sich pro Tag rund 2.000 Jahre Simulationslaufzeit ansammeln
Gamification von DST
- TigerBeetle macht aus DST ein Spiel, in dem sich unterschiedliche Ausfallszenarien über die Systemreaktion durchspielen lassen
- Das Spiel ist unter sim.tigerbeetle.com spielbar
- Im Browser läuft eine echte VOPR-Instanz, die TigerBeetle simuliert
- Es wurde zu WebAssembly kompiliert, und TigerBeetle-Ingenieure bauten das Game-Frontend, um das reale System zu visualisieren
TigerStyle und Power of Ten
Die TigerStyle-Methodik
-
TigerStyle ist die Engineering-Methodik von TigerBeetle und öffentlich auf GitHub verfügbar
- „Ein sich entwickelnder kollektiver Austausch an der Schnittstelle von Engineering und Kunst, Zahlen und menschlicher Intuition, Vernunft und Erfahrung, ersten Prinzipien und Wissen, Präzision und Poesie“
- Sie übernimmt das Konzept „Biodigital Jazz“ aus dem Film Tron: Legacy: die Verflechtung menschlicher und digitaler Elemente, der chaotische und zugleich strukturierte Charakter des „Grid“ und der improvisierende Ausdruck menschlichen Potenzials innerhalb von Technologie
- Bei TigerBeetle ist es ein Code-Ethos, das nicht nur Wissenschaft, sondern auch Kunst einfließen lässt
-
Der Einfluss von TigerStyle
- Es formuliert Engineering- und Code-Prinzipien, die aus NASAs Prinzip für perfekten Code, Power of Ten, abgeleitet sind
- Behandelt Themen von Einfachheit und Eleganz bis hin zu praktischen Fragen wie Benennung
- Beginnt auch andere Unternehmen wie Resonate und Turso zu beeinflussen
- Wurde auch im Lex Fridman Podcast besprochen
Einsatz von Assertions
-
Regel 5 von Power of Ten: Assertion
- Das Konzept, Erwartungen an das Verhalten des Codes gleichzeitig explizit zu kodieren, nicht erst im Nachhinein
- Geschrieben als boolescher Ausdruck in einer einzigen Zeile: assert(a > b)
-
Die Assertion-Regeln von TigerStyle
- Assertions für alle Funktionsargumente, Rückgabewerte, Vorbedingungen und Invarianten, im Schnitt mindestens zwei Assertions pro Funktion
- Wenn eine Assertion wichtig und überraschend ist, wird sie statt eines Kommentars verwendet
- Beziehungen zwischen Konstanten zur Compile-Zeit werden mit Assertions geprüft, damit die Design-Integrität noch vor dem Programmstart validiert wird
- Nicht nur das Erwartete wird mit Assertions versehen, sondern auch der negative Raum dessen, was nicht erwartet wird — dort treten interessante Bugs auf
Denken über Performance
-
Wichtiger als das Schreiben von Code ist das Nachdenken über Code und Design
- Der beste Zeitpunkt, um Performance-Probleme zu lösen und gewaltige 1000x-Gewinne zu erzielen, ist die Designphase — genau der Zeitpunkt, an dem Messen oder Profiling nicht möglich ist
-
Die Performance-Prinzipien von TigerStyle
- Grundlegende Überschlagsrechnungen über die „vier Grundfarben“ (Netzwerk, Storage, Speicher, CPU) und die „zwei Texturen“ (Bandbreite und Latenz)
- Taktische Tipps wie die Trennung von Control Plane und Data Plane, das Batchen von Zugriffen und das Auslagern heißer Loops in eigenständige Funktionen, um Compiler-Abhängigkeiten zu verringern
Selbst ausprobieren
- TigerBeetle wendet moderne Forschung auf ein altes Format an und bietet beispiellose Performance- und Stabilitätsgarantien
- Eine moderne OLTP-Engine, die native Debit/Credit-Modellierung, Distributed by default, Toleranz gegenüber Storage- und Uhrfehlern sowie DST-basierte Qualitätssicherung kombiniert
- Entwickelt eine Kunstform für System- und Storage-Engineering und vergisst dabei den Spaß nicht
- Dank des intelligenten Einsatzes von DST wurde sie in nur wenigen Jahren auf Jepsen-Niveau aufgebaut
- Die Installation ist mit einem einzigen Binary einfach; mit dem einfachen Installationsskript auf der offiziellen Website kann man per
curlschnell loslegen und es selbst ausprobieren
6 Kommentare
Wenn man darüber nachdenkt, warum eine Datenbank keine verteilten Knoten verwendet, kann man verstehen, warum Postgres ein Single-Node-System ist
Überleg dir, was wichtiger ist als Performance
Hacker-News-Kommentare
TigerBeetle ist zwar großartig, aber man sollte wissen, dass dieser Artikel von einer Investmentfirma geschrieben wurde, die in TigerBeetle investiert hat relevanter Link
In den nächsten Monaten werden noch mehr solcher Posts von mir kommen, ich hoffe, die Leute diskutieren aktiver darüber, und ich frage mich, ob es besser wäre, oben einen Disclaimer hinzuzufügen; schwer wäre das nicht
Der Artikel ist auf der Website der Investmentfirma klar als „Portfolio Spotlight“ gekennzeichnet, also sollte man die Erwartungen entsprechend anpassen
Ich will die Schreibweise des Artikels nicht eigens kritisieren, aber dass er von einer Investmentfirma stammt, merkt man wirklich sehr leicht
Ich bin ein Fan von TigerBeetles Streben nach Korrektheit, den Coding-Praktiken und der hyper-spezialisierten Ausrichtung, aber ein paar Punkte im Post würde ich gern kritisieren
Die Erklärung zu Multi-Node ist etwas irreführend. Egal, was Cloud-Native-Leute sagen: Mit einer gut getunten einzelnen DB und einem Connection Pooler lässt sich schon eine enorme QPS verarbeiten. In meiner früheren Firma haben wir während Wartungsarbeiten aus Versehen den gesamten Traffic auf eine einzige MySQL-8-RDS-Instanz gelenkt, und selbst 80–90K QPS hat sie problemlos verarbeitet. Die Instanz war nicht einmal groß; Schema, Queries und ProxySQL/MySQL-Tuning waren einfach gut. Zu Spitzenzeiten schafften wir mit einem Writer und zwei Read Replicas auch locker 120K QPS
Wenn man node-local NVMe auf dem Server verwendet, stößt man wahrscheinlich eher an die CPU-Grenze
Beim Thema Redundanz gilt: Ein RDBMS, das für Netzwerkumgebungen entworfen wurde, hat letztlich immer Funktionen wie Failover und Hot Standby
TigerBeetles Consensus-System ist clever und kommt ohne externe Abhängigkeiten aus, versucht aber nicht, große Rows zu verarbeiten. Wenn man mit einem 1MiB-Paket auf einmal Tausende Transaktionen verarbeitet, kann man Dinge möglich machen, die mit einem traditionellen RDBMS nicht machbar wären
Diese Kritik soll ihre Leistung nicht schmälern; ich bin von diesem Produkt weiterhin sehr beeindruckt
Der Hinweis auf die Grenzen des Consensus-Protokolls trifft genau den Kern. TigerBeetle will gezielt nur transaktionsbezogene Aufgaben herauslösen und verarbeiten, nicht alle OLGP-dbs ersetzen. Die Idee ist, nur wichtige Daten in eine separate Transaktions-DB auszulagern. Einen ähnlichen Ansatz sieht man auch bei TurboPuffer
Dass moderne RDBMS schnell genug sind, stimmt, aber TigerBeetles Use Case ist die besondere Umgebung hoher Contention. Es wurde in echten Tests direkt nachgewiesen, dass der Gesamtdurchsatz eines Clusters dramatisch einbricht, wenn mehrere Transaktionen dasselbe Konto anfassen. (Siehe: relevanter HN-Kommentar)
Mir gefallen Joran und die Arbeit des Teams zu DST, Verständnis verteilter Systeme und Performance-Tests wirklich sehr, besonders die Besessenheit, Abhängigkeiten zu minimieren, ist beeindruckend (wobei man natürlich auch das OS als Abhängigkeit betrachten könnte)
Aber ich habe immer das Gefühl, dass ihr Umgang mit allgemeinem OLTP (das das Team OLGP nennt) unfair ist. Zum Beispiel vergleichen sie nur Low-Performance-SQL-Transaktionen, als wären Zeilensperren in Finanztransaktionen der einzige Fall, und beschreiben es dann so, als würde man noch an OLTP-Designs von vor 50 Jahren festhalten
Auf der offiziellen Performance-Seite lässt sich Contention nur bis auf 1 % senken. Ich glaube nicht, dass bei Unternehmen wie Stripe in ihrer OLTP-DB nur 1 % Contention vorliegt
Man kann Systeme bauen, die Contention vorhersagen, elegant damit umgehen und extremen Transaktionsdurchsatz erreichen. Solche Systeme schützen die DB vor Contention, sodass sie weiter skalieren kann. Die Durchsatzzahlen realer großer Zahlungssysteme liegen tatsächlich weit über den offiziellen Performance-Vergleichen
Das Marketing ignoriert solche Punkte meist und tut so, als würden alle Entwickler nur unbeholfene Transaktionen in die DB kippen, dabei sind die meisten in Wirklichkeit viel klügere Engineers. In der Zahlungsbranche gibt es sogar das Berufsbild des „payments engineer“
TigerBeetle ist großartig, aber dieses Marketingmuster, das andere OLTP-Systeme missverständlich darstellt, stört mich
Danke für das Lob
Sie sagten, in Stripes OLTP-DB lägen keine 1 % Contention vor, aber Stripe basiert auf MongoDB. Ein Vergleich mit einem RDBMS ist ein Vergleich von Äpfeln mit Birnen
Zur Frage, ob man das zugrunde liegende OS als Abhängigkeit sehen kann: Ich habe Erfahrung mit Systemen, die komplett in-memory laufen und sogar einen
kexecüberdauern. In Situationen, in denen man nicht einmal syscalls machen kann, kann auch das OS sehr wohl eine Abhängigkeit seinIch würde gern ein Beispiel dafür hören, wie man lock-basierte Transaktionen und einen optimierten Ansatz mit Bedingungsprüfungen zur Commit-Zeit umsetzt
Wir haben TigerBeetle in Betracht gezogen, aber es gab folgende Hürden
Wir nutzen Cloudflare Workers, aber die TigerBeetle-Client-App wird dort nicht unterstützt. Issue-Link Mit Cloudflare Containers könnte es vielleicht gehen, aber unser Workflow ist auf Workers ausgerichtet
Es gibt keine Auth-Funktion. Auf Servern (z. B. VPS) sind nur IP-Beschränkungen möglich, aber in serverlosen Umgebungen gibt es keine festen IPs relevantes Issue
Eine Lösung könnte auch sein, IPs über ECC-Keys mit Wireguard zu authentifizieren
Tatsächlich entsteht auch in Cloudflare-Workers- oder AWS-Lambda-Umgebungen ein Problem, wenn 1000 Worker alle gleichzeitig Verbindungen zur DB öffnen. Deshalb löst man das normalerweise mit einem Proxy oder einer Service-Schicht vor der DB. Der Proxy weiß, wie die DB angesprochen werden muss, daher spielt das Auth-Problem in einem privaten Netzwerk keine Rolle
Wenn man mit dem TigerBeetle-Solution-Team spricht, könnte man maßgeschneiderte Lösungen vorgeschlagen bekommen, etwa Authentifizierung auf logischer Ebene über End-to-End-Verschlüsselung
Ein DB-System ohne Auth im Jahr 2025 ist kaum zu glauben. Für eine Finanz-DB sollte auf der Website zumindest eine Anleitung stehen, wie man einen Auth-Proxy bzw. eine Auth-Schicht ergänzt. Wenn kein HTTP verwendet wird (aus der Doku ist das nicht eindeutig), wird sich jeder fragen, wie man ohne HTTP einen Auth-Proxy davorsetzt. In diesem Zustand wäre eine direkte Exponierung ins Internet extrem gefährlich
Es gab die Frage: „In 10 Jahren ist das Transaktionsvolumen um mehr als das 1000-Fache gestiegen, und die eingesetzte DB ist 20–30 Jahre altes SQL. Hält das durch?“ Ich denke: absolut ja.
Selbst 30 Jahre alte Software wurde laufend weiterentwickelt und basiert auf einem Fundament, das damals robust entworfen wurde
Hier ist Joran (TigerBeetle). Bei allgemeinen Workloads gibt es kein Problem, aber bei der Transaktionsverarbeitung entstehen durch Power-Law-Contention SQL-Row-Lock-Probleme (siehe Amdahl's Law). Wir haben auf der Website einen Contention Calculator veröffentlicht, mit dem sich theoretische Performance-Obergrenzen berechnen lassen contetion calculator
Auch DNS wurde 1983 veröffentlicht und ist bis heute ein Fundament des Internets. Wenn die Grundlagen stimmen, können Systeme, die älter als 30 Jahre sind, absolut tragfähig sein. SQL ist für die meisten Workloads völlig ausreichend
Neue und elegante Technologien sind nicht automatisch besser als bestehende, ausgiebig genutzte und bewährte Technik. Manchmal habe ich das Gefühl, Software Engineers seien die Engineers mit dem schlechtesten „Gedächtnis“ der Branche
Wenn man in verteilten Systemen mit Dutzenden DBs arbeitet, braucht man zwingend verteilte Transaktionen (Sagas usw.). In Single-Machine-Szenarien sind relationale DBs weiterhin hervorragend
Früher reichte die Hardware-Leistung nicht aus, aber heute hat sich die Technik so weit entwickelt, dass es im Gegenteil schneller und besser läuft
Auch FoundationDB hat in der TigerBeetle-Diskussion viele Gemeinsamkeiten
Langsames Schreiben von Code, DST, keine Abhängigkeiten, standardmäßig verteilte Produktionsumgebung, toleriert Uhrenabweichungen durch optimistisches Locking, harte Tests durch Jepsen, Tests in einer neuen Sprache (Flow) usw. Mit FDB kann man viele ähnliche Probleme ebenfalls lösen, und ich denke, TigerBeetle ist stärker auf seinen Use Case optimiert
Der einzige Grund, warum FDB nicht populär ist, liegt darin, dass es kaum gut gemachte Layer dafür gibt. Allerdings entwickeln einige Leute separat SQS-, DynamoDB- und SQLite-Layer
Der wahre Grund, warum FDB nicht populär ist, ist Apple. Nach dem Release 2013 mochte man das Produkt so sehr, dass die Firma aufgekauft wurde, und alle bestehenden Nutzer wurden abgeklemmt. Auch nach Ende der Exklusivität hat sich das Vertrauen nicht erholt
In Zusammenarbeit mit dem FDB-Team bereiten wir auch Posts zu DST vor
Mich würde interessieren, was nach der Übernahme passiert ist
Ich halte es buchstäblich für „the one true database“
Ich habe mich gefragt: „Warum nutzt nicht jeder Hyperscaler FDB?“, dann GitHub durchsucht und festgestellt, dass es letztlich bei Apple gelandet ist
Ich habe den jüngsten TigerBeetle-Entwicklungsstil zuletzt auf Rust, Go usw. angewendet und möchte ihn wirklich sehr empfehlen
Ein einzelner Entry Point, fast null Abhängigkeiten
CI lokal, Tests/Coverage/Lint usw. per Single Command
Es hat mein Interesse geweckt, Simulationen mit property-/snapshot-/swarm-Tests einzuführen
Trennung von schnell/langsam, alle Tests verwenden deterministisch einen Seed
Explizite upper bounds + Betrieb mit Resource Pools, selbst dynamische Allokation wird im Code leichter verständlich
Dank der Videos und Dokumentation des TB-Teams
Beeindruckend fand ich die Aussage: „Assertions bleiben in Production aktiviert“
Ich habe nie verstanden, warum man Assertions überhaupt abgeschaltet hat. Wenn ein Assert im Betrieb fehlschlägt, sollte man das sofort wissen (rhetorisch gemeint)
Historisch brachte das Abschalten von Assertions tatsächlich Performance-Vorteile. Heute machen ein paar zusätzliche Vergleiche aber kaum noch einen Unterschied
Ursprünglich sind Assertions Checks, die den Missbrauch von Entwickler-APIs verhindern sollen. Auf Ebene von User-Input ist es sinnvoller, das in Business-Logik mit ordentlichen Fehlermeldungen zu überführen
Manchmal möchte man auch Dinge per Assertion prüfen, die nicht leicht zu überprüfen sind. Zum Beispiel, ob eine Liste sortiert ist
Der eigentliche Zweck von Assertions sind Checks zur Compile-/Test-Zeit. Wenn man sie in Prod nutzen will, kann man sie in
if-Anweisungen umwandeln. Man sollte sich fragen, obassertnicht bloß bequemer syntaktischer Zucker istIch würde mir wünschen, dass das TB-Team das Double-Entry-Modell auch für andere Szenarien außerhalb des Finanzbereichs stärker bekannt macht. Auch bei Aktien, Konzerttickets usw. ist es sehr nützlich. Die API-Verbesserungen sind nun wohl weitgehend abgeschlossen, jetzt ist es an der Zeit zu zeigen, wie man es anwendet
Ich arbeite als Analyst und nutze viel SQL, bin aber kein Code-Entwickler. Die grobe Erklärung und die Performance-Vorteile verstehe ich im Wesentlichen. Ich hätte aber ein paar Fragen a) Wie sehen die Datenstrukturen in TigerBeetle tatsächlich aus? Vermutlich nicht in Form gewöhnlicher Tabellen b) Wie nutzt man es, wenn man keine SQL-Queries schreiben kann c) Wie würde das Double-Entry-Modell bei Aktien, Tickets usw. konkret aussehen? Wenn man zum Beispiel als Veranstalter 1000 Tickets besitzt und eines verkauft, wird das dann vom Inventar in Cash und von Deferred Revenue in Performance Obligation verbucht? Oder gibt es vor dem Ticketverkauf überhaupt keinen Eintrag?
Auch in Postgres lässt sich ein ähnliches Double-Entry-Modell umsetzen
Die Aussage „Die meisten Teams schreiben Code schnell, empfinden Tests als Qual und häufen Unmengen an Abhängigkeiten an“ war vor 25 Jahren eher Standard. Bevor Google und Facebook die Kultur „move fast and break things“ eingeführt haben, wurde eher überall akribisch langsam entwickelt und gut getestet. Ich hoffe, TigerBeetle bekommt mehr Anerkennung. Auch der Jepsen-Report ist lesenswert Jepsen report
Es wird interessant sein, 25 Jahre abzuwarten und zu sehen, ob TigerBeetle zum nächsten Google wird oder ob ein langsames, aber perfektes Produkt von schnelleren Wettbewerbern verdrängt wird
„Move fast and break things“ war das Motto von Facebook. Google war im Gegenteil geradezu testbesessen. Natürlich muss man sich an real existierende Anforderungen halten, und Engineers erzeugen oft zu viele hypothetische Anforderungen und damit Ineffizienz. Es ist viel wertvoller, ein Produkt schnell zu echten Nutzern zu bringen und deren Feedback einzuarbeiten, als es endlos „in der Blase“ weiter zu verfeinern
Unabhängig vom Inhalt des obigen Artikels ist auch die Website von TigerBeetle selbst ziemlich beeindruckend.
Sie vermittelt irgendwie das Gefühl, enorm schnell zu sein, und das Design wirkt interessant, weil es versucht, schwere Technik nicht zu schwer, sondern auf eine spielerische Weise zu vermitteln.
Link: https://tigerbeetle.com
Korrektur: Beim erneuten Ansehen wirkt es doch etwas schwer. Ästhetisch fand ich es aber trotzdem beeindruckend, daher teile ich es :)
Stimmt. Die Animation ist schnell und schafft dadurch einen Bildschirm, der nicht langweilig wirkt, ohne die Konzentration auf den Inhalt zu stören. Und sie vermittelt auch sehr stark den Eindruck, dass TigerBeetle extrem schnell ist, haha.
Ziemlich interessant.
Im Vergleich zu üblichen Websites sind die Animationszeiten deutlich kürzer eingestellt. So kann man das also auch angehen...