Orb DLT について

アーキテクチャ

Orb DLT スタックは、図 1 に示すように Cassandra、Apollo、Core の 3 つの階層で構成されています。Cassandra クラスタはスタックのデータベースとして機能します。Apollo は Java アプリで、Cassandra の上部でデータベーストランザクションを管理します。Core は、アカウントおよびトランザクション機能を提供する Go 言語で開発された一揃いのアプリケーションです。Account Core と Con Core がその構成の中心となるアプリケーションです (Audit Core と Query Core)。Account Core はユーザーアカウントを作成および管理するための HTTP インターフェイスを提供します。Coin Core は、コイントランザクションや残高の照会を実行するための HTTP インターフェイスを提供します。

Core と Apollo は完全にステートレスなコンポーネントなので、これらのコンポーネントは問題なくスケールアップできます。スタック内では、Cassandra のみがステートフルです。しかし、Cassandra は分散型のデータベースであるため、必要に応じてデータベースの容量を増減することは比較的簡単です。したがって DLT スタックは容量計画の点で弾力性に優れています。全体として、これは 2 種類のマシンで構成されています。1 つは Cassandra クラスタに使用され、もう 1 つは Apollo および Core アプリの実行に使用されます。

Cassandra は冗長性とパフォーマンスのバランスに優れているため、Replication Factor (以降RFと表記) 3 で実行することをお勧めします。RF を低くするとデータが失われるリスクが高くなり、RF を高くすると要求のレイテンシにマイナスの影響が生じます。このガイドでは、Cassandra クラスタが単一のデータセンターで動作するように設定されていることを想定します。可能であれば、Cassandra インスタンスを物理的に離れた場所でホストすることをお勧めします。離れた場所でホストする場合は、別々のラックに割り当てられるように設定ファイルを編集し、Cassandra インスタンス間でデータが正しく分散されるようにします。

Apollo と Core は、リソースの消費量が比較的少ないため同じインスタンスで同時に実行できます。これはインストールおよび設定のプロセスを簡素化するのにも役立ちます。起動時に渡される引数に応じて、Core のシングルバイナリは Coin Core アプリケーションまたは Account Core アプリケーションのいずれかとして実行できます。Core アプリケーションは、Thrift プロトコルを使用して、Cassandra とのデータベーストランザクションを管理する Apollo と通信します。