Shirakami: A Hybrid Concurrency Control Protocol for Tsurugi Relational Database System

Il documento presenta Shirakami, un nuovo protocollo ibrido di controllo della concorrenza per il sistema di database relazionale Tsurugi, che integra in modo stabile transazioni lunghe e brevi senza necessità di commutazione dinamica, ottenendo prestazioni significativamente superiori rispetto a PostgreSQL.

L'essenziale

🏗️ Il Problema: La Festa in Casa e il Cantante

Immagina di avere un database come se fosse una grande casa dove le persone (i dati) vivono e lavorano.
In questa casa accadono due cose molto diverse:

1. Le "Spedite" (Transazioni Corte): Sono come ospiti che entrano, prendono un bicchiere d'acqua, lo rimettono e se ne vanno in 2 secondi. Sono veloci, leggere e tantissime.
2. I "Lavoratori Pesanti" (Transazioni Lunghe): Sono come un'impresa edile che deve ristrutturare l'intera cucina. Devono spostare mobili, dipingere pareti e spostare tubi. Ci vogliono ore.

Il problema dei sistemi attuali (come PostgreSQL):
Finora, i sistemi di gestione delle case (i database) erano fatti per gestire solo le "spedite". Se arrivava il "lavoratore pesante" (l'impresa edile), il sistema si bloccava.

• O il lavoratore pesante aspettava che tutti gli ospiti uscissero (lento).
• O gli ospiti venivano cacciati di casa per far passare il lavoratore (errori e ritardi).
• Spesso, per sicurezza, si decideva di fare i lavori pesanti solo di notte, quando non c'era nessuno, lasciando la casa inutilizzabile per le attività quotidiane.

💡 La Soluzione: Shirakami (Il Nuovo Portiere)

Gli autori di questo paper hanno creato un nuovo sistema chiamato Shirakami (nato dal monte Shirakami, simbolo di natura e stabilità in Giappone). È un "portiere" intelligente che sa gestire sia le spedite veloci che i lavori pesanti, facendoli convivere senza che si disturbino a vicenda.

Shirakami usa due strategie diverse, come se avesse due modi di lavorare:

1. Shirakami-OCC (Per le "Spedite" veloci)

Immagina un campionato di calcio.

• I giocatori (le transazioni corte) corrono, passano la palla e tirano in porta.
• Non si fermano a chiedere il permesso a ogni passo. Corrono, fanno il loro lavoro e solo alla fine controllano se qualcuno ha toccato la palla mentre loro correvano.
• Se c'è stato un contatto, si riparte da capo (ma succede raramente perché sono veloci).
• Metafora: È come un gruppo di amici che fanno una corsa veloce in un parco: ognuno corre per la sua strada e controlla solo alla fine se ha urtato qualcuno.

2. Shirakami-LTX (Per i "Lavoratori Pesanti")

Immagina un cantante che sta registrando un album in uno studio.

• Prima di iniziare a cantare, il cantante (la transazione lunga) avvisa tutti: "Ok, tra un'ora userò questo microfono e questa stanza".
• Questo avviso si chiama Write Preservation (Preservazione della Scrittura). È come mettere un cartello "Lavori in corso" prima ancora di iniziare a trivellare.
• Gli ospiti veloci (Shirakami-OCC) vedono il cartello. Se devono passare di lì, sanno che devono aspettare o cambiare strada prima di entrare, evitando di urtare il cantante.
• Il trucco magico (Order Forwarding): A volte, il cantante sta lavorando su una parte della casa e un ospite veloce sta guardando un'altra parte. Invece di dire all'ospite "fermati", il sistema dice: "Ok, tu sei arrivato prima di lui nella fila, quindi vai avanti". Questo permette a entrambi di finire il lavoro senza che nessuno debba ricominciare da zero.

🚀 Come funziona la convivenza?

Il segreto di Shirakami è che non deve scegliere tra i due metodi. Li usa contemporaneamente.

• Priorità: Le transazioni lunghe (LTX) hanno una priorità speciale. Se un lavoro lungo sta per iniziare, il sistema lo protegge.
• Nessun blocco: Le transazioni corte non vengono bloccate dai lavori lunghi, e i lavori lunghi non vengono interrotti dalle transazioni corte.
• Sincronizzazione: Tutto funziona a "turni" (chiamati Epochs). Immagina che ogni minuto sia un turno. Alla fine del turno, tutti controllano se hanno fatto il lavoro correttamente e si aggiornano insieme.

📊 I Risultati: Quanto è veloce?

Gli autori hanno testato questo sistema su due scenari reali:

1. Fatturazione Telefonica: Calcolare le chiamate di milioni di persone mentre arrivano nuove chiamate in tempo reale.
2. Gestione Magazzino (Bill of Materials): Calcolare il costo di un prodotto che è fatto di migliaia di pezzi, aggiornando i prezzi dei materiali mentre il magazzino viene rifornito.

I numeri parlano chiaro:

• Rispetto al sistema attuale (PostgreSQL), il nuovo sistema Tsurugi (che usa Shirakami) è 19,7 volte più veloce nel calcolo delle fatture telefoniche.
• Per i lavori lunghi, Shirakami è 680 volte più efficiente rispetto a quando si usa solo il metodo per le transazioni corte.
• In pratica: Nessun più "lavori notturni". Si può fare il calcolo dei costi o la fatturazione in tempo reale, mentre il sistema continua a gestire le piccole operazioni quotidiane senza rallentare.

🎯 In Sintesi

Shirakami è come un direttore d'orchestra geniale.
Prima, se c'era un assolo di violino (lavoro lungo), l'orchestra doveva fermarsi. Ora, il direttore sa come far suonare il violino (lavoro lungo) e le percussioni veloci (lavori corti) allo stesso tempo, senza che si coprano a vicenda.

Il risultato è un database che non si blocca mai, che gestisce sia i piccoli click veloci che i calcoli complessi, rendendo possibile fare cose che prima richiedevano ore di attesa o interruzioni del servizio. È un passo avanti verso database che lavorano davvero "in tempo reale", 24 ore su 24.

Sommario tecnico

1. Il Problema

Il paper affronta una sfida crescente nei sistemi di gestione di database relazionali moderni: la necessità di gestire simultaneamente due tipi di carichi di lavoro (workload) molto diversi all'interno dello stesso sistema, mantenendo la consistenza dei dati.

• Transazioni Brevi: Operazioni online tipiche (OLTP), come aggiornamenti di inventario o fatturazione in tempo reale, caratterizzate da bassa latenza e alto volume.
• Transazioni Lunghe (Read-Write): Operazioni analitiche o batch (es. calcolo dei costi di produzione, fatturazione telefonica mensile) che richiedono scansioni su larga scala, elaborazioni complesse e scritture massicce.

I protocolli di controllo della concorrenza tradizionali (come Silo, ERMIA, TicToc) sono ottimizzati per transazioni brevi e falliscono o degradano drasticamente le prestazioni quando devono gestire transazioni lunghe, a causa di conflitti frequenti e aborti. D'altro canto, i protocolli deterministici o quelli progettati per transazioni lunghe (come Oze o Tuskflow) sono spesso inefficienti per le transazioni brevi o richiedono l'interruzione del sistema per cambiare protocollo, introducendo latenza. Inoltre, molti di questi approcci non supportano nativamente l'esecuzione SQL con sottorequeste in ambienti di produzione.

2. Metodologia: Il Protocollo Shirakami

Gli autori propongono Shirakami, un nuovo protocollo di controllo della concorrenza ibrido, implementato come modulo di elaborazione transazionale per il database relazionale Tsurugi. Shirakami integra due sottoprotocolli distinti che operano in modo concorrente senza necessità di switching dinamico:

A. Shirakami-LTX (S-LTX)

Progettato per le transazioni lunghe.

• Base Teorica: Utilizza la Multiversion View Serializability (MVSR), che offre uno spazio di schedulazione più ampio rispetto alla serializzabilità classica (CSR), riducendo i falsi positivi negli aborti.
• Write Preservation (WP): Le transazioni lunghe dichiarano in anticipo l'area di scrittura (a livello di tabella) prima di iniziare. Questo permette alle transazioni brevi di rilevare potenziali conflitti in fase di lettura ed abortire preventivamente, evitando di bloccare le transazioni lunghe.
• Order Forwarding (Inoltro dell'Ordine): Se una transazione a bassa priorità (lunga) legge dati scritti da una transazione ad alta priorità (lunga), il protocollo può dinamicamente invertire l'ordine di serializzazione. La transazione a bassa priorità viene "spostata" all'epoca della transazione ad alta priorità, permettendo a entrambe di commitare senza aborti. Questo meccanismo espande lo spazio di schedulazione oltre i limiti della CSR.
• Gestione delle Fantasmatiche: Implementa meccanismi specifici per evitare letture fantasma durante l'inoltro dell'ordine.

B. Shirakami-OCC (S-OCC)

Progettato per le transazioni brevi.

• Base Teorica: Deriva dal protocollo Silo, un protocollo ottimistico (OCC) ad alte prestazioni.
• Integrazione: È modificato per coesistere con S-LTX. Le transazioni brevi controllano le informazioni di "Write Preservation" delle transazioni lunghe durante la fase di lettura. Se rilevano un conflitto, abortiscono immediatamente.
• Priorità: Le transazioni S-LTX hanno priorità più alta rispetto alle S-OCC. Se c'è un conflitto, la transazione breve viene abortita per proteggere quella lunga.

C. Sincronizzazione basata su Epoche

Il sistema utilizza un meccanismo di sincronizzazione basato su "epoche" (unità di tempo fisse).

• Le transazioni S-LTX utilizzano un'epoca di apertura per la serializzazione, mentre le S-OCC usano un'epoca di chiusura.
• Questo garantisce che tutte le transazioni lunghe di un'epoca siano serializzate prima di quelle brevi, prevenendo interferenze.
• Il sistema gestisce snapshot in memoria (sicuri e non sicuri) per fornire la coerenza dei dati necessaria.

3. Contributi Chiave

1. Protocollo Ibrido Produttivo: Shirakami è la prima implementazione a livello di produzione che combina efficacemente un protocollo per transazioni lunghe (basato su MVSR e Order Forwarding) con uno per transazioni brevi (basato su Silo), permettendo loro di operare concorrentemente senza switching manuale.
2. Supporto SQL Completo: A differenza di molti protocolli deterministici o per grafi, Shirakami supporta l'esecuzione SQL completa, inclusi sottorequeste, rendendolo adatto a database relazionali generici.
3. Meccanismi di Conflitto Avanzati: L'introduzione di Write Preservation a livello di tabella e Order Forwarding dinamico permette di gestire scenari di conflitto complessi riducendo drasticamente il tasso di aborti per le transazioni lunghe.
4. Implementazione Tsurugi: Il protocollo è stato integrato in Tsurugi, un database relazionale in memoria (in-memory) moderno, basato su microservizi e architetture scalabili.

4. Risultati Sperimentali

Gli autori hanno valutato le prestazioni su scenari reali e benchmark standard:

• Benchmark di Fatturazione Telefonica (Telecom Billing):
  • Confronto tra Tsurugi (con Shirakami) e PostgreSQL.
  • Risultato: Tsurugi ha mostrato una latenza 19,7 volte inferiore rispetto a PostgreSQL per le transazioni batch lunghe in presenza di transazioni online concorrenti. PostgreSQL non è riuscito a completare il test entro il limite di tempo con 64 thread, mentre Tsurugi sì.
• Benchmark Bill of Materials (BoM):
  • Simulazione di calcolo dei costi di produzione.
  • Risultato: Tsurugi è stato 5,6 volte più veloce di PostgreSQL. PostgreSQL ha mostrato anomalie di consistenza quando configurato con isolamento READ COMMITTED.
• Benchmark YCSB-E (Transazioni Lunghe vs Brevi):
  • Confronto diretto tra S-LTX e S-OCC in un carico misto.
  • Risultato: S-LTX ha dimostrato una throughput 680 volte superiore rispetto a S-OCC quando si gestivano transazioni lunghe in un ambiente conteso. S-OCC falliva completamente (throughput zero) per transazioni lunghe superiori a una certa soglia di operazioni, mentre S-LTX manteneva prestazioni stabili.
• TPC-C: Tsurugi scala linearmente fino a 128 thread, mentre PostgreSQL satura o degrada oltre 16 thread.

5. Significato e Impatto

Il lavoro di Shirakami è significativo perché risolve il "dilemma" storico dei database moderni: la coesistenza di carichi di lavoro OLTP (transazionali) e OLAP (analitici) sullo stesso database senza compromessi.

• Eliminazione dei Batch Notturni: Le aziende non sono più costrette a eseguire grandi elaborazioni batch (come la fatturazione o il calcolo dei costi) durante la notte per evitare conflitti con le operazioni online. Possono essere eseguite in tempo reale.
• Efficienza delle Risorse: Sfruttando meglio le risorse hardware (CPU multi-core) senza la penalità degli aborti massivi tipici dei protocolli tradizionali.
• Adozione Industriale: Essendo implementato in un sistema di produzione (Tsurugi) e supportando SQL completo, Shirakami offre una soluzione pratica e immediatamente applicabile per settori critici come le telecomunicazioni, la logistica e la manifattura, dove la consistenza e la tempestività dei dati sono fondamentali.

In sintesi, Shirakami rappresenta un avanzamento fondamentale nell'architettura dei database, dimostrando che è possibile unificare l'elaborazione transazionale e analitica in un unico motore coerente e ad alte prestazioni.