Nasze metody archiwizacji @solana są do 20 razy szybsze niż cokolwiek innego na rynku. Udostępniliśmy cały stos jako open source. Dodaj to do zakładek 🔖 Zapytania archiwalne na Solanie są notorycznie wolne i zawodzące: brakujące bloki, opóźnione odpowiedzi, utracone dane. Oto jak to naprawiliśmy 🧵

Standardowy archiwalny stos Solany (Bigtable + węzły RPC walidatora) jest łatwy do wdrożenia, ale trudny do skalowania. Jest intensywny pod względem CPU, wymaga dużej ilości pamięci i ma problemy z dużymi żądaniami wsadowymi. Dane historyczne to miejsce, gdzie opóźnienia są najbardziej odczuwalne.

Próbowaliśmy zoptymalizować Bigtable. Dodaliśmy niestandardowe tabele, dostosowaliśmy zapytania, pchnęliśmy to tak daleko, jak to możliwe. Ale każda zmiana wymagała pełnego restartu węzłów. 30 minut do kilku godzin za każdym razem. Więc porzuciliśmy to i zbudowaliśmy wszystko od nowa: pobieranie, przechowywanie i serwer RPC.

Nowy stos: → ArchivalRPC: uruchamia się w sekundy, a nie w godziny. Skaluje do 200K RPS. → Niestandardowy ingestor: selektywna ingesta w celu obniżenia kosztów i punktów awarii. → HBase nad Bigtable: samodzielnie hostowany, współlokalizowany, z niemal zerową latencją.

Szybkość nic nie znaczy, jeśli dane są błędne. Zbudowaliśmy potrójnie weryfikowany proces pozyskiwania: każdy rekord jest zapisywany dwukrotnie, walidowany programowo i ciągle skanowany. Jeśli wykryta zostanie luka, samonaprawiające się rurociągi automatycznie ponownie pozyskują i naprawiają ją.

Wynik, według regionu: • 100 000 RPS dla getTransaction • 50 000 RPS dla getSignaturesForAddress • 2 000 RPS dla getBlock Do 20 razy szybszy niż jakiekolwiek inne rozwiązanie na rynku.