FISCO BCOS 2.0 Usage Tutorial: Distributed Storage Experience

Author: Mo Nan ｜ Senior Architect, FISCO BCOS

After the release of the Distributed Storage Architecture Design article, community members are very concerned about the technology kernel and its use。Team and community enthusiastic small partners, industry experts for distributed storage, a lot of discussion。Here, share your insights or help you better understand and use distributed storage:

  • The distributed storage of FISCO BCOS 2.0 adopts the library table style, and the CRUD operation conforms to the business habit。 -No contract storage variable mode, deconstructs the embedded coupling of contract and data, and makes contract upgrade easier。

  • Storage access engine logic and data structure more intuitive, easy to adapt to a variety of storage engines, large expansion space。 -The data itself is stored in a determinant manner, without the intertwined relationship of MPT trees, making it easier to take snapshots and cut and migrate。 -Table plus primary key structure index data, high access efficiency, easier concurrent access。

  • Less storage overhead, the capacity model is linearly related to the number of transactions and states, making it easier to predict business capacity, which is very meaningful for massive services。 -In terms of details, the state MPT is weakened, but the transaction and receipt MPT are retained, and the light client can still be supported, using process proof and existence proof, without relying on the volatile state, and without affecting the implementation of cross-chain。

  • The state is checked by incremental HASH, and the state generated by each block of transactions is rigorously checked across the network to ensure consistency。 -Initially built for SQL types, it can support engines such as MySQL and Oracle, and then adapt to NoSQL types such as LevelDB。More high-speed and mass storage engines will be adapted in the future, and the optimal solution will be explored in the triangular relationship of [single io delay / concurrency efficiency / capacity expansion]。

Although distributed storage is a big project (it took several fast shooters a year before they dared to take it out to meet people), it is very simple to use, and this article will talk about the experience process of distributed storage。Initial contact with users, it is recommended to start from the previous article (click the title to jump directly) → Distributed storage architecture design

Configure Distributed Storage

Distributed storage supports multiple storage engines and can be configured with different storage engines based on business requirements and deployment environment。

The basic data such as blocks and transactions of the blockchain are stored in a library table structure, and the state data can be stored in a library table structure or MPT to meet the needs of different scenarios。

The configuration items of distributed storage are located in the configuration file of the group. Each group can use a separate storage policy. The group configuration file is located in the path named conf / group. [group number] .genesis in the blockchain node, such as group.1.genesis. Once the group is started, the related configuration of the distributed storage of the group cannot be changed。

An example of a distributed storage configuration item is as follows:

[storage]

type = LevelDB: DB engine type for distributed storage

[state]

type = storage: the state type. Currently, storage state and MPT state are supported. The default value is storage state

Recommended storage state， Unless MPT must be used to trace the global historical state，MPT State not recommended。

Using CRUD Smart Contract Development

Distributed storage provides a dedicated CRUD interface that allows contracts to directly access the underlying storage tables。

To access CRUD, you need to reference the Table.sol interface, a smart contract dedicated to distributed storage. This interface is a database contract. You can create tables and add, delete, and query tables。

Quoting Table.sol

import "./Table.sol";

The Table.sol interface includes：

-createTable / / Create table

  • select(string, Condition) / / Query data

  • insert(string, Entry) / / Insert data

  • update(string, Entry, Condition) / / Update data

  • remove(string, Condition) / / Delete data

The usage of each interface is as follows：

Create Table

/ / The address of TableFactory is fixed to 0x1001
TableFactory tf = TableFactory(0x1001);

/ / Create the t _ test table. The key _ field of the table is name, and the value _ field is item _ id and item _ name
/ / key _ field indicates a column in the distributed storage master key value _ field indicates a column in the table, which can have multiple columns, separated by commas
int count = tf.createTable("t_test", "name", "item_id,item_name");

Query data

TableFactory tf = TableFactory(0x1001);
Table table = tf.openTable("t_test");

/ / If the condition is empty, you can filter without filtering or use the condition as needed
Condition condition = table.newCondition();

Entries entries = table.select(name, condition);

Insert Data

TableFactory tf = TableFactory(0x1001);
Table table = tf.openTable("t_test");

Entry entry = table.newEntry();
entry.set("name", name);
entry.set("item_id", item_id);
entry.set("item_name", item_name);

int count = table.insert(name, entry);

Update data

TableFactory tf = TableFactory(0x1001);
Table table = tf.openTable("t_test");

Entry entry = table.newEntry();
entry.set("item_name", item_name);

Condition condition = table.newCondition();
condition.EQ("name", name);
condition.EQ("item_id", item_id);

int count = table.update(name, entry, condition);

Delete Data

TableFactory tf = TableFactory(0x1001);
Table table = tf.openTable("t_test");

Condition condition = table.newCondition();
condition.EQ("name", name);
condition.EQ("item_id", item_id);

int count = table.remove(name, condition);

PS

The optimization of storage architecture is a basic project, but also a big project。The shift in implementation is actually an evolution of the architectural worldview, and the impact will be more profound than the functional points seen。This second article is only the tip of the iceberg of distributed storage。For more principles and use cases, please refer to: https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/smart_contract.html

Series selection

FISCO BCOS 2.0 Released: (with new features interpretation)

principle analysis

Design of Group Architecture: Make it as easy as group chat to establish a multi-party collaborative business relationship between enterprises。

Using tutorials

Group Structure Practice Exercise: Take building an arbitration chain as an example and demonstrate how to send transactions to that chain。