1/ Abbiamo appena superato il collo di bottiglia dell'impegno statale su Eclipse: AlDBaran sostiene 48M aggiornamenti/sec su una macchina AWS a 96 core, accelerando il rollup di GigaCompute di Eclipse.

2/ Perché è importante: 1 milione di TPS -> 3 milioni di aggiornamenti di stato/sec (~3 chiavi/tx su Eclipse). I motori ADS standard si strozzano al di sotto di 0,6 M/s, un divario di 5 volte superiore che ci siamo rifiutati di accettare.

3/ Incontra AlDBaran: due motori appositamente costruiti per lo stato. 🔹 Pleiades - aggiornamenti velocissimi in DRAM 🔹 Hyades - archivio di prova asincrono di sola aggiunta

4/ Le cinque regole di progettazione delle Pleiadi: 1️⃣ Esecuzione solo DRAM (nessun errore fsync/page) 2️⃣ Partizionamento dei thread (0 blocchi) 3️⃣ Buffering dei ramoscelli (differisce l'hashing dell'albero superiore) 4️⃣ Batch SIMD (16 hash/operazione vettoriale) 5️⃣ Layout prevedibile + precaricamento (riscontri nella cache L2)

5/ Punti salienti del benchmark: - 48 milioni di up su 96 core per Pleiades a circa 1 B di tasti (0,5 M/core ≈ 78 % di picco in solitaria) e 40 milioni di up anche a 8 tasti B - 24M con la storia per Hyades - Le radici dello stato ora navigano attraverso un collegamento a 50 Gbps.

6/ Si tratta di un salto del 20× rispetto ai 2,3 M/s di QMDB e del 30× più veloce rispetto ai nostri test QMDB interni. Il nostro fabbisogno di 3 M/s ora consuma < 7% della capacità, con un'enorme altezza libera.

7/ Hyades funziona in modo completamente asincrono, inserendo voci di prova compatte di 40 miliardi fuori percorso in un registro di sola accodamento, mentre i payload completi dell'account atterrano in un diario separato. Il sentiero caldo rimane immacolato.

8/ Per saperne di più sull'architettura di AlDBaran e sui risultati principali, visitare: