一文详解区块链的存储体系

UTXO的机制可以有效地在无锁的情况下避免双花问题，但是其劣势则在于不存储余额表，所有的信息均通过重做流水数据，从零开始生成。对于一个存在了十年以上，包含几百亿笔交易的系统来说，这样的做法就好比每次重启都要从都重做几百笔交易并存入内存中(或KV数据库里)，是一种非常原始且不经济的方式。

另一方面，区块链日志的结构看来，由于多活系统中全局锁很难实现，因此需要通过交易日志结构的调整来满足传统数据库中事务的功能。传统数据库中当涉及到两账户之间转账操作时需要开启一个事务。在事务日志中一个账户增加一个账户减少的业务逻辑，需要体现为包含三条记录的链表(最后的提交操作也是一个记录)。在数据库崩溃或发生异常后，只要通过重做所有的任务，并最后对全部没有提交记录的事务进行反向操作，即可得到原子性(Atomic)与持久性(Durability)。

而在区块链体系中由于不存在事务的概念，同时操作日志与结算业务进行了紧密耦合，因此每条交易记录都会包含一个输入账号以及若干个输出账号，也就是说只要一条事务记录被成功发送给一个节点，则可以保证在该记录内部的全部输入输出账户统一进行了变更。可以说，区块链通过定制化交易日志简化了事务操作的复杂性，但是带来的影响便在于业务与代码的紧密耦合不可分割。

但是无论如何，首先UTXO并不是通用数据结构，而是为交易业务高度定制化的数据结构，如果想要运行图灵完备的智能合约(或者说存储过程)，使用UTXO会有很多局限性。第二，对长期运行的大型系统(相比起大中型银行核心交易系统所产生的交易流水，比特币从诞生到现在的交易量少得可以忽略不计)，UTXO每次初始化需要全部的历史交易日志。这种模式完全不可能适用于大型交易系统。

因此，可以存在两种做法解决该问题。第一种方式使用传统账户表与流水表的机制，将UTXO以流水的方式体现出来，同时定期保存账户快照，以避免每次重构数据库都需要重做全部交易(这种机制需要考虑到账户与流水表在多活系统中，没有全局锁的情况下如何实现一致性的问题)。而对于非结算类交易，通用型区块链项目则可能采用日志结合用户数据存储的模式，才能够普适性地满足通用业务需求(这种机制需要依靠比nonce更好的排序机制避免双花)。

5. 索引存储

当前基本没有任何区块链项目支持用户数据的自定义索引。这种机制在未来的通用型区块链项目一定会被弥补。从本质上看当前的区块链项目结构没有任何理由无法在其上构建通用索引能力(包括B树索引、位图索引、全文检索等)。

小结

区块链的存储体系现在还处于数据库上世纪80年代的阶段，其当前最大的问题在于日志结构与业务逻辑的紧密耦合(读者可以理解为应用程序为每种业务逻辑都要从头实现一遍Oracle)。而这样做的本质原因在于多活数据库中事务的原子性与锁极难保障，因此当涉及到多个账户的转账原子操作时，当前大部分账本类区块链项目均不得不定制日志结构，将每一笔交易的全部信息放在一条记录中。从数据库的角度看，在区块链项目中实现跨记录的原子操作(包括全局锁)极为复杂，而这也正是区块链技术向通用型数据存储进化的关键所在。

笔者认为，随着区块链应用越发广泛，人们在不久的将来一定会将各类区块链应用泛化出一系列典型的场景和需求。基于这些场景和需求，一定会出现一批优秀高效的多活数据存储。不论这些机制的后台到底是否基于“区块”的架构实现，其这正需要突破的是现有数据库体系中无法做到active-active的局限(也就是去中心化)。

本文章素材来自互联网

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!