Philip O'Toole blickt auf zwölf Jahre verteiltes SQLite zurück
Twelve Years of Distributed SQLite
Im September 2014 veröffentlichte Philip O'Toole rqlite, das erste Open-Source-System, das SQLite mit einem Raft-Log kombinierte. Heute gibt es ein Dutzend Projekte in dieser Kategorie, einige venture-finanziert, zwei übernommen. O'Toole zeichnet die Geschichte nach: von dqlite bei Canonical über Litestream und cr-sqlite bis zu Cloudflares D1 und Turso. Sein Fazit: Der Kern war richtig, der Designraum hat drei Ecken, und das Geld ging an die Plattformen.
Aber es lohnt sich festzuhalten, dass die Idee acht Jahre lang Open Source war, bevor jemand sie verkaufte.
- mmnfrdmcx
Als jemand, der sqlite und seine Einfachheit geliebt hat, stelle ich fest, dass es mit Agents extrem einfach ist, postgres zu verwalten, und es ist wirklich schön, alle SQL-Features von postgres zu haben – sqlite ist in vielen SQL-Bereichen ziemlich limitierend. Wenn du also über remote sqlite und all das nachdenkst, fühlt es sich besser an denn je, einfach einen Datenbankserver zu verwenden.
Natürlich ist sqlite großartig für lokale Tools usw.
- AgentME
Der Vergleich zwischen rqlite und Litestream war interessant. (rqlite verwendet einen Konsensalgorithmus zwischen den Knoten, um sie synchron zu halten und den primären Knoten wechseln zu können, während Litestream sich einfach selbst nach S3 synchronisiert, sodass ein anderer Knoten mit den Daten von dort übernehmen könnte.)
Ich hatte voll erwartet, dass der Artikel bald auf D1 eingehen und erwähnen würde, dass das ungefähr die gleiche Beziehung zwischen Cloudflare Durable Objects (auf denen D1 basiert) und celld ist, einer Open-Source-Neuimplementierung von Cloudflare Durable Objects, die nach S3 schreibt. Aber dann behandelt der Artikel D1 mit einem sehr plötzlichen Desinteresse und kommt damit nicht weiter.
- piterrro
Nachdem ich D1 in der Produktion verwendet habe – es ist nicht sehr zuverlässig. Es gab einen Kommentar auf HN von einem der D1-Entwickler [1], der sagte, dass D1 ein SQL-Wrapper auf Durable Objects ist, der die verteilte Natur von sqlite nachahmt.
> Ich verrate dir ein ziemlich schmutziges Geheimnis:
Es ist fast immer besser, Durable Objects Storage zu verwenden, statt D1. Selbst wenn du nur eine einzige globale Datenbank willst, ist es besser, das als singleton Durable Object zu implementieren, als D1 zu verwenden. Denn genau das ist D1 selbst: ein singleton Durable Object, das eine API für seine SQLite-Datenbank bereitstellt. Es ist nur ein Wrapper.
- vikrantrathore
Es ist lustig, als ich das Part-Time-Parliament-Paper (Paxos) las und dabei die Sprachen Zig und Odin lernte, habe ich eine reine Paxos-Bibliothek erstellt, und die erste Anwendung für diese Bibliothek war der Bau eines Multi-Master-sqlite. Die beiden Ansätze, die ich verfolgte, sind sehr unterschiedlich: In Zig habe ich zaxonlite (https://github.com/insanai/zaxonlite) gebaut und habe einen Benchmark dafür, der rqlite einschließt. Es verwendet WAL-Replikation als Strategie. Der zweite Versuch, den ich in Odin unternahm, ist sqlodin (https://github.com/insanai/sqlodin); in diesem verwendet das System kein WAL, sondern führt die SQL-Abfrage auf jedem Knoten aus, wodurch eine Teilmenge der SQL-Abfragen in sqlite nicht unterstützt wird.
- klamann
Wenn es dir keine Freude bereitet, über deine persönlichen Erfahrungen in deiner eigenen Stimme zu schreiben, warum solltest du dann überhaupt darüber schreiben?