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

Il paper presenta Nezha, un archivio distribuito chiave-valore che risolve le sovrapposizioni di I/O tra il protocollo di consenso Raft e i motori di storage integrando la separazione chiave-valore e una raccolta spazzatura a livelli, ottenendo così significativi miglioramenti nelle prestazioni di throughput mantenendo la coerenza forte.

L'essenziale

Ecco una spiegazione semplice e creativa del paper su Nezha, pensata per chiunque, anche senza un background tecnico.

Immagina di dover gestire una biblioteca gigantesca e caotica dove migliaia di persone scrivono e leggono libri ogni secondo. Questa è la sfida dei database distribuiti (come quelli che usano Amazon, Netflix o i social network).

Il Problema: Il "Doppio Lavoro" Inutile

Nel mondo attuale, per garantire che i dati non vadano persi (se un server si rompe, i dati devono essere salvati), i sistemi usano due cose:

1. Un "Diario di Bordo" (Raft): Ogni volta che qualcuno scrive qualcosa, il sistema lo scrive su un diario per assicurarsi che tutti i membri del team siano d'accordo.
2. Un Archivio (LSM-tree): Poi, il sistema prende quel dato e lo archivia fisicamente nel magazzino dei dati.

Il problema è che fanno un doppio lavoro inutile.
Immagina di dover spedire un pacco pesante (i dati).

• Prima lo metti in una scatola di sicurezza (il Diario di Bordo).
• Poi lo prendi, lo sballi e lo rimetti in un'altra scatola per l'archivio (l'Archivio).
• E spesso, per sicurezza, ne fai una terza copia.

In termini tecnici, questo significa che il disco rigido deve scrivere gli stessi dati tre volte. È come se un corriere dovesse portare lo stesso pacco tre volte allo stesso indirizzo solo per assicurarsi che arrivi. Con i dati moderni che sono enormi (come video o immagini), questo crea un collo di bottiglia: il sistema è lento perché passa troppo tempo a scrivere su disco invece che a lavorare.

La Soluzione: Nezha, il "Corriere Intelligente"

Gli autori hanno creato Nezha (il nome di un eroe mitologico cinese, simbolo di velocità e potere) per risolvere questo problema. L'idea geniale è separare il "titolo" del libro dal "libro" stesso.

Ecco come funziona Nezha con un'analogia semplice:

1. Separazione Chiave-Valore (Il Biglietto e il Pacco)

Invece di scrivere il pacco intero tre volte, Nezha fa così:

• Nel Diario di Bordo (Raft), scrive solo il pacco intero una volta sola.
• Nell'Archivio (il database), scrive solo un biglietto (un indirizzo) che dice: "Il pacco si trova al punto X del Diario".

Risultato: Il disco rigido scrive il pacco pesante una sola volta. Il resto del tempo, il sistema scrive solo piccoli bigliettini leggeri. È come se il corriere portasse solo l'etichetta del pacco nel magazzino, risparmiando un sacco di tempo e fatica.

2. Il Problema della Lettura (Il Labirinto)

C'è però un rovescio della medaglia. Se qualcuno vuole leggere un dato, il sistema deve prima guardare il biglietto nell'archivio, trovare l'indirizzo nel diario e poi andare a prendere il pacco. Senza aiuto, questo rende la lettura lenta (come cercare un libro in una biblioteca dove i libri sono sparsi a caso).

3. La Magia di Nezha: La "Pulizia Intelligente" (GC)

Qui entra in gioco l'innovazione principale di Nezha: un sistema di pulizia e riordino automatico (chiamato Garbage Collection o GC) che sa esattamente cosa sta facendo il "Diario di Bordo".

Nezha non si limita a pulire; riorganizza i dati mentre lavora:

• Prima della pulizia: I dati sono sparsi.
• Durante la pulizia: Il sistema crea una nuova zona di lavoro per i nuovi dati, mentre riordina quelli vecchi in un file ordinato e veloce.
• Dopo la pulizia: I dati sono disposti in ordine alfabetico (o logico) su un nastro continuo.

L'analogia: Immagina che Nezha sia un bibliotecario super-veloce. Mentre i clienti continuano a prendere e mettere libri (senza fermarsi), lui riorganizza i libri sugli scaffali in modo che siano tutti in ordine. Quando qualcuno chiede un libro, il bibliotecario sa esattamente dove è, perché i libri sono in fila ordinata, non sparsi a caso.

I Risultati: Quanto è veloce?

Grazie a questa combinazione di "scrivere una volta sola" e "riordinare i dati in modo intelligente", Nezha ha ottenuto risultati spettacolari nei test:

• Scrittura (Put): È diventato 4,6 volte più veloce (un aumento del 460%!). È come se il corriere facesse il viaggio in un quarto del tempo.
• Lettura (Get): È leggermente più veloce (+12,5%), perché la pulizia intelligente compensa il tempo perso a cercare i biglietti.
• Ricerca di più dati (Scan): È diventato 1,7 volte più veloce (+72,6%). È come se, invece di cercare libro per libro in una stanza disordinata, potessi scorrere una fila ordinata di libri.

In Sintesi

Nezha è un sistema che ha capito che i computer moderni sono veloci, ma i dischi rigidi soffrono quando devono scrivere le stesse cose troppe volte.

• Ha eliminato il lavoro di copia-incolla inutile.
• Ha creato un sistema di riordino automatico che non blocca mai il servizio.
• Ha dimostrato che, separando i "biglietti" dai "pacchi" e riordinandoli con cura, si può avere un database che è più veloce, più economico da gestire e più sicuro di quelli tradizionali.

È come passare da un sistema di posta dove devi spedire tre copie della stessa lettera per sicurezza, a un sistema dove spedisci una sola lettera e un codice di tracciamento intelligente che ti permette di trovarla istantaneamente quando serve.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration" in lingua italiana.

Titolo

Nezha: Un archivio distribuito Key-Value separato con integrazione Raft ottimizzata

1. Il Problema

Gli archivi distribuiti Key-Value (KV) basati su alberi LSM (Log-Structured Merge-tree) e protocolli di consenso come Raft sono fondamentali per le applicazioni big data. Tuttavia, l'analisi sistematica condotta dagli autori rivela un collo di bottiglia critico nelle operazioni di I/O causato dalla sovrapposizione delle operazioni di persistenza tra il protocollo di consenso e il motore di storage sottostante.

In un sistema tradizionale basato su Raft e LSM-tree, ogni operazione di scrittura (Put) richiede almeno tre scritture su disco distinte:

1. Persistenza del Log Raft: Scrittura della richiesta nel log di consenso per garantire la coerenza.
2. WAL (Write-Ahead Log) dell'LSM-tree: Scrittura nel log di pre-scrittura del motore di storage.
3. Persistenza del Memtable: Scrittura dei dati nel Memtable, che successivamente viene flushato in file SSTable.

Questa ridondanza, unita all'amplificazione delle scritture dovuta al processo di compattazione dell'LSM-tree, genera un eccessivo overhead di I/O, limitando le prestazioni complessive del sistema, specialmente in ambienti hardware moderni ad alta velocità (es. NVMe SSD).

2. Metodologia e Architettura di Nezha

Per risolvere questo problema mantenendo le garanzie di coerenza forte, gli autori propongono Nezha, un sistema di storage distribuito che integra innovativamente la separazione Key-Value con il protocollo Raft.

Le componenti architetturali chiave sono:

• KVS-Raft (Consensus Layer):

  • Un algoritmo di consenso ottimizzato che integra la separazione Key-Value direttamente nel protocollo Raft.
  • Meccanismo: Solo le chiavi (e i puntatori) vengono memorizzati nel motore di storage (RocksDB), mentre i valori vengono scritti direttamente e una sola volta in un file di log append-only chiamato ValueLog.
  • Il log Raft contiene solo l'offset del valore nel ValueLog, eliminando la necessità di scrivere i valori nel log di consenso, nel WAL dell'LSM e nel Memtable separatamente. Questo riduce le scritture dei valori da almeno tre volte a una sola volta.

• Framework di Garbage Collection (GC) Consapevole di Raft:

  • La separazione Key-Value introduce sfide per le letture (Get/Scan) poiché i valori sono sparsi nel ValueLog in ordine di arrivo, non ordinati per chiave.
  • Nezha introduce un meccanismo GC che riorganizza i dati:
    • File Log Non Ordinati: Per le nuove scritture (ordine cronologico).
    • File Log Ordinati: Per i dati compattati e ordinati per chiave, con indici hash per l'accesso rapido.
  • Il GC trasforma i dati sparsi in file sequenziali ordinati, migliorando drasticamente le prestazioni delle query di intervallo (Scan).

• Meccanismo di Elaborazione delle Richieste in Tre Fasi:
  Per garantire la correttezza durante il ciclo di vita dello storage (incluso il GC), il sistema gestisce le richieste in tre fasi distinte:

  1. Pre-GC: Letture e scritture avvengono sullo storage attivo.
  2. Durante-GC: Le nuove richieste vengono reindirizzate a un modulo di "Nuovo Storage" (New Storage), mentre il GC lavora sullo storage attivo. Le letture effettuano query parallele su entrambi i moduli per garantire la coerenza.
  3. Post-GC: I dati vengono consolidati nello "Storage Compattato Finale" e il vecchio storage viene eliminato.

3. Contributi Chiave

1. Identificazione del Collo di Bottiglia: Dimostrazione che la persistenza ridondante tra strato di consenso e storage è un limite prestazionale maggiore nei sistemi moderni.
2. KVS-Raft: Proposta di un protocollo di consenso che unifica la persistenza dei valori con la replicazione del log, eliminando le scritture ridondanti a livello di storage.
3. Framework GC Raft-Aware: Progettazione di un sistema di gestione dei dati che bilancia le prestazioni di scrittura (tramite separazione) e di lettura (tramite riordinamento e indicizzazione), risolvendo il problema delle prestazioni di lettura tipiche delle architetture Key-Value separate.
4. Garanzie di Sicurezza: Implementazione di un meccanismo a tre fasi che garantisce la correttezza delle operazioni di lettura e scrittura durante le transizioni di stato del sistema, mantenendo le proprietà di sicurezza di Raft.

4. Risultati Sperimentali

Gli autori hanno implementato Nezha in Go e hanno condotto test comparativi contro sistemi baselines (Original Raft+RocksDB, TiKV, PASV, LSM-Raft, Wisckey distribuito). I risultati mostrano miglioramenti significativi:

• Throughput (Rendimento):
  • Put (Scrittura): Miglioramento del 460,2% rispetto ai sistemi tradizionali. Il vantaggio aumenta con la dimensione dei valori.
  • Get (Lettura Punto): Miglioramento del 12,5% (grazie all'indicizzazione hash nel GC).
  • Scan (Lettura Intervallo): Miglioramento del 72,6%, risolvendo il problema delle I/O casuali tipico della separazione Key-Value non ottimizzata.
• Latenza: Riduzione significativa della latenza di scrittura (fino al 59,2% in meno) e latenza di lettura migliorata rispetto alle versioni senza GC.
• Scalabilità: Nezha mantiene prestazioni robuste all'aumentare della dimensione del cluster (da 3 a 7 nodi), superando di 3,5x-5,3x i sistemi tradizionali in termini di throughput.
• Recupero da Guasti: Tempi di recupero ridotti del ~34% grazie alla minore quantità di dati da ripristinare (solo offset e log ordinati).

5. Significato e Impatto

Il lavoro di Nezha rappresenta un passo avanti significativo nella co-progettazione (co-design) di protocolli di consenso e motori di storage.

• Efficienza delle Risorse: Riducendo le scritture su disco da tre a una, Nezha massimizza l'utilizzo delle moderne unità NVMe e riduce i costi operativi nel cloud (dove si paga per l'I/O).
• Coerenza e Prestazioni: Dimostra che è possibile ottenere prestazioni elevate senza sacrificare le garanzie di coerenza forte (Strong Consistency) fornite da Raft.
• Versatilità: L'architettura è efficace sia per carichi di lavoro scritti intensivi che per carichi di lettura misti, rendendola adatta a un'ampia gamma di applicazioni big data.

In sintesi, Nezha risolve il problema della ridondanza I/O nei sistemi distribuiti moderni attraverso un'innovazione architetturale che sposta la logica di separazione Key-Value dallo strato di storage allo strato di consenso stesso, offrendo un modello di riferimento per futuri sistemi di storage ad alte prestazioni.