1/ Właśnie przełamaliśmy wąskie gardło związane z zobowiązaniem stanu w Eclipse: AlDBaran utrzymuje 48M aktualizacji/sek na 96-rdzeniowej maszynie AWS, przyspieszając rollup GigaCompute Eclipse.

2/ Dlaczego to ma znaczenie: 1M TPS -> 3M aktualizacje stanu/s (~3 klucze/tx w Eclipse). Gotowe silniki ADS dławią się poniżej 0,6 m/s, co jest 5-krotną różnicą, której nie chcieliśmy zaakceptować.

3/ Poznaj AlDBaran: dwa specjalnie zaprojektowane silniki dla stanu. 🔹 Plejady - niesamowicie szybkie aktualizacje w pamięci DRAM 🔹 Hyades — asynchroniczny magazyn zabezpieczeń tylko do dołączania

4/ Pięć zasad projektowania Plejad: 1️⃣ Wykonywanie tylko DRAM (bez fsync/błędów stron) 2️⃣ Odłamkiwanie gwintów (0 zamków) 3️⃣ Buforowanie gałązek (odroczenie haszowania wierzchołków drzewa) 4️⃣ Grupowanie SIMD (16 skrótów/operacja wektorowa) 5️⃣ Przewidywalny układ + pobieranie z wyprzedzeniem (trafienia pamięci podręcznej L2)

5/ Najważniejsze informacje o testach porównawczych: - 48M ups na 96 rdzeniach dla Pleiades przy około 1B (0,5 M/rdzeń ≈ 78% solo peak) i 40M ups nawet przy 8 B - Zasilacze UPS 24M z historią dla Hyades - Korzenie stanowe przepływają teraz przez łącze o przepustowości 50 Gb/s.

6/ To skok o 20× w stosunku do 2,3 M/s QMDB i o 30× szybszy niż w naszych wewnętrznych testach QMDB. Nasze zapotrzebowanie na 3 M/s zużywa teraz < 7% pojemności, co daje ogromną przestrzeń nad głową.

7/ Hyades działa w pełni asynchronicznie, pozyskując kompaktowe wpisy dowodowe 40B poza ścieżką do dziennika tylko do dołączania, podczas gdy pełne ładunki konta lądują w osobnym dzienniku. Gorąca ścieżka pozostaje nieskazitelna.

8/ Więcej informacji na temat architektury AlDBaran i głównych wyników można znaleźć na stronie: