Sin fsync: FractalBits logra duplicar rendimiento en almacenamiento

Fuentes: Removing fsync from our local storage engine | FractalBits Blog
Sin fsync: FractalBits logra duplicar rendimiento en almacenamiento
Imagen generada con IA

FractalBits desarrolló un motor de almacenamiento clave-valor de un solo nodo que elimina completamente la llamada al sistema fsync del camino de escritura, logrando casi el doble de rendimiento que soluciones tradicionales con fsync. Este artículo explica cómo lo lograron.

La llamada fsync es costosa: típicamente toma entre cientos de microsegundos y varios milisegundos, y su latencia es impredecible porque no solo sincroniza los datos del archivo, sino también metadatos del sistema de archivos (inodos, entradas de directorio, mapas de extensión, y commits del journal). Un fsync que parece tocar solo unos pocos KB puede desencadenar un orden de magnitud más de E/S.

El diseño del motor se basa en tres pilares técnicos fundamentales. Primero, preasignación de archivos de tamaño fijo usando fallocate: tanto el área de datos como el journal se preasignan completamente al inicio y mantienen tamaños fijos. Como los archivos nunca crecen, el sistema de archivos nunca necesita actualizar el campo de tamaño del inodo, eliminando una fuente importante de metadatos que requerirían sincronización. Segundo, escrituras O_DIRECT: las escrituras van directamente al dispositivo de almacenamiento, omitiendo la caché de páginas del kernel y eliminando el estado intermedio de "datos sucios en memoria del kernel". Tercero, un journal alineado a la unidad de escritura atómica del SSD: el journal registra cambios en el índice y en el mapa de espacio (no los valores), con sus commits específicamente alineados para garantizar atomicidad ante pérdida de energía.

La arquitectura del motor tiene tres componentes: un índice Fractal ART que mapea claves a ubicaciones, un journal que es el límite de consistencia ante fallos, y un área de datos para los valores. El índice mantiene sus datos residentes en memoria y delega la persistencia al journal. El journal nunca modifica el tamaño de los archivos, solo sobrescribe registros en áreas preasignadas.

En benchmarks de escrituras aleatorias de 4KB en NVMe local de AWS i8g.2xlarge, el motor alcanzó 190.985 objetos por segundo, comparado con 116.041 del sistema ext4 con O_DIRECT y fsync. Este enfoque solo funciona bajo condiciones específicas: deployments en SSD/NVMe con caché protegida, un contrato de durabilidad más estrecho que la semántica POSIX, y un motor que controla completamente la asignación, journalización y recuperación.