Jepsen zerlegt ParticleDB: 96 Fehler trotz „Full ACID“
Jepsen: ParticleDB 1.1.4
Jepsen hat ParticleDB, eine Multi-Model-Datenbank für KI-Workloads von Orkes, in den Versionen 1.1.4 bis 1.1.18.11.rc-22 getestet und 96 Probleme gefunden – von Abstürzen und Datenverlust bis zu unsichtbaren Zeilen und verlorenen Tabellen. Die meisten traten auf einem einzelnen Server ohne Fehlerinjektion auf. Selbst im stärksten Modus gingen committete Schreibvorgänge verloren. Orkes hat inzwischen Version 1.1.19-rc.13 veröffentlicht und behauptet, alle Probleme behoben zu haben.
ParticleDB verlor weiterhin committete Schreibvorgänge während des Normalbetriebs mit dem Standard-Transaktionsmodus `occ` und erlaubte interne Anomalien sowie Lost Update mit `serializable`, der stärksten Einstellung.
- the_duke
Brutal!
> ParticleDB 1.1.4 gab an, eine Postgres-kompatible Datenbank zu sein ... Stattdessen fanden wir eine Bibliothek der Verwirrung
> zeigte häufig tiefgreifende transaktionale Anomalien in praktisch jeder messbaren Hinsicht. Wir beobachteten regelmäßig den Verlust von committeten Schreibvorgängen, interne Konsistenzverletzungen, G1a (Aborted Read), G1b (Intermediate Read) und P4 (Lost Update). In der Append-Workload verschwanden erfolgreich angehängte Werte regelmäßig aus späteren Lesezugriffen auf einen bestimmten Schlüssel. Unsere Testsuite leitete jede Art von zyklischer Anomalie ab, einschließlich G0, G1c, G-Single und G2-item, aber viele davon lassen sich auf grundlegendere Probleme wie Schreibverlust zurückführen. Diese Probleme traten mit einem einzigen Server und ohne Fehler auf und betrafen jeden getesteten Transaktionsmodus, jede Schnittstelle und jeden WAL-Modus.
- amluto
Ich habe eine interessante Dichotomie in der Software kennengelernt:
Manche Software ist von der Konstruktion her korrekt, in dem Sinne, dass das Gesamtdesign sinnvoll ist und die Fälle, die nicht funktionieren, im Allgemeinen lokale Bugs sind.
Manche Software ist von der Konstruktion her inkorrekt und funktioniert tendenziell durch eine Kombination aus Glück und sorgfältiger Umgehung des inkorrekten Designs in den meisten oder allen Codepfaden, die die Inkorrektheit aufdecken könnten. (KI kann recht effektiv darin sein, die relevanten Stellen zu finden, an denen Workarounds eingefügt werden müssen.)
ParticleDB klingt nach der letzteren Kategorie. Viele große Projekte haben Teile, die in die eine Kategorie fallen, und Teile, die in eine andere fallen.
Nebenbei bemerkt: In den letzten ein oder zwei Tagen habe ich darüber nachgedacht, dass die Handhabung von Folio-Pinning im Linux-Kernel zur Kategorie „von der Konstruktion her inkorrekt“ zu gehören scheint. Schöne Zeiten. Nein, ich habe keinen schwer zu behebenden Bug gefunden, den ich glaubwürdig als Sicherheits- oder wahrscheinliches versehentliches Korruptionsproblem bezeichnen würde [0], aber das scheint größtenteils Glück zu sein.
[0] Ich scheine einen Bug wiederentdeckt zu haben, den auch ein massiver Anthropic-Dump von vor ein paar Monaten gefunden hat, und er wird gerade behoben. Wenn Ihre Anwendung „fixed“ io_uring-I/O oder bestimmte Arten von iommu-basiertem oder vielleicht RDMA auf einem memfd verwendet, könnten Sie ihn plausibel bei seltenen Gelegenheiten antreffen. Ich habe mir nicht die Mühe gemacht, einen Reproducer zu erstellen.
- tensegrist
> Die Homepage von ParticleDB warb damit, dass ParticleDB mit einem TLA+-Beweis „formal bewiesen“ sei. Während unserer Zusammenarbeit war jedoch keine TLA+-Spezifikation verfügbar. Es ist unklar, welche Eigenschaften bewiesen sein könnten oder ob sie ParticleDB so beschrieben, wie es gebaut wurde.
- wofo
> Angesichts der Schwere und des Ausmaßes der von uns gefundenen Sicherheitsfehler und des Prozesses, der sie hervorgebracht hat, empfiehlt Jepsen den Nutzern, den weiteren Einsatz von ParticleDB einzustellen und so bald wie möglich auf andere Datenbanken zu migrieren. Erwägen Sie, den Datenbankzustand aus zuverlässigeren Quellen zu überprüfen und/oder neu aufzubauen, falls verfügbar.
Ich schätze, das passiert, wenn man eine Datenbank vibecodet ...
- edude03
> Wir präsentieren 96 Probleme in ParticleDB, von den alltäglichen (Abstürze, Deadlocks, Datenverlust usw.) bis zu den pikanten (teilweise unsichtbare Zeilen, die nicht gelöscht werden konnten, WHERE 4 = 5, gelöschte Tabellen, die in verzerrter Form wieder auftauchen, verwirrte Spalten, Zeichenketten, die sich in Ganzzahlen verwandeln, und so weiter).
Definitiv scheint es schlimmer als üblich zu sein (wenn ich zurückblicke, scheinen die meisten Datenbanken insgesamt <10 Probleme zu haben, und die Mehrheit scheint „mild“ zu sein) – da es eine Datenbank für KI ist, war sie wahrscheinlich auch vibe-coded oder einfach nur neu? Andererseits würde ich selbst bei Neuheit nicht so viele Probleme in einer stabilen Version erwarten.
- mxey
Es ist der Wahnsinn, wie schlecht es ist. Nicht überraschend für eine vibecodete Datenbank, aber warum haben sie Kyle für einen Test engagiert, anstatt vorher IRGENDWELCHE Tests selbst durchzuführen?
- eqvinox
> Zeichenketten verwandelten sich manchmal in Acht-Bit-Ganzzahlen (#37)
ENDLICH wissen wir, was mit eMudhras Schlüsseln passiert ist!
(Entschuldigung. Ich konnte wirklich nicht widerstehen.)
- t3ntxcles
Einen Bug wie „WHERE 4 = 5“ auszuliefern, der Zeilen zurückgibt, sagt für mich alles.