Fase 1 — Núcleo (En curso)
Todo lo que hay en las secciones de formato de fichero, B+tree copy-on-write, free list, transacciones, índices secundarios, delete_range y cifrado de la especificación de diseño del motor. 4.000-6.000 líneas.
Criterios de salida:
Tests basados en propiedades e inyección de fallos en verde.
Como máximo 40 bytes por entrada de registro, medido con un millón de registros sintéticos.
Apertura de coste constante, verificada con ficheros de 30 KB y 2 GB.
Un benchmark comparativo frente a SQLite usando el esquema real de quota.
Fase 2 — RAM y CPU (Planificada)
Sin tocar el formato en disco. Unas 1.000 líneas: un filtro de Bloom en lugar del diccionario de interning, cierre por inactividad con reapertura de coste constante, vaciado diferido de agregados, un pool de páginas compartido entre bases de datos del mismo proceso, una caché limitada a nodos internos, y lecturas sin copia con un asignador arena por transacción.
Criterios de salida: 40 KB o menos por base de datos abierta en un nodo pro, 8 KB o menos en un nodo micro, amplificación de escritura de 1,2× o menos.
Fase 3 — Segmentos append-only (Condicional)
Sustituye el B+tree por segmentos secuenciales y un índice disperso, solo en el keyspace del log. Unas 700 líneas. Es la única fase que cambia la arquitectura del motor, y requiere un prototipo y mediciones antes de comprometerse con ella.
Fase 4 — Codificación columnar (Condicional)
Delta y bitpacking en timestamps, RLE en columnas de baja cardinalidad, frame-of-reference en latencias y tamaños, diccionario y bitpacking en identificadores internados, LZ4 sobre el bloque.
Criterios de salida: 13 bytes o menos por entrada de registro.
Requisito previo: confirmar que ningún flujo de quota necesita modificar un registro que ya se ha escrito.
Cifras esperadas por fase, nodo pro
| Fase | Disco | Amplificación de escritura | RAM por base de datos | | --- | --- | --- | --- | | 1 — núcleo | 46 MB | 2,1× | ~832 KB | | 2 — RAM y CPU | 46 MB | 1,1× | ~34 KB | | 3 — segmentos | 40 MB | ~1,0× | ~34 KB | | 4 — columnar | ~15 MB | ~1,0× | ~34 KB |
Proyecciones a partir del diseño, no mediciones.
Las cifras de disco son fiables con un margen del 10%. Las cifras de CPU son estimaciones de orden de magnitud, con un margen del 50%. Las cifras de RAM dependen por completo de cuántos usuarios distintos ve un nodo dentro de su ventana de retención.
Un servidor con 4.500 nodos micro o starter y 500 nodos pro: unos 640 MB de RAM tras la fase 1, unos 61 MB tras la fase 2 con todas las bases de datos abiertas, y unos 12 MB si el 95% están inactivos y cerrados.