【存储专栏】连续型数据高效存储之道

【前言】

在《打破K/V存储的性能瓶颈》中，我们提到区块链中的数据可以分为「连续型数据」和「K/V型数据」，并对K/V型数据的特点及读写进行了阐述。我们以leveldb为例，了解到K/V数据在存储时采用LSM-Tree的组织形式，存储方式相对而言比较复杂，数据读写的复杂度也较高，且在数据量大的情况下会遇到性能下降的问题。针对这些问题，我们已经提出了一些优化思路，但这种数据格式读写的性能存在天然的缺陷。而优化思路里也提到，leveldb的归并操作是为了让SSL Table的key变得有序，说明有序的数据在读写方面有天然优势。

区块链中也有很多数据是有序的。因此，本文将重点讨论连续型数据的特点和连续型数据的读写方式，并根据实际场景中会遇到的问题提出我们的优化思路。

【连续型数据的特点】
连续型数据，顾名思义，最大的特点就是连续。我们可以把连续型数据当做一种特殊的K/V数据，只不过其key值是单调递增的。
“那么在区块链中，什么样的数据是连续的呢？”

区块链中有一个重要的概念：区块号，就是单调递增的。区块链是一个账本，记下来的账是只增不减的，区块也是不断向后追加的。因此，以区块号为单位存储的数据就可以认为是连续型数据。在上一篇推文中，我们提到除了区块数据以外，回执数据、修改集数据也是连续型数据，这是因为每一条回执，每一条世界状态修改记录，都对应于一笔交易，而交易是区块的组成部分，因此这些数据也可以以区块为单位来存储。

任何数据存储的目的都是为了查询，因此我们在存储连续型数据的同时，需要考虑对这些数据的查询需求。一般来说，对于区块和交易数据，会有以下查询需求：

1）给定一个区块号，查询对应的整个区块数据；

2）给定一个区块哈希，查询对应的整个区块数据；

3）给定一个交易哈希，查询这笔交易的详细信息；

面对这样的查询需求，我们在设计数据库时需要考虑如何支持这些查询。

▲ 以太坊
连续型数据作为一种特殊的K/V型数据，自然也可以用K/V数据库来存储，例如以太坊就是这样存的。在以太坊中[1]，所有数据均存储在leveldb中，区块和交易相关的数据存储方式如下：
(H) + Block Hash -> Block Number
(h) + Block Number