一、存储层业务需求每种类型的数据都有自己特殊的业务场景,相应的会有自己特有的读写需求:1. 交易:每个交易对应一个AccountBlock,在Vite中可以通过交易的哈希值或地址来查询交易,还可以根据关联关系查询SendTx和ReceiveTx之间的关联。2. 快照:快照链中的SnapshotBlock记录了该块快照的全部交易的快照信息,可以通过快照块和交易之间的关联来查询。3. 账户状态和虚拟机状态:这两类数据都是绑定在地址上的存储结构,区别是账户状态关联一个普通地址,而虚拟机状态关联的是合约地址。由于状态可能会被修改,需要支持多版本来满足更新、回溯和回滚操作,同时还要支持状态变化的trace输出。
二、总体设计根据不同类型数据的读写需求,存储层设计的原则是在底层通用方案的基础上进行了一些定制,并对下游模块提供友好的接口。
1、通用方案设计为了提供支撑和提高系统的可靠性,我们设计了以下几个通用方案:a、小文件存储:使用固定大小的小文件对两种类型的块进行暂存和永久性存储,适合区块链这样基于海量交易的数据结构。b、索引:通过levelDB实现索引存储,适合追加写入多、更新少的场景。c、缓存:利用内存性能来加速读取,采用一定的策略存储热点数据。d、异步flush:通过异步方式提高IO性能,并保证数据的一致性。e、数据压缩:为减少存储量,可以选择压缩后再进行持久化。
2、具体实现根据具体业务需求,存储分为以下三个模块的实现:a、blockDB:用于存储AccountBlock和SnapshotBlock,在小文件中存储多个块,减少碎片并方便索引。b、indexDB:用于levelDB索引blockDB中块的位置,同时存储块之间的关联关系。c、stateDB:用于存储账户状态和虚拟机状态,通过levelDB的key来支持多版本数据。
三、总结通过以上介绍,我们了解到Vite存储层根据业务需求进行了模块拆分,并建构在几个通用方案上。后续的文章将详细介绍每个子模块的设计细节,敬请期待。
本站所有软件信息均由用户上传发布,版权归原著所有。如有侵权/违规内容,敬请来信告知邮箱:764327034@qq.com,我们将及时撤销! 转载请注明出处:https://czxurui.com/zx/73158.html
发表回复
评论列表(0条)