Наши методы архивирования @solana в 20 раз быстрее, чем что-либо еще на рынке. Мы открыли весь стек. Добавьте в закладки это 🔖 Архивные запросы в Solana известны своей медлительностью и ненадежностью: пропущенные блоки, задержка ответов, потерянные данные. Вот как мы это исправили 🧵

Стандартный архивный стек Solana (Bigtable + узлы RPC валидатора) легко развернуть, но сложно масштабировать. Он требует много ресурсов ЦП, нуждается в большом объеме памяти и испытывает трудности с большими пакетными запросами. Исторические данные — это то место, где задержка ощущается сильнее всего.

Мы пытались оптимизировать Bigtable. Добавили пользовательские таблицы, настроили запросы, довели его до предела. Но каждое изменение требовало полной перезагрузки узлов. Каждый раз от 30 минут до нескольких часов. Поэтому мы отказались от этого и перестроили всё: загрузку, хранение и RPC-сервер.

Новый стек: → ArchivalRPC: запускается за секунды, а не часы. Масштабируется до 200K RPS. → Пользовательский инжектор: выборочная загрузка для снижения затрат и точек отказа. → HBase вместо Bigtable: саморазмещенный, совместно расположенный, с почти нулевой задержкой.

Скорость ничего не значит, если данные неверны. Мы создали тройную проверку данных: каждая запись записывается дважды, проверяется программно и постоянно сканируется. Если обнаруживается разрыв, самовосстанавливающиеся конвейеры автоматически повторно загружают и исправляют его.

Результат по регионам: • 100,000 RPS для getTransaction • 50,000 RPS для getSignaturesForAddress • 2,000 RPS для getBlock До 20 раз быстрее, чем любое другое решение на рынке.