Чому штатні вузли не справляються з потоком даних
Повновузловий клієнт зберігає стан усієї мережі та віддає дані через RPC-виклики — це зручно для гаманця, але не для аналітики та продуктових сценаріїв.
Кожен запит історії — це або перебір блоків, або eth_getLogs за вузьким діапазоном, і щойно в одному блоці виявляється кілька тисяч подій, вузол починає віддавати відповіді частинами або взагалі розриває з'єднання за таймаутом. Застосунок отримує не дані, а фрагменти, і відновити за ними цілісну картину вже неможливо.
Відставання індексації — друга системна проблема.
Вузол синхронізується з мережею, але ваш шар читання живе окремим процесом і на піковому навантаженні не встигає за надходженням нових блоків: черга зростає, лаг між ончейн-подією та її появою у вашій базі вимірюється десятками хвилин. Для торгових сценаріїв, виплат і моніторингу це означає рішення, ухвалені за застарілими даними.
Третій клас збоїв — пропуск подій під час реорганізацій ланцюга та розривів з'єднань.
Якщо індексатор не відстежує зміну канонічної гілки і не вміє відкочувати вже записані записи, у базі залишаються події з відкинутих блоків: баланси та історії розходяться з реальним станом мережі, а знайти джерело розходження постфактум майже неможливо.
Штатний вузол не розрахований на те, щоб бути джерелом істини для продукту — він спроєктований як учасник консенсусу.
Саме тому під задачі з щільним потоком подій збирають кастомний індексатор блокчейну: власний конвеєр читання, ідемпотентний запис, контроль глибини підтверджень і явна обробка реорганізацій. Розбираємо, як це закривається на практиці.
Що дає власний конвеєр обробки даних
Затримка індексації перестає залежати від чужої інфраструктури
Публічні оглядачі віддають дані через спільний пул: у момент пікового навантаження запити до свіжих блоків стають у чергу, і застосунок отримує стан мережі із відставанням, яке ви не контролюєте.
Власний конвеєр читає блоки напряму з вузла і складає їх у власну базу — затримка між виходом блоку та його доступністю в API тримається в передбачуваному коридорі й не зростає разом із чужим навантаженням.
Для операцій, де важлива свіжість стану, це різниця між «дані за вчора» та «дані за останні секунди».
Повнота історії та розбір реорганізацій
Зовнішні джерела часто віддають урізану історію: частина внутрішніх переказів, логів подій і службових викликів у публічний індекс не потрапляє.
Власний конвеєр пише все, що пройшло через блок, включно з внутрішніми транзакціями та подіями контрактів, — вибірки за адресою або токеном не втрачають записи на глибині.
Окремо закривається тема реорганізацій: при відкаті ланцюга індексатор позначає зачеплені блоки недійсними й перебудовує зачеплений діапазон, тому в базі не залишається «висячих» станів, які потім спливають у звітах.
Стійкість до оновлень мережі та зниження ручних операцій
Мережа змінює формат блоків, додає нові типи подій, оновлює контракти — публічний оглядач під це підлаштовується сам, а ваші вибірки ламаються мовчки.
Власний конвеєр описує схему даних явно: при зміні формату правиться один модуль розбору, решта логіки та API залишаються незмінними.
Це прибирає регулярні ручні доопрацювання при оновленнях мережі — команда не витрачає цикли на розбір «чому поле зникло», а отримує стабільний потік даних, на який можна спиратися в продукті.
Способи організації індексації: порівняння режимів
Вибір режиму визначає не лише швидкість появи даних в індексі, а й вартість інфраструктури, і те, як система переживає перезбирання історії. На практиці чистих схем дві, а робоча конфігурація майже завжди третя — гібридна. Нижче — порівняння за тим, коли кожен режим доречний і де починає впиратися.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Потокова індексація | Потрібні свіжі дані із затримкою в секунди: баланси, операції, події контрактів у реальному часі | Потребує стійкого з'єднання з вузлом і черги; при розриві можливі пропуски, потрібен контроль порядку та повторна доставка блоків |
| Пакетна обробка | Первинне завантаження історії, аналітика, звіти, де важлива повнота, а не секунди | Дані з'являються із затримкою; на великих діапазонах блоків зростає час проходу та навантаження на вузол |
| Гібридний режим | Продукт із живим інтерфейсом і глибокою історією одночасно | Складніший у підтримці: два контури, узгодження стану та єдина точка звірки |
Чому гібрид закриває більше задач
Потоковий контур тримає «голову» ланцюга і віддає свіжі події, пакетний наздоганяє історію та перераховує ділянки при зміні логіки розбору.
Розділення знімає головне протиріччя: живий інтерфейс не чекає, поки переіндексується вся історія, а перезбирання не гальмує прийом нових блоків.
Ключовий елемент тут — ідемпотентність запису та чекпойнти за висотою блоку. Якщо обробка впала на середині діапазону, контур піднімається з останньої зафіксованої точки, а не починає заново. Це перетворює збій з «переіндексуємо все» на «наздоганяємо пропущене».
Обмеження гібрида — організаційні, а не технічні: потрібна дисципліна у схемі даних і єдина точка звірки, інакше контури починають розходитися. Ми закладаємо її на етапі проєктування, тому режим вибирається під задачу, а не під зручність реалізації.
Як ми вибудовуємо кастомний індексатор блокчейну
Роботу починаємо з аудиту інфраструктури: дивимося, які вузли вже підняті, як налаштована синхронізація з мережею, які запити до блокчейну йдуть сьогодні і які з них гальмують продукт.
На цьому етапі фіксуємо цільові метрики — глибину індексації, допустиме відставання від останнього блоку, набір полів у відповіді — щоб далі перевіряти результат за цифрами, а не за відчуттями.
- Аудит інфраструктури. Розбираємо поточні вузли, сховище, навантаження і точки відмови. Визначаємо, що перевикористаємо, а що доведеться замінити, і де індексатор упреться в стелю при зростанні кількості запитів.
- Проєктування конвеєра. Проєктуємо потік даних: приймання блоків, розбір подій, збагачення, запис у сховище, віддача через API. Заздалегідь закладаємо повторну обробку при збої — щоб пропущений блок не залишав діру в даних.
- Налаштування індексатора. Піднімаємо сервіси, налаштовуємо правила відбору подій і схеми зберігання під конкретні запити продукту. Окремо налаштовуємо моніторинг відставання і оповіщення при зупинці синхронізації.
- Перевірка повноти. Звіряємо проіндексовані дані з даними мережі на контрольних відрізках: скільки подій пропущено, чи збігаються баланси і стани. Проганяємо навантажувальні сценарії і перевіряємо поведінку при перезапуску.
- Передача і супровід. Віддаємо конфігурації, схеми і документацію, навчаємо команду замовника. Далі супроводжуємо: стежимо за оновленнями мережі і коригуємо правила індексації.
Кожен етап закінчується перевірюваним результатом, тому відхилення видно одразу, а не на проді. Опишіть задачу — повернемося з оцінкою і планом робіт.
Артефакти та документація після впровадження
Після запуску індексатора команда не залишається з «чорною скринькою»: усе, що описує поведінку системи, передається у вигляді робочих матеріалів. За ними ваш інженер зможе підняти стенд з нуля, повторити конфігурацію та зрозуміти, чому обробка влаштована саме так.
- Конфігурації індексатора та вузлів: параметри підключення до мережі, глибина переобробки при реорганізаціях, ліміти на розмір батча, налаштування повторних спроб.
- Схеми потоків даних: від приймання блоків до запису в сховище та віддачі через API — з точками, де можливі затримки та втрати.
- Регламенти обслуговування: планові перезапуски, переіндексація при зміні схеми, порядок дій при розбіжності стану з мережею.
- Політики доступу: ролі для читання та запису, розмежування за ендпоінтами, правила ротації ключів і секретів.
- Опис схеми зберігання: таблиці, індекси, стратегія партиціонування та очищення застарілих даних.
- Набір перевірок: health-ендпоінти, метрики відставання від голови мережі, алерти на зупинку обробки.
- Інструкція з розгортання: порядок підняття компонентів, залежності, змінні середовища, вимоги до ресурсів.
- Журнал рішень: які альтернативи розглядалися і чому обрано поточний варіант — щоб майбутні зміни не ламали логіку.
Матеріали передаються в репозиторії та вікі вашої команди, а не в листуванні. Ми залишаємося на зв'язку на етапі, коли ваші інженери вносять перші правки, — це знижує ризик, що документація розійдеться з реальною конфігурацією.
Кейс: як ми скоротили затримку індексації втричі
Замовник — сервіс аналітики по мережі на базі EVM-сумісного блокчейну — прийшов із симптомом, а не із задачею: дані в дашбордах відставали від мережі, а зранку індексатор відвалювався на переобробці.
Свій індексатор вони писали під задачу, але він читав блоки строго послідовно, одним потоком, і зберігав стан в одній таблиці без партиціонування. На піку навантаження черга нерозібраних блоків зростала швидше, ніж її встигав розгрібати воркер.
Що було до
Затримка між появою блоку в мережі та його доступністю в API сягала 40 хвилин на піках. Реорги глибше двох блоків ламали стан: індексатор не відкочував уже записані події, і в базі залишалися «висячі» записи зі скасованої гілки.
Раз на кілька днів процес падав по пам'яті — перезапуск означав повний перерахунок з нуля і ще кілька годин простою.
Що змінили
Рознесли читання і запис: окремий збирач тягне блоки пачками і кладе їх у чергу, пул воркерів розбирає її паралельно за діапазонами. Ввели явну обробку реоргів — при розходженні хешів індексатор відкочує зачеплені діапазони за журналом і перечитує канонічну гілку.
Стан розклали за партиціями з чекпоінтами: після падіння процес продовжує з останньої підтвердженої висоти, а не з нуля.
Що стало
| Метрика | До | Після |
|---|---|---|
| Затримка індексації на піку | до 40 хв | 12–13 хв |
| Відмови через реорги | регулярно | клас усунено |
| Простій після збою | години, повний перерахунок | секунди, з чекпоінта |
Затримка скоротилася втричі, ручні перезапуски пішли з процесу зовсім. Окремо винесли метрики самого індексатора — глибину черги, лаг за висотою, число відкатів — щоб команда замовника бачила деградацію до того, як її помітять користувачі.
Чим відрізняється кастомний індексатор від готових рішень?
Готові індексатори — це універсальні конвеєри: вони читають блоки, декодують стандартні події та розкладають їх у власну схему зберігання. Поки ви працюєте з типовими контрактами та однією мережею, цього достатньо.
Проблема починається там, де логіка вашого продукту розходиться з тим, що готовий інструмент уміє віддавати «з коробки»: нестандартні контракти, власні структури даних, перерахунок стану за історичними блоками, об'єднання кількох мереж в один запит.
Кастомна розробка починається з питання «які запити мають виконуватися швидко», а не «які дані є в блоках». Інженери проєктують схему зберігання під конкретні сценарії: агрегати за адресами, історію балансів на довільну висоту, зв'язки між подіями різних контрактів.
Готове рішення таку схему не запропонує — його модель фіксована, і ви підлаштовуєте продукт під неї, а не навпаки.
Критерії вибору прості. Якщо потрібен огляд мережі, стандартні перекази та події популярних контрактів — готовий інструмент закриє завдання швидше й дешевше в підтримці.
Якщо потрібні власні метрики, нестандартна агрегація, глибока історія або кілька мереж в одній відповіді — універсальний конвеєр упреться в обмеження, і обхідні шляхи з'їдять більше ресурсів, ніж власна розробка.
Окремо варто сказати про стійкість до реорганізацій ланцюга та збоїв вузлів. У кастомному індексаторі логіка відкатів і повторної обробки блоків проєктується під ваші дані: зрозуміло, які записи перераховуються, а які залишаються валідними. У готових рішень це чорна скринька — при розходженні доводиться розбиратися, що саме загубилося.
Порівняння варто вести не за кількістю підтримуваних мереж, а за тим, наскільки швидко ви отримаєте відповідь на нове питання до даних. Готовий інструмент відповідає на вже закладені питання, кастомний — на ті, які з'являться у продукту завтра.
Часті технічні сумніви при впровадженні
Індексатор — це не разова інтеграція, а сервіс, який живе разом із мережею: змінюються контракти, додаються події, виходять оновлення вузла. Тому перше, що перевіряє технічний замовник, — не «чи запрацює», а «що буде через пів року». Нижче — сумніви, які виникають на кожному проєкті, і як ми їх закриваємо інженерно.
Наскільки складно підтримувати кастомний індексатор власними силами?
Складність не в коді, а в експлуатації: реорги, відсталі блоки, зростання бази, переіндексація після апгрейду контракту.
Ми віддаємо сервіс із метриками (лаг індексації, глибина черги, частка помилок), алертами на відставання та регламентом переіндексації — команда бачить стан без читання вихідних кодів. Оновлення схеми подій робиться міграцією, а не переписуванням з нуля.
Чи сумісно це з нашою поточною інфраструктурою та вузлами?
Індексатор підключається до ваших нод або до зовнішніх провайдерів через стандартні інтерфейси, а результат віддає у звичне сховище — реляційну базу, пошуковий рушій або чергу. На вході — звичайні RPC-виклики та підписки на події, на виході — схема, яку споживає ваш бекенд.
Міграція не вимагає зупиняти поточні сервіси: новий індекс наповнюється паралельно, перемикання — зміною джерела читання.
Як забезпечується безпека та цілісність даних?
Дані беруться з підтверджених блоків з урахуванням фінальності, тому в індекс не потрапляють події зі скасованих гілок. Доступи розмежовані: сервіс індексації має лише читання до вузла та запис у свою схему, ключі підпису зберігаються окремо від процесу обробки.
Кожна подія супроводжується посиланням на блок і транзакцію — будь-який запис можна перевірити на ланцюжку.
Що якщо мережа або контракт зміняться після запуску?
Апгрейд контракту — штатний сценарій: нова версія подій описується окремою схемою, старі дані залишаються доступними. При зміні формату ми додаємо обробник і запускаємо переіндексацію потрібного діапазону блоків, не торкаючись решти історії. Версіонування схеми закладено з самого початку, тому перехід проходить без простою.
Опишіть вашу мережу та обсяг подій — повернемося з оцінкою та планом впровадження.
Обговоримо ваше завдання і запропонуємо план робіт
Щоб запропонувати план робіт, а не загальні слова, нам потрібно зрозуміти ваше завдання на рівні даних: які мережі та контракти індексуємо, які події та виклики методів важливі, що саме має потрапляти у відповіді API.
Опишіть сценарій — звідки надходять запити, які вибірки критичні за швидкістю, чи потрібна історична глибина або лише свіжі блоки. За цим описом ми зберемо чернетку архітектури і повернемося з оцінкою термінів та етапів.
На першій розмові уточнюємо вимоги та межі:
- джерела даних: які мережі, ноди або провайдери, чи потрібен доступ до архівних вузлів;
- модель даних: які сутності, зв'язки та агрегати мають бути в індексі, як часто перераховуються;
- навантаження та затримка: скільки запитів за секунду очікується, яка затримка від блоку до відповіді допустима;
- стійкість: що робимо при реорганізації ланцюга, пропуску блоку, падінні вузла — чи потрібен автоматичний догін;
- доступи та інфраструктура: де розгортаємо, свої сервери чи хмара, хто володіє ключами та даними;
- інтеграції: які сервіси та команди будуть читати індекс, у якому форматі їм зручно отримувати дані;
- розвиток: які метрики та вибірки з'являться пізніше, щоб закласти їх у схему без переробки.
Далі пропонуємо наступні кроки: фіксуємо узгоджені вимоги в короткому документі, показуємо схему потоку даних і склад індексу, розбиваємо роботу на етапи з перевірюваним результатом на кожному. Ви бачите, що і в якому порядку робиться, де можна запустити першу версію і як вона розширюється.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом робіт.
