cobalt
Un almacén clave-valor embebido de tipo LSM en Zig. Las escrituras recientes van a una skiplist respaldada por WAL, se vuelcan a SSTables inmutables y el espacio se recupera mediante leveled compaction.
Un almacén clave-valor LSM embebido en Zig. Las escrituras frescas aterrizan en una skiplist respaldada por un WAL, luego se vuelcan a SSTables inmutables, y el leveled compaction recupera el espacio. Es el cimiento sobre el que se apoyan las bases de datos modernas.
Introducción
Las bases de datos modernas que usas a diario casi siempre tienen la misma forma de motor por debajo. cobalt existe para que esa forma deje de ser una caja negra: implementa todo el camino de escritura LSM desde el log hasta la compaction, en Zig, un lenguaje que no te oculta ni un solo byte ni una asignación.
No es otra base de datos para producción sino un motor desmontado en piezas donde cada decisión es visible. Una vez que escribes tú mismo el WAL, la memtable, la SSTable y la compaction, RocksDB y Cassandra dejan de ser magia y se convierten en variantes familiares de la misma idea.
Por qué LSM y no un árbol B
Las bases clásicas escriben en el sitio, actualizando páginas de árbol B, lo que significa escrituras aleatorias por el disco. LSM va por el otro camino: cada escritura es un anexo. Los datos nuevos aterrizan en una estructura en memoria mientras las capas más antiguas yacen inmutables en el disco. Eso hace las escrituras rápidas y secuenciales, porque las escrituras secuenciales son justo lo que más le gusta a un disco.
El coste es claro y deliberado: los mismos datos pueden vivir en varios sitios a la vez y hay que fusionarlos después. Todo el arte del LSM consiste en pagar esa deuda en segundo plano sin frenar las escrituras que la crean.
El camino de escritura, paso a paso
una escritura toca primero el log, así que sobrevive a un apagón repentino antes de aterrizar en cualquier otro sitio.
los datos frescos se sientan en una estructura en memoria ordenada, listos para lecturas rápidas.
cuando la memoria se llena, la skiplist se vuelca a un fichero inmutable y ordenado en el disco.
el leveled compaction fusiona ficheros entre niveles, descarta versiones sobrescritas y recupera espacio.
El orden de estos pasos no es accidental. El WAL va primero precisamente porque garantiza la durabilidad antes de que los datos lleguen a la memoria volátil. Si el orden fuera al revés, un corte de corriente entre la escritura en memoria y el log significaría una pérdida silenciosa de datos.
La compaction es el corazón que distingue un LSM que funciona de uno que con el tiempo se ahoga. Sin ella los ficheros SSTable se apilan sin fin y una lectura tiene que revisar cada vez más capas. El leveled compaction los fusiona entre niveles, tirando por el camino las versiones sobrescritas y recuperando el espacio ocupado por datos muertos.
La misma forma de motor, WAL más memtable más SSTable más compaction, es lo que encuentras en RocksDB, LevelDB y Cassandra. La diferencia entre ellos es sobre todo el ajuste de las mismas piezas, no una arquitectura distinta.
El final de la caja negra
La mayor ganancia de cobalt no es el almacén en sí sino que las grandes bases de datos dejan de ser un misterio. Una vez que has recorrido todo el camino desde añadir al log hasta recuperar espacio en la compaction, sabes exactamente por qué LSM es rápido en escritura y dónde lo paga en lectura.
Las capas del motor y dónde viven también
| Capa | Rol | Dónde más |
|---|---|---|
| WAL | durabilidad de la escritura | toda base seria |
| Memtable (skiplist) | datos frescos en memoria | RocksDB, LevelDB |
| SSTable | ficheros inmutables en el disco | Cassandra, LevelDB |
| Compaction | recuperación de espacio, fusión | RocksDB, Cassandra |
Más proyectos
Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.
¿Tiene un proyecto similar?
Escríbenos - el presupuesto es gratuito y llega en una hora.



