一、存储层业务需求每种类型的数据都有自己特殊的业务场景，相应的会有自己特有的读写需求：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存储层根据业务需求进行了模块拆分，并建构在几个通用方案上。后续的文章将详细介绍每个子模块的设计细节，敬请期待。
本文来自用户投稿，不代表币大大立场，如若转载，请注明出处：https://czxurui.com/zx/73158.html
发表回复
评论列表（0条）