Як працює словник SubQuery?

Уся ідея проекту загального словника полягає в тому, щоб індексувати всі дані з блокчейна і записувати події, екстрінсіки та її типи (модулі та методи) в базі даних у порядку зростання блоків. Інший проект може вимагати використання цього network.dictionary endpoint замість стандартного network.endpoint, визначеної у файлі маніфесту.

Значення network.dictionary endpoint є додатковим параметром, який у разі присутності, будет автоматично виявлений та використаний за допомогою SDK. network.endpoint є обов'язковим і проект не скомпілюється без нього.

Взявши проект SubQuery dictionary за приклад, файл schema визначає 3 сутності: extrinsic, events, specVersion. Ці 3 сутності містять відповідно 6, 4 та 2 поля. Коли цей проект запущено, ці поля відображаються в таблицях бази даних.

Потім дані з ланцюжка блоків зберігаються в цих таблицях та індексуються для продуктивності. Потім проект розміщено в SubQuery Project і кінцева точка API доступна для додавання в файл маніфесту.

Як включити словник у ваш проект?

Додайте dictionary:https://api.subquery.network/sq/subquery/dictionary-polkadot до розділу мережі маніфесту. Наприклад.

network:
  endpoint: wss://polkadot.api.onfinality.io/public-ws
  dictionary: https://api.subquery.network/sq/subquery/dictionary-polkadot

Що відбувається, коли словник НЕ використовується?

Якщо словник не використовується, індексатор отримуватиме всі дані блоку за допомогою polkadot api згідно batch-size , що за замовчуванням становить 100, і поставить це в буфер для обробки. Пізніше, індексатор бере всі ці блоки з буфера та під час обробки даних блоку, перевіряє, чи підходить фільтр за вказаними користувачами подіями і зовнішніми блоками.

Що відбувається, коли словник використовується?

Коли словник використовується, індексатор спочатку прийме фільтри виклику та подій як параметри, а потім об'єднає їх у запит GraphQL. Потім він використовує API словника, щоб отримати список з релевантною висотою блоків, що містить лише певні події та додаткові ознаки. Часто це істотно менше, ніж 100, якщо використовуються налаштування за замовчуванням.

Наприклад, уявіть собі ситуацію, де ви індексуєте подію "трансфер". Не всі блоки мають цю подію (на зображенні нижче, подія "трансфер" відсутня в блоках 3 та 4).

Словник дозволяє вашому проекту пропустити цю подію "трансфер", а не шукати її у кожному блоці, він пропустить її для блоків 1, 2 і 5. Це тому, що словник є попередньо налаштованим посиланням на всі виклики та події в кожному блоці.

Це означає, що за допомогою словника можна зменшити кількість даних, які отримує індексатор з ланцюга, а також зменшити кількість "не бажаних" блоків, які зберігаються в локальному буфері. Але, порівняно з традиційним методом, це додає додатковий крок, щоб отримати дані з API словника.

Коли словник НЕ корисний?

Коли block handlers використовується, щоб забрати дані з ланцюга, кожен блок повинен бути оброблений. Тому використання словника у цьому випадку не дає жодної переваги. Індексер перемикається автоматично на стандратний підхід, не використовуючи словники.

Також, коли він має справу з подіями або зовнішніми ознаками, що зустрічається або існує в кожному блоці, наприклад, timestamp.set, в такому випадку словник також не дасть ніяких додаткових переваг.