Канали MultiChain для інтеграції баз даних

Видалення даних із блокчейну та в широкий світ

З першим публічним випуском MultiChain, ще в 2015 році, ми побачили інтерес до блокчейн-додатків з дивовижного напрямку. Незважаючи на те, що ми спочатку розробили MultiChain, щоб забезпечити випуск, передачу та зберігання цифрових активів, все більша кількість користувачів була зацікавлена ​​у використанні його для програм, орієнтованих на дані.

У цих випадках використання мета блокчейна полягає у забезпеченні можливості зберігання та отримання інформації загального призначення, яка не повинна мати фінансовий характер. Мотивація використання блокчейну, а не звичайної бази даних, полягає у тому, щоб уникнути покладання на надійного посередника для розміщення та обслуговування цієї бази даних. З комерційних, нормативних чи політичних причин користувачі бази даних хочуть, щоб це була розподілена, а не централізована відповідальність.

Еволюція потоків

У відповідь на цей відгук у 2016 році ми введені Потоки MultiChain, які забезпечують просту абстракцію для зберігання, індексації та отримання загальних даних на блокчейні. Ланцюг може містити будь-яку кількість потоків, кожен з яких може бути обмежений для запису за певними адресами. Кожен елемент потоку позначається адресою видавця, а також додатковим ключем для подальшого пошуку. Кожен вузол може самостійно вирішити, чи підписуватись на кожен потік, індексуючи його елементи в режимі реального часу для швидкого пошуку за ключем, видавцем, часом, блоком або позицією. Потоки моментально потрапили у користувачів MultiChain і сильно відрізнили їх від інших корпоративних блокчейнових платформ.

У 2017 році потоки були розширений для підтримки власного тексту JSON та Unicode, кількох ключів на елемент та декількох елементів на транзакцію. Ця остання зміна дозволяє публікувати понад 10,000 2018 окремих елементів даних за секунду на високотехнологічному обладнанні. Тоді в XNUMX році ми додали безперебійну підтримку дані поза мережею, в якому в ланцюжку публікується лише хеш деяких даних, а самі дані доставляються поза мережею вузлам, які цього хочуть. А пізніше того ж року ми випустили MultiChain 2.0 Community with Розумні фільтри, що дозволяє користувацькому коду JavaScript виконувати довільну перевірку потокових елементів.

Протягом 2019 року ми зосередились на MultiChain 2.0 Enterprise, комерційній версії MultiChain для великих клієнтів. Перший Демонстрація підприємства використовували дані поза мережею в потоках, щоб дозволити зчитування, доставку зашифрованих даних та вибірковий пошук та очищення окремих елементів. Як завжди, основна складність прихована за простим набором API, що стосуються дозволів та елементів потоку. Що стосується потоків, наша мета постійно полягала в тому, щоб допомогти розробникам зосередитись на даних своїх додатків і не турбуватися про те, що блокчейн працює поза кадром.

Дилема бази даних

Оскільки потоки MultiChain продовжували розвиватися, ми стикалися з постійною дилемою. Для читання та аналізу даних у потоці, чи слід MultiChain піти шляхом перетворення на повноцінну базу даних? Чи повинен він пропонувати індексацію полів JSON, оптимізовані запити та розширену звітність? Якщо так, яку парадигму бази даних вона повинна використовувати - реляційну (як MySQL або SQL Server), NoSQL (MongoDB або Cassandra), пошукову (Elastic або Solr), часові ряди (InfluxDB) або вбудовану пам’ять (SAP HANA)? Зрештою, існують випадки використання блокчейну, які підходять для кожного з цих підходів.

Одним із варіантів, який ми розглянули, є використання зовнішньої бази даних як основного сховища даних MultiChain, замість поточної комбінації вбудованих LevelDB та двійкових файлів. Ця стратегія була прийнята Ядро ланцюга (припинено), Постчейн (ще не загальнодоступний) і доступний як варіант у тканині Hyperledger. Але врешті-решт ми вирішили відмовитись від цього підходу через ризик залежності від зовнішнього процесу. Ви насправді не хочете, щоб ваш блокчейн-вузол завис, оскільки він втратив підключення до бази даних або тому, що хтось запускає складний запит у його сховищі даних.

Ще одним фактором, який слід враховувати, є агностицизм технологій та інтеграції. У мережі блокчейнів, що охоплює кілька організацій, кожен учасник матиме власні уподобання щодо технології баз даних. Вони вже матимуть програми, інструменти та робочі процеси, побудовані на платформах, які відповідають їхнім потребам. Тому, вибираючи будь-яку конкретну базу даних або навіть пропонуючи кілька варіантів, ми в підсумку зробимо деяких користувачів нещасними. Подібно до того, як кожен учасник блокчейну може запустити свій вузол на різноманітних версіях Linux, він повинен мати можливість інтегруватися зі своєю базою даних на вибір.

Представляємо канали MultiChain

Сьогодні ми раді представити наш підхід до інтеграції баз даних - MultiChain Feeds. Потік - це двійковий двійковий журнал подій, що стосуються одного або декількох потоків блокчейну в реальному часі, для зчитування зовнішніми процесами. Ми також пропонуємо відкритий код Адаптер живлення MultiChain який може читати стрічку та автоматично копіювати її вміст у базу даних Postgres, MySQL або MongoDB (або декілька одночасно). Адаптер написаний на Python і має ліберальну ліцензію, тому його можна легко модифікувати для підтримки додаткових баз даних або для додавання фільтрації та перетворення даних. (Ми також задокументували формат файлу подачі для тих, хто хоче написати парсер іншою мовою.)

Вузол не повинен підписуватися на потік для того, щоб відтворити його події у стрічці. Це дозволяє повністю обійти вбудовану індексацію потоку MultiChain, щоб заощадити час та місце на диску. Фіди також відображають пошук та очищення поза мережевих даних і можуть повідомляти про надходження нових блоків на ланцюжок. Щоб заощадити місце на диску, ви можете точно контролювати, які події записуються у стрічку, і які поля записуються для кожної з цих подій. Крім того, файли каналів обертаються щодня, і є проста команда видалення для видалення файлів після обробки.

Чому канали MultiChain записуються на диск, а не передаються між процесами або через мережу? Оскільки ми хочемо, щоб вони слугували наднадійним журналом реплікації, який стійкий до простоїв бази даних, збоїв у роботі системи, втрати живлення тощо. Використовуючи дискові файли, ми можемо гарантувати довговічність і дозволити асинхронно оновлювати цільову базу даних. Якщо з якихось причин ця база даних перевантажується або відключається, MultiChain може продовжувати працювати без перерв, і база даних буде наздоганяти, як тільки все нормалізується.

Початок роботи з стрічками

Канали інтегровані в останню демонстраційну / бета-версію MultiChain Enterprise, яка є доступні для скачування зараз. Почніть, читаючи документацію до Адаптер живлення MultiChain, або перегляд API, пов’язані з кормами. Ми б дуже хотіли почути ваш відгук щодо цієї функції та як ми можемо розширити її в майбутньому.

З випуском каналів версія 2.0 MultiChain Enterprise тепер повна - див Завантаження та встановлення на сторінці для повного порівняння видань Community та Enterprise. Протягом наступних кількох місяців ми завершимо його тестування та оптимізацію, і очікуємо, що він буде готовий до виробництва приблизно наприкінці І кварталу. Тим часом, для отримання інформації щодо ліцензування або ціноутворення MultiChain Enterprise, будь ласка, не соромтеся увійти в контакт.

Будь ласка, залишайте будь-які коментарі на LinkedIn.

Джерело: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/