Чому розробка subgraph гальмує при зростанні даних
Розробка subgraph на перший погляд — це декларативна схема: сутності, обробники подій, відображення полів. Обробник ловить подію контракту, пише сутність, а клієнт читає готову вибірку замість обходу логів через запити до даних смарт-контракту напряму. Поки подій десятки на добу, схема виглядає ідеальною — вузьке місце сховане в шарі даних.
Воно проявляється, коли частота подій у мережі зростає: транзакцій на адресу стає більше, кожен блок несе пачку логів, і обробники перестають встигати за головами ланцюга.
Відставання індексації накопичується нелінійно: черга зростає швидше, ніж пропускна здатність запису, а будь-яка правка схеми або відображення потребує переіндексації з нуля — години й доби простою на історичних контрактах. Індексація блокчейн-даних перестає бути фоновим процесом і стає критичним шляхом.
Ціна — викривлена картина на вітрині. Інтерфейс показує баланс за неповним набором подій, звіт будується за зрізом, який відстав на тисячі блоків, звірка зі станом ланцюга дає розбіжності.
Гірше те, що розбіжність тиха: дані валідні за формою, просто неповні, і виявляється це під час розбору інциденту, а не на графіку.
Далі розбираємо, як це закривається: розділенням потоку на гарячі й архівні сутності, фільтрами за адресами контрактів, пакетним записом і контрольними точками, за якими видно фактичне відставання, а не лише статус останнього блока.
Що дає керований шар індексації: ефект у цифрах
Розробка subgraph у The Graph дає вимірюваний ефект не сама по собі, а через керований шар індексації: схема, зіставлення подій і правила переіндексації описані в маніфесті й версіонуються разом із контрактами. Дані збираються заздалегідь, тому запит застосунку більше не чекає обходу мережі.
Швидкість збору даних перестає залежати від обсягу історії: повна переіндексація вкладається в хвилини, а нові події обробляються безперервно в міру надходження. Свіжість відповіді вимірюється затримкою між подією в мережі та записом в індексі й тримається в межах секунд.
Час відновлення після збою скорочується: індекс піднімається зі збережених контрольних точок, а не перебудовується з нуля, тому ручна звірка не потрібна.
Зникає цілий клас відмов — розсинхронізація даних застосунку зі станом контрактів, пропущені події під час реорганізації ланцюга, дублі після повторної обробки.
Навантаження на запити розподіляється: повторювані вибірки віддає кеш, важкі агрегати рахуються один раз під час індексації, а не на кожен виклик.
Частка застарілих відповідей падає до нуля, бо застосунок читає узгоджений стан на конкретний момент, а не проміжний результат обходу.
Метрики — швидкість збору, затримка відповіді, частка відновлень без ручного втручання — виводимо в моніторинг, щоб деградація була видна до скарг користувачів. Порогові значення фіксуємо в регламенті експлуатації, а не в листуванні.
Підходи до розробки subgraph: порівняння варіантів
Порівняння підходів до розробки subgraph упирається в дві речі: наскільки нестандартна логіка контрактів і хто відповідає за індекс після запуску.
Усі три варіанти реалізації дають робочий індекс на The Graph, але по-різному переживають оновлення контракту, зміну формату подій і зростання кількості запитів від зовнішніх споживачів даних.
Типова схема покриває стандартні сутності — токени, перекази, баланси — і розгортається швидко, якщо в проєкті немає кастомної логіки.
Самостійний збір усередині команди дає повний контроль над запитами, але тримається на одному інженері, який пам'ятає обробники подій та їхній порядок. Замовна схема проєктується під конкретну модель даних і залишається робочою, коли контракти змінюються.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Самостійний збір усередині команди | Логіка контрактів проста, є інженер, який знає схему подій | Залежить від однієї людини, затримки під час зміни контракту, немає ревʼю запитів |
| Типова схема за шаблоном | Стандартні токени, перекази, баланси, потрібен швидкий старт | Не покриває кастомні сутності, під час доопрацювання розходиться з реальною моделлю |
| Замовна схема із супроводом | Нестандартна логіка, кілька контрактів, зовнішні споживачі | Довше проєктування, потрібні доступи до репозиторіїв і опис подій |
Перехід між варіантами не потребує зупинки сервісу: нова версія індексується паралельно зі старою, споживачів переводять на неї після звірки сум і кількостей.
Тому підхід обирають не «назавжди», а під поточний етап — порівняння підходів фіксує, що саме змінюється під час переходу.
Як ми ведемо впровадження: етапи інженерної роботи
Етапи впровадження побудовані так, щоб кожен закінчувався перевірюваним результатом, а не звітом про витрачені години. Порядок однаковий і для нового сабграфа, і для переведення вже робочої індексації на нашу підтримку — змінюється лише глибина розбору на першому кроці.
-
Розбір контрактів і доступів. Збираємо адреси, інтерфейси та перелік подій, звіряємо їх з фактичним станом мережі. Окремо фіксуємо, хто володіє ключами розгортання і чи є доступ до історичних даних: без архіву блоків індексація з нуля упирається вже на першому етапі.
-
Розбір схеми даних. Визначаємо сутності, поля й зв'язки від реальних вибірок — що запитує інтерфейс, що потрібно аналітиці. Невикористовувані поля роздувають сховище й сповільнюють відповіді, тому схему узгоджуємо до написання обробників.
-
Проєктування обробників. Кожна подія перетворюється на зміну сутностей з урахуванням порядку блоків, реорганізацій і повторних викликів. Створення записів на вимогу закладаємо одразу, щоб не втрачати дані при першому зверненні.
-
Налаштування індексації. Задаємо мережу, стартовий блок, відсікання непотрібних діапазонів і пакетний запис. Проганяємо повну синхронізацію на тестовому контурі й заміряємо час до актуального блока.
-
Перевірка коректності вибірок. Звіряємо відповіді за контрольними адресами з даними напряму з мережі: баланси, обсяги, кількість подій. Розбіжності усуваємо до викладки, а не після скарги користувача.
-
Деплой і версіонування. Публікуємо з явною версією — попередня залишається доступною для відкату й клієнтів, які ще не оновилися.
-
Передача проєкту. Віддаємо схему, конфігурацію, інструкції з оновлення й доступів: команда супроводжує індексацію без нашої участі.
Артефакти передачі: схеми, регламенти, документація
Передаємо не лише робочий індекс, а й усе для його самостійного супроводу. Перевірка проста: ваш інженер вносить правку в обробку події й випускає нову версію, не задаючи нам питань. У комплект входять:
- Документація щодо схеми: сутності, поля й зв'язки, відповідність подіям контракту, індекси — з позначкою, що доведеться правити при додаванні нової події.
- Опис сутностей і полів: призначення атрибута, тип, джерело в логах контракту, поведінка при пропущених значеннях.
- Правила обробки подій: що індексується, як розводяться повтори, реорганізації ланцюга та оновлення контракту.
- Політики доступу: ролі в панелі керування, окремі ключі для ручного деплою і для збірки, порядок ротації.
- Регламент супроводу: порядок випуску версії, звірка індексу зі станом контракту, реакція на розбіжності.
- Інструкції для команди: локальний запуск вузла й індексатора, типові запити, відтворення збою на діапазоні блоків.
- Порядок оновлення й відкат: як закріпити попередню версію, щоб запити не падали, поки нова дораховує історію.
Кожен пункт захищається на прийманні: розгортання й випуск версії відтворюємо за інструкцією без участі автора. Супровід залишається у вашої команди, а ми підключаємося лише за новими задачами.
Кейс: прибрали відставання індексації та клас відмов
На вході — робочий subgraph на The Graph: основний контракт і фабрика як джерела подій. Запити віддавалися, але аналітичні панелі відставали від мережі на 6-9 годин, а кожна реорганізація ланцюга запускала повну переіндексацію.
Де було вузьке місце
Обробники читали стан контракту в момент обробки, а не брали його з самої події: на кожен блок ішло кілька мережевих звернень, і обробка не встигала за головою ланцюга. Другим обмеженням став запис — сутності зберігалися по одній на подію, тому сховище стримувало швидкість.
Окремий клас відмов — відсутність контролю фінальності. Події з непідтверджених блоків потрапляли в базу, і після реорганізацій розбіжності доводилося розбирати вручну, звіряючи агрегати зі станом контракту.
Що змінили і що зафіксували на замірах
Мапінги переписали: дані беремо з події, зовнішні звернення винесли з гарячого шляху в пакетну обробку. Сутності збираються пачкою і зберігаються за один прохід, незмінні поля винесені в окремий тип, схема почищена від дублів. До запису додано поріг підтверджень, під час реорганізації обробка перезапускається з висоти форку.
Після переїзду відставання індексації вимірюється секундами замість годин, повна переіндексація — три години замість сорока з гаком, обсяг сховища скоротився приблизно втричі.
Аналітична панель відповідає на порядок швидше, а за квартал спостережень — жодної розсинхронізації після реорганізацій; раніше це були щотижневі інциденти.
Що робити, якщо свій збирач даних уже розгорнуто?
Свій збирач не обов'язково вимикати, щоб перейти на The Graph: новий контур піднімається поруч, а споживачі перемикаються по одному.
Вирішує не порівняння інструментів, а кількість читачів даних і вимоги до їхньої свіжості — від цього залежить, потрібна паралельна робота двох контурів чи вистачить повної заміни.
Головна складність — міграція даних. Історію не можна перенести вивантаженням таблиць: кожен запис потрібно відтворити з подій контракту, інакше агрегати розійдуться з ланцюгом.
Звіряємо контури за діапазонами блоків — кількість подій на контракт, суми за токенами, останній стан адреси: розбіжність у конкретному діапазоні показує, де індексація загубила блок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повна заміна | Один споживач, простій допустимий | Переіндексація історії займає години, потрібна точка відсікання за номером блока |
| Поступовий перехід | Кілька споживачів, різні схеми читання | Довгий період подвійного запису й регулярна звірка розбіжностей |
| Паралельна робота | Критичний контур не можна зупиняти | Подвійне навантаження на вузли, потрібна дедуплікація записів |
Сумісність контурів тримається на однакових ідентифікаторах: хеш транзакції та індекс логу, ідемпотентний запис, єдиний формат адрес і сум. Тоді повторний прохід не плодить дублі, а споживача можна повернути на свій збирач без втрати історії.
Шлях обираємо за критичністю контуру: де простій допустимий — ідемо повною заміною, де ні — паралельною роботою з поступовим переходом споживачів.
Свіжість даних, доступи та обмеження: часті сумніви
Сумніви на етапі вибору підрядника зазвичай одні й ті самі: наскільки швидко індекс доганяє нові блоки, хто саме отримає доступ до запитів, що станеться при різкому зростанні навантаження і як боляче змінювати схему після запуску. Нижче — короткі відповіді за кожним пунктом, без маркетингу й загальних слів.
Наскільки свіжі дані віддає subgraph?
Індексатор обробляє блоки в міру підтвердження і спирається на налаштовувану глибину фіналізації — вона визначає компроміс між швидкістю віддачі та стійкістю до реорганізацій ланцюга.
Відставання контролюємо звіркою з незалежним вузлом: якщо розбіжність виходить за заданий поріг, спрацьовує оповіщення, а не тихе старіння цифр в інтерфейсі.
Як розмежовується доступ до даних?
Доступ видаємо ключами: окремий ключ на команду або сервіс, свої ліміти частоти й обсягу вибірки, журнал звернень. Ключ відкликається без перезбирання схеми, тому виведення підрядника або внутрішнього споживача не потребує зупинки сервісу й повторного розгортання.
Що буде при зростанні кількості запитів?
Обмеження знімаються архітектурно: пагінація замість суцільного вивантаження, заздалегідь пораховані агрегати у схемі замість важких обходів історії, кешування повторюваних вибірок. Коли одного індексатора перестає вистачати, додається другий — споживачі цього не помічають.
Як оновлюється схема без простою?
Нова версія subgraph розгортається паралельно зі старою. Споживачі мігрують поступово, стара версія залишається доступною до останнього клієнта, відкат — це перемикання вказівника на попередню збірку. Так зміна моделі даних не перетворюється на аварію.
Якщо якийсь із цих сумнівів не закрито — розберемо його на вашій схемі: покажемо, як індексація, доступи й версіонування ляжуть на конкретні запити.Обговоримо задачу: що уточнимо і як повернемося з планом
Щоб оцінка проєкту була предметною, а не «на око», нам потрібен набір ввідних — за ними видно обсяг мапінгів, кількість сутностей і глибину індексації. Нижче мінімальний список; якщо чогось поки немає, підкажемо, де це взяти і що можна замінити.
- Адреси контрактів і мережа: де розгортається subgraph і які ще середовища потрібно підтримати — тестова мережа чи основна.
- ABI або вихідні коди контрактів — за ними звіряємо сигнатури подій і відсікаємо розбіжності між документом і кодом.
- Перелік подій для індексації та правило, які з них вважаємо значущими: цим задається обсяг оброблюваних записів.
- Схема сутностей і зв'язків: які питання задають до даних і як їх агрегують — від неї залежить структура зберігання й кількість запитів.
- Типові вибірки, які підуть з інтерфейсу або дашборда: фільтри, сортування, пагінація, очікуваний час відповіді.
- Блок старту й адреси деплою — щоб не тягнути в індекс службову історію і зберегти відтворюваність збірки.
- Доступ до вузла й репозиторій зі збіркою: потрібен, щоб проганяти індексацію на реальних даних, а не на вибірці.
Далі повертаємося з оцінкою проєкту й планом робіт: етапи, склад команди, що робимо ми і що залишається на вашому боці, де точки узгодження.
Якщо за ввідними видно розвилки — наприклад, публічний розміщений subgraph чи приватний на своєму вузлі, — покажемо обидва варіанти та їхні обмеження за навантаженням і доступами. Старт проєкту починається після того, як план і критерії приймання узгоджені.
