データベース統合のためのマルチチェーンフィード

データをブロックチェーンから取り出して、より広い世界へ

2015年にさかのぼるMultiChainの最初の公開リリースで、意外な方向からブロックチェーンアプリケーションに関心がありました。 もともとデジタルアセットの発行、転送、および保管を可能にするためにマルチチェーンを設計していましたが、データ指向のアプリケーションにマルチチェーンを使用することに関心を持つユーザーが増えています。

これらの使用例では、ブロックチェーンの目的は、本質的に金銭的である必要のない汎用情報の保存と取得を可能にすることです。 通常のデータベースではなくブロックチェーンを使用する動機は、そのデータベースをホストおよび維持するために信頼できる仲介者に依存することを避けることです。 商業上、規制上、または政治上の理由から、データベースのユーザーはこれを一元化された責任ではなく分散したものにすることを望んでいます。

ストリームの進化

このフィードバックを受けて、2016年には 導入 マルチチェーンストリーム。これは、ブロックチェーン上の一般的なデータの格納、インデックス作成、および取得のための単純な抽象化を提供します。 チェーンには任意の数のストリームを含めることができ、各ストリームは特定のアドレスによる書き込みを制限できます。 各ストリーム項目には、その発行元のアドレスと、将来の取得のためのオプションのキーがタグ付けされています。 各ノードは、各ストリームをサブスクライブするかどうかを個別に決定し、キー、パブリッシャー、時間、ブロック、または位置による迅速な取得のためにリアルタイムでアイテムにインデックスを付けることができます。 ストリームはMultiChainのユーザーにすぐにヒットし、他のエンタープライズブロックチェーンプラットフォームとは大きく異なりました。

2017年、ストリームは で ネイティブJSONおよびUnicodeテキスト、アイテムごとの複数のキー、およびトランザクションごとの複数のアイテムをサポートします。 この最後の変更により、ハイエンドハードウェアで毎秒10,000を超える個別のデータアイテムを公開できます。 その後、2018年にシームレスなサポートを追加しました オフチェーンデータ、一部のデータのハッシュのみがチェーン上で公開され、データ自体が必要なノードにチェーン外で配信されます。 そしてその年の後半に、MultiChain 2.0 Communityをリリースしました。 スマートフィルター、カスタムJavaScriptコードがストリーム項目の任意の検証を実行できるようにします。

2019年の焦点は、大規模顧客向けのマルチチェーンの商用バージョンであるマルチチェーン2.0エンタープライズに向けられました。 最初 エンタープライズデモ ストリーム内のオフチェーンデータを活用して、読み取り許可、暗号化されたデータ配信、および個々のアイテムの選択的な取得とパージを可能にしました。 いつものように、根本的な複雑さは、権限とストリーム項目に関連する単純なAPIセットの背後に隠されています。 ストリームの場合、私たちの目標は一貫して、開発者がアプリケーションのデータに集中できるようにすることであり、舞台裏で実行されているブロックチェーンについて心配する必要はありません。

データベースのジレンマ

マルチチェーンストリームは進化し続けているため、絶え間ないジレンマに直面しています。 ストリーム内のデータを読み取って分析するために、MultiChainは本格的なデータベースになる道を進むべきですか？ JSONフィールドインデックス、最適化されたクエリ、高度なレポートを提供する必要がありますか？ その場合、どのデータベースパラダイムを使用する必要がありますか–リレーショナル（MySQLまたはSQL Serverなど）、NoSQL（MongoDBまたはCassandra）、検索（ElasticまたはSolr）、時系列（InfluxDB）またはインメモリ（SAP HANA）？ 結局のところ、これらのアプローチのそれぞれに適したブロックチェーンの使用例があります。

私たちが検討したオプションのXNUMXつは、埋め込まれたLevelDBとバイナリファイルの現在の組み合わせの代わりに、マルチチェーンのプライマリデータストアとして外部データベースを使用することです。 この戦略は チェーンコア （廃止）、 ポストチェーン （まだ公開されていません）そして利用可能です オプションとして ハイパーレジャーファブリック。 しかし、外部プロセスに依存するリスクがあるため、最終的にはこのアプローチに反対することを決定しました。 ブロックチェーンノードがデータベース接続を失ったため、または誰かがそのデータストアで複雑なクエリを実行しているため、ブロックチェーンノードをフリーズさせたくありません。

考慮すべきもうXNUMXつの要素は、テクノロジーと統合の不可知論です。 複数の組織にまたがるブロックチェーンネットワークでは、各参加者はデータベーステクノロジーに関して独自の好みを持っています。 彼らはすでに、ニーズに合ったプラットフォーム上に構築されたアプリケーション、ツール、ワークフローを持っています。 したがって、特定のデータベースを選択したり、いくつかのオプションを提供したりしても、一部のユーザーは不満を感じることになります。 各ブロックチェーン参加者がさまざまなLinuxフレーバーでノードを実行できるのと同じように、選択したデータベースと統合できるはずです。

マルチチェーンフィードの紹介

今日、データベース統合へのアプローチをリリースできることを嬉しく思います– MultiChain Feeds。 フィードは、外部プロセスで読み取るための、XNUMXつ以上のブロックチェーンストリームに関連するイベントのリアルタイムのディスク上のバイナリログです。 オープンソースも提供しています マルチチェーンフィードアダプター フィードを読み取り、そのコンテンツをPostgres、MySQL、またはMongoDBデータベース（または一度に複数）に自動的に複製できます。 アダプターはPythonで記述されており、リベラルなライセンスが付与されているため、追加のデータベースをサポートしたり、データのフィルタリングや変換を追加したりするために簡単に変更できます。 （私達はまた文書化しました フィードファイル形式 別の言語でパーサーを書きたい人のために。）

イベントをフィードに複製するために、ノードはストリームにサブスクライブする必要はありません。 これにより、MultiChainの組み込みのストリームインデックスを完全にバイパスして、時間とディスク領域を節約できます。 フィードは、チェーン外のデータの取得とパージも反映し、チェーンへの新しいブロックの到着を報告できます。 ディスク容量を節約するために、フィードに書き込まれるイベントと、各イベントに対して記録されるフィールドを正確に制御できます。 さらに、フィードファイルは毎日ローテーションされ、処理後にファイルを削除する簡単なパージコマンドがあります。

マルチチェーンフィードがプロセス間またはネットワーク経由でストリーミングされるのではなく、ディスクに書き込まれるのはなぜですか？ データベースのダウンタイム、システムクラッシュ、停電などに耐えられる、非常に信頼性の高いレプリケーションログとして機能させるためです。 ディスクファイルを使用することで、耐久性を保証し、ターゲットデータベースを非同期で更新できます。 何らかの理由でこのデータベースが過負荷になったり切断されたりした場合、MultiChainは中断することなく動作を継続でき、正常に戻るとデータベースが追いつきます。

フィード入門

フィードは、MultiChain Enterpriseの最新のデモ/ベータに統合されています。 ダウンロード可能 今。 のドキュメントを読んで始めましょう マルチチェーンフィードアダプター、または フィード関連のAPI。 私たちはしたいです フィードバックを聞く この機能と、今後の拡張方法について説明します。

フィードのリリースにより、MultiChain Enterpriseのバージョン2.0の機能が完成しました。 ダウンロードとインストール コミュニティエディションとエンタープライズエディションの完全な比較については、ページをご覧ください。 今後数か月間でテストと最適化を完了し、Q1の終わり頃に本番環境での準備ができると期待しています。 それまでの間、MultiChain Enterpriseのライセンスまたは価格については、お気軽に 連絡を取る.

コメントを投稿してください LinkedInの上に.

ソース：https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/