Jepsen desmonta el «Full ACID» de ParticleDB: 96 fallos, incluida la pérdida de escrituras confirmadas
Jepsen: ParticleDB 1.1.4
Jepsen probó las versiones 1.1.4 a 1.1.18.11.rc-22 de ParticleDB, la base de datos multimodelo de Orkes para cargas de IA, y encontró 96 problemas: caídas, bloqueos, pérdida de datos, filas parcialmente invisibles que no se podían borrar, tablas eliminadas que reaparecían distorsionadas y strings convertidos en enteros. La mayoría aparecieron en un solo nodo, sin fallos y con un único cliente. Aunque casi todos se corrigieron, la base seguía perdiendo escrituras confirmadas en el modo `occ` y permitía anomalías internas y Lost Update incluso con `serializable`.
La mayoría de los problemas solo requerían un único servidor, un único cliente y ningún fallo.
- the_duke
¡Brutal!
> ParticleDB 1.1.4 afirmaba ser una base de datos compatible con Postgres... En cambio, encontramos una biblioteca de confusión
> exhibía frecuentes y profundas anomalías transaccionales en prácticamente todas las formas que pudimos medir. Observamos rutinariamente la pérdida de escrituras confirmadas, violaciones de consistencia interna, G1a (Lectura Abortada), G1b (Lectura Intermedia) y P4 (Actualización Perdida). En la carga de trabajo de append, los valores añadidos con éxito solían desaparecer de lecturas posteriores de una clave dada. Nuestra suite de pruebas infirió todo tipo de anomalías cíclicas, incluyendo G0, G1c, G-Single y G2-item, pero muchas de estas pueden atribuirse a problemas más básicos, como la pérdida de escrituras. Estos problemas ocurrían con un solo servidor y sin fallos, y afectaban a todos los modos de transacción, interfaces y modos de WAL probados
- amluto
He llegado a aprender una dicotomía interesante en el software:
Algunos softwares son correctos por construcción, en el sentido de que el diseño general tiene sentido y los casos que no funcionan son generalmente errores locales.
Algunos softwares son incorrectos por construcción, y tienden a funcionar por alguna combinación de suerte y de evitar cuidadosamente el diseño incorrecto en la mayoría o en todos los caminos de código que podrían exponer la incorrección. (La IA puede ser bastante efectiva para encontrar los lugares relevantes donde insertar soluciones alternativas).
ParticleDB suena como de la última categoría. Muchos proyectos grandes tienen porciones que están en una categoría y porciones que están en otra.
Aparte, durante el último día o dos, he estado contemplando que el manejo del pinning de folios en el kernel de Linux parece estar en la categoría de incorrecto por construcción. Buenos tiempos. No, no he encontrado un error difícil de arreglar que caracterizaría de manera creíble como un problema de seguridad o una probable corrupción accidental [0], pero esto parece mayormente suerte.
[0] Parece que he redescubierto un error que algún volcado masivo de Anthropic de hace un par de meses también encontró, y se está arreglando. Si tu aplicación hace E/S de io_uring "fixed" o ciertos tipos de iommu-based o quizás RDMA en un memfd, podrías encontrarlo plausiblemente en raras ocasiones. No me molesté en hacer un reproductor.
- tensegrist
> La página de inicio de ParticleDB anunciaba que ParticleDB estaba "formalmente probado" con una prueba TLA+. Sin embargo, durante nuestra colaboración no había ninguna especificación TLA+ disponible. No está claro qué propiedades podrían probarse, o si describían ParticleDB tal como se construyó.
- wofo
> Dada la gravedad y extensión de los errores de seguridad que encontramos, y el proceso que los produjo, Jepsen recomienda a los usuarios detener el despliegue adicional de ParticleDB y migrar a otras bases de datos lo antes posible. Considere verificar y/o reconstruir el estado de la base de datos a partir de fuentes más confiables, si están disponibles.
Supongo que eso es lo que pasa cuando vibecodeas una base de datos...
- edude03
> Presentamos 96 problemas en ParticleDB, que van desde lo pedestre (caídas, bloqueos mutuos, pérdida de datos, etc.) hasta lo picante (filas parcialmente invisibles que no se podían eliminar, WHERE 4 = 5, tablas eliminadas que reaparecen en formas distorsionadas, columnas confundidas, cadenas que se convierten en enteros, etc.).
Definitivamente parece peor de lo habitual (mirando atrás, la mayoría de las bases de datos parecen tener <10 problemas en total, y la mayoría parecen "leves") - dado que es una base de datos para IA, ¿también es probable que haya sido vibe-codeada o simplemente nueva? Aunque incluso si es nueva, no esperaría tantos problemas en una versión estable
- mxey
Es una locura lo malo que es. No sorprende para una base de datos vibe-codeada, pero ¿por qué contrataron a Kyle para una prueba, en lugar de hacer primero CUALQUIER prueba ellos mismos?
- eqvinox
> Las cadenas a veces se convertían en enteros de ocho bits (#37)
¡FINALMENTE sabemos qué pasó con las claves de eMudhra!
(Lo siento. Realmente no pude resistirme).
- t3ntxcles
Publicar un error como "WHERE 4 = 5" devolviendo filas lo dice todo para mí