With the gradual development of blockchain technology, the connection between blockchain and distributed databases has become increasingly close and subtle. This paper, published at the SIGMOD conference (ACM Conference on Management of Data) in 2021, analyzes the classification method of blockchain and distributed database and the hybrid system of the two from the bottom design.
The research first details the taxonomy used to describe blockchains, distributed databases, and their hybrid systems: from four aspects of replication, concurrency, storage, and sharding; then uses permissioned chains Quorum, Fabric, and databases TiDB, etcd , design performance experiments and analyze the experimental results in detail; finally, a framework that can be used to interpret and estimate the performance of hybrid systems is presented.
Thesis title: Blockchains vs. Distributed Databases: Dichotomy and Fusion
Authors: Pingcheng Ruan, Tien Tuan Anh Dinh, Dumitrel Loghin, Meihui Zhang, Gang Chen, Qian Lin, Beng Chin Ooi
论文链接：Blockchains vs. Distributed Databases | Proceedings of the 2021 International Conference on Management of Data (acm.org)
Introduction to Blockchain and Distributed Databases
From the point of view of data structure, the blockchain is a list of blockchains connected by hash pointers, and each block contains a series of transactions; from the point of view of the system, the blockchain is a chain of multiple Nodes that do not trust each other jointly maintain a distributed system of consistent ledgers across the entire network.
Blockchains can be divided into permissioned and permissionless chains. The non-licensed chain is completely open, and everyone is qualified to account and read data, such as Bitcoin and Ethereum. The permission chain has certain access mechanism and permission control, such as Hyperledger Fabric. Although the underlying design of the early blockchain is completely different from that of the database, after smart contracts are applied to the blockchain, users can freely deploy and run Turing-complete code, which makes the blockchain and database comparable. Therefore, the paper compares the blockchain and database with contract capabilities.
A distributed database is a database in which data is stored in different physical locations. For many years, traditional relational databases have been the mainstream. Due to practical reasons such as big data processing and hardware development, in order to achieve high availability and scalability of the system, distributed systems began to evolve. Under this new design trend, NoSQL and NewSQL appeared.
In order to enhance the scalability of the system, NoSQL abandons the relational model of traditional databases and strong ACID semantics. NoSQL has a more flexible data storage structure, such as Key-Value (key-value) storage, column storage, document storage and so on. NoSQL has weaker consistency and can achieve eventual consistency, sequential consistency, or causal consistency, etc. The design of NoSQL is more flexible, but it increases the complexity of upper-layer applications.
NewSQL is a design between relational databases and NoSQL. It retains the data model of relational databases and support for ACID semantics, and at the same time has NoSQL’s storage management capabilities and scalability for massive data.
The following figure shows the trade-off between security and performance of distributed databases and permissioned and permissionless chains.
The classification method proposed in the paper is shown in Fig. Below, we will introduce them one by one from four aspects:
Replication is a technique for storing copies of data on multiple nodes in a system.
From the perspective of the replication model , the blockchain replicates an ordered transaction log. The unit of replication is the transaction. The transaction contains application-level information such as transaction context, signature, and timestamp, and is easy to verify. The word “transaction” is expressed as a logical calculation performed on the underlying data, whether in a blockchain or a database, is a sequence of operations. In the blockchain, a transaction is expressed in the form of contract deployment and invocation, which can be regarded as what we usually call a transaction. For example, when a contract is invoked, it will cause a sequence of operations on the data. This sequence of operations is atomic, or The execution is completed, or it is not executed, and the state of the system will change after completion.
A distributed database replicates an ordered log of read and write operations, one operation at a time. As shown in the figure, a trusted transaction manager is required for coordination, and when the unit of replication is a more fine-grained operation, the system is more convenient to achieve concurrency.
From the perspective of replication methods , blockchains and distributed databases can choose different methods for data replication. The paper summarizes the replication methods as primary backup replication and state machine replication , in which state machine replication is further divided into two types: consensus protocol and shared log .
Primary-backup replication means that one of the primary replicas identified in the replica runs a deterministic state machine, while the backup only stores the state. The primary database computes a new series of application states through processing operations and forwards these states to each backup in the order in which they were generated. That is, the entire state of the primary replica is transmitted to the standby server in real time; while state machine replication allows each replica to implement a deterministic state machine. Essentially maintaining an ordered log of operations or transactions on each replica. Each replica starts from the same initial state and then applies the operations or transactions in the log in the same order.
The difference between consensus protocol-based replication and shared log-based replication is that the latter relies on a trusted external service to provide a shared log, which is executed on each replica to change state.
From the perspective of fault models , the fault problems that blockchain and distributed databases need to solve are different, which determines the different characteristics of the consensus layer and upper-layer applications of the two.
In a distributed database, nodes belong to trusted internal systems, so they only need to tolerate node downtime. Databases usually use the CFT protocol (Protocols that tolerate crash failures), such as Paxos and Raft; in blockchain, each node needs to Consensus is reached without mutual trust, so malicious behavior of nodes needs to be tolerated, so blockchains often use more expensive BFT protocols (Protocols that tolerate Byzantine failures), such as PBFT, PoW, etc.
The figure shows the network scale that CFT and BFT protocols need to achieve in different network models. A synchronous network is a network with a bounded and known delay, while the delay in an asynchronous network may be infinite. where f is the number of faulty nodes.
Concurrency refers to having transactions or transactions execute at the same time. Concurrency control technology in the database field has always been a research hotspot, and good concurrency optimization can greatly improve the performance of database systems. Transactions in the blockchain are often executed serially, and concurrency technology is not used much. The main reason is that transaction execution is not a performance bottleneck in many blockchain systems. Secondly, because transactions often share contract state data, It is therefore simpler and safer to execute transactions serially.
Storage determines the mechanism by which data is stored in the system.
In terms of storage model , most databases only store the latest data information that can be modified, even if there is historical information, it is only used as a log for node failure recovery; while blockchain stores all historical data, and only increases way of maintenance.
In terms of indexing , in order to support the correctness verification of data, the blockchain will use a data structure like Merkle Tree to store data; while distributed databases pay more attention to performance, and make special optimizations according to the nature of the hardware when creating indexes, for example, The data in the hard disk is stored in a B+ tree data structure, while the data in the memory is stored in a structure such as FAST or PSL which is more friendly to multi-core parallelism and cache.
Sharding is also a commonly used technology in the database field. It distributes data into different shards and processes them by nodes in the shards, so as to expand the system or improve processing performance.
The shard formation protocol determines which shard nodes and data should be allocated to. The database can be sharded according to the hash calculation result of the data, the range of the data, etc., while the blockchain pays more attention to security, and the shard must be large enough to avoid the number of malicious nodes in the shard exceeding the security assumption. In addition, The allocation mechanism of shards should also not be affected by node behavior.
The atomicity of shards requires that a transaction across shards is either committed or aborted in all shards it involves, exhibiting consistent behavior. In a distributed database, atomicity is generally guaranteed by a two-phase commit protocol (2 Phase Commit, 2PC), which needs to rely on a trusted coordinator, and the blockchain lacks such a coordinator, so the BFT protocol is introduced to coordinate cross-shard transactions.
Finally, according to the described classification method, the paper also gives the analysis and comparison of some system designs.
The performance experiment mainly selected two license chain systems, Quorum and Fabric, and two distributed databases, TiDB and etcd.
Quorum is a branch of Ethereum’s Go language implementation. It adds transaction and contract privacy, permission management, and Raft-based consensus mechanism to Ethereum. It packages blocks in an order-execute form; Fabric It is a sub-project of Hyperledger, a global collaborative project sponsored by the Linux Foundation, and its architecture model is execute-order-validate; TiDB is a NewSQL database, which inherits most of the features of MySQL and consists of three Independent module composition: PD is used for coordinating cluster management, TiKV is used for KV storage, server parses and schedules SQL queries; etcd is a NoSQL database, which uses the kv data model with relaxed transaction restrictions, focusing on the relationship between availability and consistency balance.
For a fair comparison, the experiments have every node in all systems have a full copy of the state data. For Fabric, transactions are executed and endorsed by all peer nodes, and the number of ordering nodes is fixed to three. Quorum and Fabric use the Raft protocol.
The experiments are analyzed from five perspectives, namely peak performance , and the four aspects of the above taxonomy, namely replication , concurrency , storage , and sharding .
In terms of peak performance , the performance gap between blockchain and distributed databases is quite large.
Here each system is populated with 100K records, each 1KB in size. Record throughput and latency under update-only and query-only workloads. TiKV, as the underlying distributed database module of TiDB, also participated in the comparison.
It can be seen that NoSQL performs better than NewSQL because they do not incur the overhead of supporting ACID transactions. In addition, the throughput of TiDB is still 4 times higher than that of the better performing blockchain Fabric.
In terms of replication , the transaction-based replication model affects the concurrency capability of the system, which has a major impact on system performance.
Figure 7 compares the impact of transaction-based and operation-based replication models according to the performance of Fabric and TiDB . Besides having higher latency compared to TiDB, Fabric’s latency also increases significantly when the system is saturated. And when the request rate exceeds the system capacity, the verification phase becomes a bottleneck. The paper argues that the increase in latency is due to serial verification in Fabric, where blocks and transactions within blocks are verified sequentially before committing.
Figure 8 shows the throughput of the four systems as a function of the number of nodes. Among them, Fabric’s replication method is based on shared logs, while others are based on consensus protocols. The throughput of Fabric decreases as the number of nodes increases, and it is observed in the experiment that the delay of block verification increases, because the endorsement policy is set so that all peer nodes must endorse a transaction. Quorum uses the raft protocol, but the performance is not sensitive to the number of nodes. This is because of Quorum’s order-execute architecture, the process of packing blocks is performed sequentially.
Figure 8 represents a comparison of the throughput of Raft and IBFT consensus protocols in Quorum to analyze the performance impact of different failure models . In a larger network, the throughput variance of IBFT is larger. This is because IBFT needs to communicate with more nodes than Raft to avoid master node switching, and the more malicious nodes, the higher the probability of re-election of master nodes. large, the probability of transaction interruption will increase.
In terms of concurrency , blockchains with execute-order-validate architecture have lower performance under high contention and highly constrained workloads.
Figure 9 shows the effect of skewness on performance. Each transaction modifies a record, and the key value of the record obeys the Zipfian distribution. The distribution changes according to the skewness coefficient θ. The larger the θ, the greater the possibility of modification conflict and the greater the competition. It can be seen that when the competition occurs, the throughput of TiDB drops sharply; etcd and Quorum execute transactions serially without concurrency control; and Fabric performance drops by 31%, which is due to Fabric’s optimistic concurrency control mechanism for read and write conflicts. Transaction aborted. Furthermore, TiDB’s throughput drops disproportionately to the increase in transaction abort rate because its latching mechanism consumes more time.
Figure 10 Increases the number of operations in each transaction to observe the effect of transaction atomicity on performance. As can be seen from the left graph, the performance of Fabric, TiDB and etcd degrades when the number of operations per transaction increases. This shows that more operations lead to conflicts, and that TiDB transactions may span multiple shards; the right figure shows the transaction abort rate of TiDB and Fabric as a function of the number of operations. The transaction abort in TiDB is mainly due to write-write conflicts, while in Fabric, inconsistent reads and read-write conflicts are caused. Inconsistent reads may be due to the different rates of peer nodes that require pre-execution and endorsement transactions to submit blocks.
Figure 11 shows the impact of the record, ie the size of the data that needs to be processed, on performance, from the graph on the left it can be seen that as the record grows, the performance of almost all systems degrades. And Quorum’s throughput dropped significantly. The figure on the right analyzes the details of the transaction latency of Fabric and Quorum. In the Commit stage, Quorum introduces the cost of the hash function due to the reconstruction of the MPT (Merkle Patricia Trie) data structure, and the delay of the Proposal stage and the Commit stage increases at the same speed. Because Quorum’s order-execute architecture enables transactions to be serially verified at the node that packs the block and other nodes after consensus, in contrast, Fabric’s serial processing is only once.
In terms of storage , the ledger abstraction model in the blockchain incurs a large storage overhead, in addition, the security overhead required to protect the state data from tampering is small.
The graph shows the impact of record size on storage overhead. The storage overhead of Fabric is much higher than that of TiDB because of the abstract model of the ledger chain of the blockchain in Fabric. The figure on the right compares the MBT (Merkle Bucket Trie) in Fabric and Quorum’s MPT. The overhead of MBT is smaller because its tree structure size is fixed.
In terms of sharding , the performance of sharded blockchains lags far behind distributed databases due to the security requirements of shard formation and periodic reconfiguration.
TiDB, AHL, and Spanner are used here. AHL is a Fabric-based sharded blockchain, and Spanner is a cloud-based NewSQL database. As shown in Figure 14, when the number of nodes increases, the throughput of TiDB is higher than that of Spanner, because once a conflict is detected, TiDB will immediately abort the transaction, while Spanner uses a pessimistic concurrency control mechanism, in the case of transaction conflict Locks will be contended for; AHL that periodically reconfigures shards for greater security has a 30% reduction in performance compared to shard-fixed AHL. However, due to the high cost and other security overhead of the PBFT protocol, the performance gap between AHL and databases is still large.
According to the above research and analysis, the paper finally proposes a framework that can be used to analyze and predict the hybrid system, however, only the throughput is used as the evaluation index.
It can be seen that the replication model and failure model greatly affect the system performance. Transaction-based replication does not have as good concurrency as operation-based replication, so throughput is low. Compared with the BFT protocol, the network overhead of the CFT protocol is lower.
This paper systematically discusses and summarizes the design differences between blockchain and distributed databases, and presents a classification method consisting of four dimensions of replication, concurrency, storage, and sharding. The design orientation of some existing systems is analyzed, and the corresponding performance tests are carried out. The experimental results are used to illustrate the impact of the underlying design choices on performance. Finally, a framework for evaluating and estimating system throughput is provided. The work of the whole article is complete and detailed, which is conducive to understanding the design connection and difference between blockchain and database, and understanding the current research work on the integration of blockchain and database from a more detailed and methodical perspective.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/blockchain-vs-distributed-database-whats-the-difference/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.