Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration

Nezha es un almacén distribuido de clave-valor que integra la separación de claves y valores con el protocolo Raft para eliminar la sobrecarga de E/S causada por operaciones de persistencia superpuestas, logrando mejoras significativas en el rendimiento de lectura y escritura mientras mantiene garantías de consistencia fuerte.

Lo esencial

¡Hola! Imagina que estás gestionando una biblioteca gigante y muy popular donde millones de personas entran y salen cada segundo pidiendo libros (datos). El problema es que, en la biblioteca actual, el proceso para guardar un libro nuevo es tan lento y repetitivo que los libreros (los servidores) se agotan antes de poder atender a los clientes.

Este paper presenta a Nezha, un nuevo sistema para gestionar esta biblioteca que es mucho más rápido y eficiente. Aquí te explico cómo funciona usando analogías sencillas:

1. El Problema: La "Triple Copia" Inútil

Imagina que un cliente quiere guardar un libro nuevo en la biblioteca. En los sistemas tradicionales (como los que usan Raft, un protocolo muy común para asegurar que todos los libreros estén de acuerdo), el proceso es absurdo:

1. Primero, el librero escribe el libro en un cuaderno de registro (el log de Raft) para que nadie lo olvide.
2. Luego, lo escribe en un segundo cuaderno (el registro de la base de datos) por seguridad.
3. Finalmente, lo mueve a una tercera estantería (la base de datos final) para que esté ordenado.

El resultado: Para guardar una sola cosa, el librero tiene que escribir tres veces. Es como si tuvieras que fotocopiar un documento tres veces antes de guardarlo en el cajón. Esto llena los pasillos de la biblioteca de papel (sobrecarga de entrada/salida o I/O) y hace que todo sea lento.

2. La Solución de Nezha: Separar la "Etiqueta" del "Contenido"

Nezha introduce una idea brillante llamada Separación de Clave y Valor.

• La analogía: Imagina que en lugar de guardar el libro entero en la estantería principal, solo guardas una etiqueta (el título y la ubicación) en la estantería principal. El libro real (el contenido pesado) se guarda en un camión de carga (un archivo separado) que pasa por la puerta trasera.
• Cómo funciona:
  • Cuando alguien pide guardar un libro, Nezha solo escribe la etiqueta en el cuaderno de registro y en la estantería principal.
  • El libro pesado (el valor) se guarda una sola vez en el camión de carga.
  • El ahorro: En lugar de escribir el libro tres veces, solo se escribe una vez. ¡Es como si el librero dejara de hacer fotocopias innecesarias!

3. El Reto: ¿Cómo encontrar el libro si está en el camión?

Aquí surge un problema: Si solo tienes la etiqueta en la estantería, ¿cómo sabes dónde está el libro en el camión? Si tienes que buscar en el camión cada vez, podría ser lento.

Además, el camión se llena de libros viejos que ya nadie usa, y hay que limpiarlo (esto se llama Garbage Collection o recolección de basura). Si el librero se pone a limpiar mientras los clientes piden libros, la biblioteca se detiene.

4. La Magia de Nezha: El "Sistema de Tres Fases"

Nezha resuelve esto con un sistema de gestión inteligente que nunca detiene la biblioteca:

• Fase 1 (Antes de limpiar): Todo funciona normal. Los libros nuevos se guardan en el camión actual.
• Fase 2 (Durante la limpieza): ¡Aquí está la genialidad! Cuando el camión necesita limpieza, Nezha no para el tráfico. Abre un segundo camión nuevo (New Storage).
  • Los libros nuevos entran en el camión nuevo.
  • Mientras tanto, un equipo de limpieza ordena el camión viejo en silencio, separando los libros por orden alfabético y creando un índice rápido (como un mapa del tesoro).
  • Los clientes pueden pedir libros en ambos camiones al mismo tiempo sin que nadie se dé cuenta.
• Fase 3 (Después de limpiar): Una vez que el camión viejo está ordenado y limpio, se convierte en el nuevo "camión principal" y se cierra el viejo. El sistema cambia de uno a otro instantáneamente.

5. ¿Por qué es tan rápido? (Los Resultados)

Gracias a esta arquitectura, Nezha logra cosas increíbles:

• Para escribir (Guardar): Es 460% más rápido. Al no tener que escribir el libro tres veces, los libreros trabajan a la velocidad de la luz.
• Para leer (Buscar): Es 12.5% más rápido. Aunque antes era lento buscar en el camión, el nuevo sistema de índices y ordenamiento hace que encontrar el libro sea instantáneo.
• Para escanear (Buscar muchos libros seguidos): Es 72% más rápido. Como los libros en el camión limpio están ordenados alfabéticamente, puedes pasar la mano por la estantería y sacar todos los libros de "A" a "Z" muy rápido, en lugar de tener que buscar uno por uno en desorden.

En Resumen

Nezha es como una biblioteca que aprendió a:

1. No hacer fotocopias innecesarias (guardando el libro pesado solo una vez).
2. Usar un sistema de etiquetas para saber dónde está todo.
3. Limpiar y ordenar los estantes mientras los clientes siguen comprando, sin cerrar la puerta ni un segundo.

Esto permite que las aplicaciones modernas (como redes sociales, comercio electrónico o inteligencia artificial) manejen cantidades masivas de datos de forma mucho más rápida y eficiente, ahorrando dinero y energía al mismo tiempo.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration", presentado en español:

1. El Problema: Redundancia de E/S en Almacenamiento Distribuido

El artículo identifica un cuello de botella crítico en los sistemas de almacenamiento de clave-valor distribuidos que utilizan el protocolo de consenso Raft junto con motores de almacenamiento basados en LSM-tree (como RocksDB).

• Sobrecarga de Escritura Redundante: En las implementaciones tradicionales, cada operación de escritura (Put) requiere al menos tres escrituras en disco distintas para garantizar la durabilidad y consistencia:
  1. Persistencia del registro en el Log de Raft.
  2. Escritura en el WAL (Write-Ahead Log) del motor de almacenamiento (LSM-tree).
  3. Persistencia de la Memtable hacia archivos SSTable (Sorted String Tables).
• Amplificación de Escritura: Además, el proceso de compaction (compactación) del LSM-tree reescribe los datos múltiples veces, aumentando aún más la amplificación de escritura y reduciendo la eficiencia del almacenamiento.
• Impacto: Esta redundancia genera una sobrecarga significativa de I/O, limitando el rendimiento (throughput) y aumentando la latencia, especialmente en entornos modernos con discos NVMe de alto rendimiento donde la ineficiencia de software se convierte en el nuevo cuello de botella.

2. Metodología: Arquitectura Nezha

Para abordar este problema, los autores proponen Nezha, un sistema de almacenamiento distribuido que integra innovadoramente la separación de clave-valor con el protocolo Raft. La arquitectura se basa en tres pilares principales:

A. KVS-Raft (Consenso Optimizado)

Nezha redefine la estrategia de persistencia a nivel de operación mediante un nuevo protocolo llamado KVS-Raft:

• Separación de Datos: En lugar de almacenar los valores completos en el estado de la máquina y en múltiples logs, el sistema almacena solo los valores en el Log de Raft (ValueLog).
• Mecanismo de Offset: El motor de almacenamiento (basado en RocksDB) solo guarda claves y punteros de desplazamiento (offsets) hacia los valores en el ValueLog.
• Reducción de Escrituras: Esto unifica la persistencia del valor con la replicación del log. En lugar de escribir el valor tres veces, se escribe una sola vez en el ValueLog. El estado de la máquina se actualiza solo con el offset ligero, reduciendo drásticamente el I/O y el espacio en disco.

B. Marco de Recolección de Basura (GC) Consciente de Raft

La separación de clave-valor introduce un desafío: los valores en el ValueLog se vuelven desordenados y dispersos, lo que degrada el rendimiento de las lecturas (Get y Scan). Nezha soluciona esto con un framework de GC (Garbage Collection) consciente de Raft:

• Gestión de Archivos: Utiliza archivos de log no ordenados (para escrituras nuevas) y archivos de log ordenados (para datos compactados).
• Índices Eficientes: Construye estructuras de índices (como hashes) sobre los datos ordenados para acelerar las búsquedas.
• Seguridad: El GC está diseñado para no violar las propiedades de seguridad de Raft (orden y completitud del log), permitiendo la recuperación de nodos y la consistencia fuerte.

C. Mecanismo de Procesamiento de Solicitudes en Tres Fases

Para garantizar la corrección durante el proceso de GC sin interrumpir el servicio, Nezha implementa un mecanismo de tres fases:

1. Pre-GC: El sistema opera normalmente en el almacenamiento activo.
2. Durante-GC: Se crea un nuevo módulo de almacenamiento (New Storage) para manejar nuevas solicitudes. Las lecturas consultan en paralelo tanto el almacenamiento nuevo como el antiguo para encontrar la versión más reciente de los datos.
3. Post-GC: Una vez completada la compactación, los datos ordenados se mueven a un almacenamiento final (Final Compacted Storage) y el almacenamiento antiguo se elimina.

3. Contribuciones Clave

1. Identificación del Cuello de Botella: Demostración de que la persistencia redundante entre el protocolo de consenso y el motor de almacenamiento es un problema de rendimiento evitable en hardware moderno.
2. Diseño de KVS-Raft: Un protocolo de consenso que integra nativamente la separación de clave-valor, reduciendo las escrituras de valores de al menos tres a una sola vez, manteniendo la consistencia fuerte.
3. Framework GC Adaptativo: Un mecanismo de recolección de basura que equilibra el rendimiento de lectura y escritura, reorganizando los datos dispersos en archivos ordenados con índices eficientes.
4. Mecanismo de Tres Fases: Una estrategia robusta para manejar solicitudes concurrentes durante la reorganización de datos, asegurando disponibilidad y consistencia.

4. Resultados Experimentales

Los autores implementaron Nezha en Go y lo evaluaron comparándolo con sistemas como TiKV, RocksDB estándar, PASV y LSM-Raft. Los resultados mostraron mejoras significativas:

• Operaciones Put (Escritura): Mejora de rendimiento del 460.2% en promedio. Esto se debe a la eliminación de la amplificación de escritura redundante.
• Operaciones Get (Lectura de punto): Mejora del 12.5%. Aunque la separación de clave-valor suele penalizar las lecturas, el índice hash y la organización de datos de Nezha compensaron esta desventaja, superando a sistemas sin GC optimizado.
• Operaciones Scan (Lectura de rango): Mejora del 72.6%. La reorganización de datos en archivos ordenados permitió lecturas secuenciales eficientes, evitando el I/O aleatorio típico de la separación de clave-valor no optimizada.
• Escalabilidad: Nezha demostró una escalabilidad superior al aumentar el tamaño del clúster (de 3 a 7 nodos), manteniendo un rendimiento 3.5x a 5.3x superior a las implementaciones tradicionales.
• Recuperación: El tiempo de recuperación tras fallos se redujo en un ~34% debido a la menor cantidad de datos que deben ser recuperados desde el disco (solo offsets en RocksDB).

5. Significado e Impacto

El trabajo de Nezha es significativo porque:

• Rompe el Paradigma de Capas: Demuestra que la co-diseño profundo entre el protocolo de consenso y el motor de almacenamiento es esencial para el rendimiento en la era de los discos NVMe y la nube.
• Eficiencia de Costos: Al reducir drásticamente las escrituras redundantes, no solo mejora el rendimiento, sino que reduce los costos de almacenamiento y ancho de banda en entornos de nube con facturación por uso.
• Consistencia sin Sacrificio: Logra estas optimizaciones sin comprometer las garantías de seguridad y consistencia fuerte de Raft, lo cual es crítico para aplicaciones financieras y de infraestructura crítica.
• Solución Integral: A diferencia de trabajos anteriores que solo optimizan el lado de los seguidores o eliminan un solo log, Nezha aborda la redundancia en todo el clúster (líder y seguidores) y resuelve tanto los problemas de escritura como los de lectura.

En resumen, Nezha representa un avance importante en la arquitectura de bases de datos distribuidas, ofreciendo una solución práctica para eliminar la sobrecarga de I/O inherente a las implementaciones actuales de sistemas consistentes.