Наші @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 разів швидше, ніж будь-яке інше рішення на ринку.