MultiChain Feeds для интеграции баз данных

Получение данных из блокчейна и в более широкий мир

С первым публичным выпуском MultiChain еще в 2015 году мы увидели интерес к блокчейн-приложениям с удивительной стороны. Хотя мы изначально разработали MultiChain для обеспечения возможности выдачи, передачи и хранения цифровых активов, все большее число пользователей были заинтересованы в использовании его для приложений, ориентированных на данные.

В этих случаях использования цель цепочки блоков состоит в том, чтобы обеспечить хранение и поиск информации общего назначения, которая не обязательно должна быть финансовой по своей природе. Мотивация для использования блокчейна, а не обычной базы данных, состоит в том, чтобы не полагаться на доверенного посредника для размещения и обслуживания этой базы данных. По коммерческим, нормативным или политическим причинам пользователи базы данных хотят, чтобы это была распределенная, а не централизованная ответственность.

Эволюция потоков

В ответ на этот отзыв в 2016 году мы выпустили MultiChain потоки, которые обеспечивают простую абстракцию для хранения, индексации и извлечения общих данных в блокчейне. Цепочка может содержать любое количество потоков, каждый из которых может быть ограничен для записи по определенным адресам. Каждый элемент потока помечается адресом его издателя, а также дополнительным ключом для последующего извлечения. Каждый узел может самостоятельно решить, подписываться ли на каждый поток, индексируя его элементы в режиме реального времени для быстрого поиска по ключу, издателю, времени, блоку или позиции. Потоки были мгновенным ударом для пользователей MultiChain и сильно отличали его от других корпоративных блоковых платформ.

В 2017 году потоки были расширенная для поддержки собственного текста JSON и Unicode, нескольких ключей на элемент и нескольких элементов на транзакцию. Последнее изменение позволяет публиковать более 10,000 отдельных элементов данных в секунду на высокопроизводительном оборудовании. Затем в 2018 году мы добавили бесшовную поддержку вне цепочки данных, в котором только хэш некоторых данных публикуется в цепочке, а сами данные доставляются вне цепочки в узлы, которые этого хотят. А позже в том же году мы выпустили MultiChain 2.0 Community с Умные Фильтры, позволяя пользовательскому коду 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 Feeds

Сегодня мы рады представить наш подход к интеграции баз данных - 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/