Part 1 – BadgerDB 设计架构
Badger[1] 是基于论文：WiscKey: Separating Keys from Values inSSD-conscious Storage[2] 的思维利用 Go 语言进行设计实现的。
LSM-Tree 的劣势在于将随机写转换为程序写，将大块的内存间断地写入到磁盘，缩小磁盘寻址的工夫，同时数据是依照 key 排序，查找起来速度快，同时也带来了写、读放大。LSM-Tree 的这些优化很实用 HDD，然而 SSD 的性能却受到限制（写放大）。因而，Wisckey 提出了一种面向 SSD 的，将 key-value 拆散存储的办法。
上面先剖析一下 LSM-Tree 写、读放大。写放大次要是因为各个层级之间的 Compaction，当两个层级之间做 Compaction 时，都须要将多个 SSTable 读到内存排序（读放大），而后写到磁盘。读放大次要是在 LSM-Tree 中查找一个 key 时，个别查问流程是 MemTable、Immutable MemTable 以及 SSTable。如果该 key 不存在，尽管 MemTable 和 Immutable MemTable 是内存操作很快，然而在 Level 0 层的 SSTable 中 Key 是全局无序的，可能还有重叠，须要全扫，更高层级的 SSTable 中也须要二分查找，尽管有 bloom filter 然而仍旧影响查找的效率。图 1 中展现了 LevelDB 中写、读办法的测试，数据集大小分为 1G 和 100GB，其中 Key 大小为 16B，Value 大小为 1KB。
图 1 LevelDB 的写、读办法
Wisckey 提出的优化是：Key-Value 拆散存储。LSM-Tree 外面存储的是一个 Key 以及 Value 的地址，Value 自身以 WAL 形式 append 到 Value Log 文件中。这样在做 Compaction 的时候就只须要重写 Key 以及 Value 的地址就能够了，SSD 中数据的散布如图 2 所示。因而，在 Key size 远远小于 Value size 的场景中升高写放大的效果显著。然而当 Value 很小的时候，重写 Value 的开销就很小，Key-Value 拆散带来的益处不足以对消其自身的开销（读写 Key-Value 须要操作不同的文件，在 range query 的场景下，会产生屡次的随机 IO）。
图 2 Wisckey 中数据在 SSD 中的分部
基本操作流程：
写流程：先把 Valueappend 到 Value Log（为了便于 GC 操作也会写入 Key），而后把 Key 以及 Value 的地址（<vLog-offset,value-size>）写入 LSM-Tree 的 MemTable 中，而后依照肯定策略利用 MinorCompaction 将 MemTable 写入 SSTable。
读流程：先从 LSM-Tree 外面读取 Key 对应 Value 的地址，而后从 ValueLog 读取 Value。
删除流程：只需把 Key 从 LSM-Tree 外面删除，无需操作 ValueLog。Value 由 GC 机制进行解决。
因为 LSM-Tree 做 Compaction 时不须要重写 Value，大大减小了写放大。同时 LSM-Tree 更小，一个 Block 能存储更多的 key，也会相应的升高读放大，能缓存的 Key 以及 Value 地址也更多，缓存命中率更高。
面临的一些挑战：
RangeQuery：Range query 容许用户查问一段有序 range 内的 KV 对，能够对其进行遍历。当发动一次 rangequery 的时候，最终会被转换为对 Value Log 的屡次随机读，而对 LSM-Tree 则是程序读。因而在 Value 小的状况会减少了提早。
该场景下，Wisckey 会通过充分利用 SSD 并行 I/O 个性，在 range query 时对 Value Log 中的 Value 进行预取缓存。预期缓存对于大范畴的 range query 成果比拟显著，然而对于小范畴的 range query 可能作用不大。依据论文的试验数据如图 3 所示（100GB 的数据集中查问 4GB 数据），当 value 大于 4KB 时，读的性能才体现进去。
图 3 范畴查问性能
GC：因为删除操作只会删除 LSM-Tree 外面的 Key 以及 Value 地址，不会删除 ValueLog 的 Value。
如图 4 所示，Wisckey 在 Value Log 中会存储元组（keysize, value size, key, value）同时会存储 <head,head-vLog-offset> 以及 <tail,tail-vLog-offset>，用来标识最初做 GC 的地位。会从 tail 开始扫描 Value Log，获取 Key-Value。为了不影响在线服务，会每次取出 Value Log 最旧的一部分数据 (MB)，通过读取 LSM-Tree 来验证其有效性，如果过期或者被删除则抛弃；无效则 append 写入到最新的 vlog，而后更新 tail 的值，并删除 tail 之前的数据，通过 fallocate() 开释有效的文件磁盘空间。如图 5 所示，Wisckey 在 GC 是的性能在所有状况下至多比 LevelDB 快 70 倍。
图 4 Wisckey 中 GC 解决的数据结构
图 5 Wisckey 的 GC 性能
一致性：Wisckey 是先写入 Value Log，再写入 LSM-Tree，所以会有以下几种失败状况：vLog 写入失败；vLog 写入胜利，LSM-Tree 写入失败；vLog 写入胜利，LSM-Tree 写入胜利后立即解体。
在 Wisckey 中 vLog 写入失败，则 LSM-Tree 必定写入失败。可能会残留局部 vLog 数据，由 GC 机制来回收。vLog 写入胜利，LSM-Tree 写入失败：此时 vLog 的值便成了垃圾数据，会有 GC 机制来回收。vLog 写入胜利，LSM-Tree 写入胜利后立即解体：Wisckey 中勾销了 LSM-Tree 的 WAL，所以写入 LSM-Tree 也仅仅是写入了内存的 MemTable，此时程序或者机器产生解体 LSM-Tree 的数据依旧会失落。Wisckey 的做法是保留元组（key size, value size, key, value）以及 <head, head-vLog-offset> 在 vLog 中。每次 Open 数据库的时候，读取 vLog 中 head 的值，而后顺次读取 head-vLog-offset 之后的记录，并将 Key 以及 Value 地址写入到 LSM-Tree，最初更新 head 的值。如果更新 head 的值产生解体也无所谓，只不过再次 Open 数据库的时候多重放一点记录罢了。
Wisckey 中 Key-Value 拆散的策略在大 Value 场景下效果显著，然而对于小 Value 性能不如 LSM-Tree。为此在 BadgerDB 中设置一个 Value 阈值，当 Values 大小超过阈值时该 Value 存入 vLog，小于阈值时存入 LSM-Tree。
图 6 BadgerDB 整体架构
BadgerDB 是基于 Wisckey 论文实现的，整体架构相似 LevelDB，具体如图 6 所示，区别就在于去掉了 LSM-Tree 外面的 WAL，用 vLog 代替。在实现上，去掉了 current 文件。
性能个性：
反对罕用的 Get、Put、Delete、Batch 等操作。
实现了 SSI 隔离的 Transaction，反对读、写事物。
所有的操作都是以 Transaction 执行的。
反对 MVCC，反对多版本的 Key-Value。
反对对 key 设置 TTL 以及 UserMeta。
所有的 Key 都是有序存储的，反对 Iteration 和 Prefix-Scan。
反对 Key 的 Compaction 以及 Value 的 GC。
Part 2 – 云溪数据库中的 RAFT 算法
云溪数据库是分布式数据库，与 CockroachDB 等一样都是 NewSQL 家族的一员。云溪数据库具备强统一、高可用的分布式架构，可能程度扩大提供企业级的平安个性齐全兼容 PostgreSQL 协定，可能为用户提供残缺的分布式数据库解决方案。云溪数据库的整体架构如图 7 所示，云溪数据库的强一致性是由 Raft 算法 [3] 保障分布式多正本之间数据强一致性以及内部读写的一致性，简言之云溪数据库中数据会有多个正本，这些正本寄存在不同的机器上，当其中一台机器故障宕机后数据库仍旧可能对外提供服务。云溪数据库会依据插入数据的键，将数据划分为多个 Range，每个 Range 上的数据都有一个 Raft Group 来维持多个正本之间数据的一致性。因而，精确地说云溪数据库应用的是 Multi-Raft 算法。
图 7 云溪数据库的整体架构
利用单机的 RocksDB，云溪数据库能够将数据疾速地存储在磁盘上；利用 Raft 算法，能够疾速地将数据复制到多台机器上，以防单机故障。数据的写入是通过 Raft 算法接口写入，而不是间接写 RocksDB。通过 Raft 算法，云溪数据库变成了一个分布式的键值存储系统，不超过集群半数的机器故障宕机齐全可能通过 Raft 算法主动把正本补全，能够做到业务对故障无感知。在后期，云溪数据库中 Raft 算法采纳的是开源的 etcd-raft 模块 [4]，该模块次要提供如下几点性能：
Leader 选举；
成员变更，能够细分为：减少节点、删除节点、Leader 转移等；
日志复制。
云溪数据库利用 etcd-raft 模块进行数据复制，每条数据操作都最终转化成一条 RaftLog，通过 RaftLog 复制性能，将数据操作安全可靠地同步到 Raft Group 中的每一个节点上。不过在实际操作中，依据 Raft 的协定，只须要同步复制到少数节点，即可平安地认为数据写入胜利。
Part 3 – Raft Log 拆散与定制存储
在 etcd-raft 模块中，Raft Group 中的 Leader 节点接管客户端发来的 Request，将 Request 封装成 Raft Entry（Raft Log 的根本组成单元）追加到本地，并通过 gRPC 将 Raft Entry 发送给 Raft Group 中其余 Follower 节点，当 Follower 节点收到 Raft Entry 后进行追加、刷盘以及回复处理结果的同时，Leader 将本地 Raft Entry 进行刷盘，两者同步进行。等 Leader 节点收到过半数节点的必定回复后，提交 Raft Entry 并将其利用到状态机（将 Raft Entry 中蕴含的业务数据进行长久化），而后将处理结果返回客户端。
从下面的剖析中能够看出 RaftLog 在正本之间达成共识、节点重启以及节点故障复原等环节都起到至关重要的作用，RaftLog 与业务数据独特存储在同一个 RocksDB 中，在查问高峰期必然会产生磁盘 I/O 资源争抢，减少查问期待时延，升高数据库的整体性能。在 TPCC 场景下进行了 Raft Log 与业务数据写入量的测试，测试场景如下：在物理机（CPU：6240 72 核 内存:384G 零碎硬盘：480G 数据盘：375G+SSD 硬盘:2T*7）上启动单节点云溪数据库服务，零碎稳固后 init 6000 仓 TPCC 数据，察看整个过程中业务数据与 Raft Log 写入量的大小，测试后果如表 1 所示。
表 1 TPCC 初始化过程数据量统计
同时发展了 TPCC 场景下针对 Raft Log 各项操作数量的测试，测试场景如下：启动 3 个节点的云溪数据库集群，零碎稳固后 init 40 仓 TPCC 数据，察看网关节点在整个初始化过程中 Raft Log 各项操作数量的变动，测试后果如表 2 所示。将 RaftEntryCache 的大小从 16MiB 减少到 1GiB 后，雷同场景下 Term 与 Entry 的查问数量降落到 0。
表 2 TPCC 初始化过程 Raft Log 各项操作统计
根据上述测试以及测试后果，可将云溪数据库中 Raft Log 的操作特点总结如下：
- 在失常运行过程中，插入和删除操作是最多的且数量也很靠近，阐明 Raft Log 长久化的工夫很短。查问 RaftLogSize 也是较为惯例操作，其余操作都是在非凡场景下触发的，简直能够忽略不计。
- 查问 Term 与查问 Entry 的操作次数取决于 RaftEntryCache 的大小，是由云溪数据库外部实现机制决定的，Entry 和 Term 的查问个别先去 Unstable 中查找，查找不到再去 RaftEntryCache 中查找，还是查找不到就到底层存储中查找。通常状况下 RaftEntryCache 大小设置正当的话能够命中所有查找。
- 云溪数据库理论运行过程中产生的 Raft Log 比真正长久化的业务数据多很多（5~10 倍），而且只有数据库继续运行（即便没有任何用户查问）就会源源不断的产生 Raft Log。Raft Log 是用户数据的载体，为了保障数据完整性和一致性 Raft Log 必须长久化。
- 云溪数据库中存储 raft Log 的引擎面临的真正挑战是频繁写入、删除以及短暂的存储给零碎带来的性能损耗。
通过对云溪数据库中 Raft Log 操作场景的详细分析，总结 Raft Log 存储引擎应该满足如下特色：
尽可能将待查问数据保留在内存中，缩小不必要磁盘 I/O;
写入的数据可能及时落盘，保障故障复原后数据的完整性和一致性；
可能及时地清理被删除数据或是提早清理被删除数据，缩小不必要的资源占用。
针对这个问题，目前一些支流 DB 的解决方案是：每个 KV 实例中有两个 RocksDB 实例，一个用于存储 Raft 日志（通常被称为 raftdb），另一个用于存储用户数据以及 MVCC 信息（通常被称为 kvdb）。同时，还开发了基于 RocksDB 的高性能单机 Key-Value 存储引擎。在云溪数据库中间接应用 RocksDB 来存储 Raft Log 是不适合的，不能很好地满足 Raft Log 的具体应用场景。RocksDB 外部采纳 LSMTree 存储数据，在 Raft Log 频繁写入疾速删除并且还会继续进行随机查问的场景下，造成重大读放大和写放大，不可能充分发挥出 RocksDB 的劣势，也对系统整体性能造成不利影响。
研发团队在具体调研剖析 LevelDB、RocksDB、BadgerDB、FlashKey 以及 Aerospike 等的具体架构与特色后，决定基于 BadgerDB v2.0 的根底上进行定制优化，作为云溪数据库中 Raft Log 的专用存储引擎。Raft Log 定制存储实现了以下基本功能：
Raft Log 的批量写入与长久化；
Raft Log 的程序删除与提早 GC；
Raft Log 的迭代查问，包含：RaftLogSize 查问、Term 查问、LastIndex 查问以及 Entry 查问；
相干 Metrics 的可视化；
多引擎场景下的用户数据残缺与统一保障策略。
云溪数据库中 RaftLog 定制存储整体部署架构如图 8 所示：
图 8 Raft Log 定制存储整体部署架构
部署时 BadgerDB 须要与 RocksDB 并列进行部署，即一个 Node 上部署相等数量的 RocksDB 实例和 BadgerDB 实例（由目前云溪数据库中正本均衡策略所决定）。查问申请的大抵解决流程是先将 Raft Log 写入 BadgerDB，期待集群过半数节点达成共识后，再将 Raft Log 利用到状态机，行将 Raft Log 转化成用户数据写入到 RocksDB，用户写入胜利后再将 BadgerDB 中已利用的 Raft Log 删除，同时将状态数据更新到 RocksDB 中。
云溪数据库中 Raft Log 定制存储的写、读流程如图 9 所示。
图 9 RaftLog 定制存储写、读流程
因为 Raft Log 定制存储采纳 Key-Value 拆散的策略，残缺的 Key-Value 数据首先写入 VLog 并落盘（如果是删除操作则在落盘胜利后由 IfDiscardStats 更新内存中保护各 VLog File 的删除数据的统计信息，这些统计信息也会定期落盘。防止了 BadgerDB 中 SSTable 压缩不及时导致统计信息滞后的问题），而后将 Key 以及元数据信息写入 Memtable(skiplist)。将 Level 0 SSTable 放入内存，同时将须要频繁查问的信息（RaftLogSize、Term 等）记录到元数据放入内存，放慢随机读取的效率，缩小不必要的 I/O。
已删除 Key 的清理依赖 SSTable 的压缩，对应 Value 的清理则须要云溪数据库周期性调用接口，首先依据拜访 IfDiscardStats 在内存中保护的 VLog file 的 discardStats，对备选文件进行排序，程序遍历进行采样，若能够进行 GC 则遍历 VLog File 中的 Entry，同时到 Mentable(或 SSTable) 查看最新元数据信息确定是否须要进行重写，须要重写则写入新的 VLog File，不须要则间接跳过，Raft Log 定制存储中 GC 解决流程如图 10 所示。
图 10 RaftLog 定制存储 VLog GC 流程
在将 Raft Log 进行独立贮存后，必须要思考多个存储引擎数据放弃一致性的策略。Raft Log 存在的目标是为了保障业务数据的残缺，因而在 Raft Log 与业务数据离开存储后不谋求两者完全一致，而是 Raft Log 放弃肯定的“冗余”。具体策略是每个 range 上先将 AppliedIndex 以及对应的 Term 同步写磁盘，当 RaftLog 积攒到肯定数量后再去磁盘上读取后面落盘 AppliedIndex 以及对应的 Term 进而生成 TruncateState 进行 RaftLog 的删除。
研发团队实现上述优化后，发展了“迭代查问性能比照测试”与“TPCC 场景性能测试”。在“迭代查问性能比照测试”中，测试场景如下：启动单机单节点云溪数据库服务，零碎稳固运行后 init 40 仓 TPCC 数据，记录迭代器查问 RaftLogSize 与 Term 的总耗时。Raft Log 别离存储在 RocksDB、BadgerDB 以及 Raft Log 定制存储中，其中 ValueThreshold 设置为 1KB，其余设置均采纳默认值。
表 3 迭代查问测试后果汇总
从上述测试后果来看，在对 Badger 迭代器进行优化后，针对元数据的迭代查问速率失去大幅晋升，相比 RocksDB 迭代查问提早升高了约 90%。
在“TPCC 场景性能测试”中，测试场景如下：在物理机（CPU：6240 72 核 内存:384G 零碎硬盘：480G 数据盘：375G+SSD 硬盘:2T*7）启动单节点云溪数据库服务，零碎稳固后 init 6000 仓 TPCC 数据，察看整个过程中相应监控指标。
表 4 TPCC 压测监控数据汇总表
从上述测试后果来看，Raft Log 采纳定制存储后，raft Log 提交提早降落约 60%，raft Log 利用提早降落约 25%，RocksDB 读放大降落约 60%（高负载），同时没有明显增加资源耗费。
综上，利用键值拆散的思维优化 LSM 树，借助索引模块晋升迭代查问性能，应用统计前置的策略晋升零碎 GC 的效率，可能很好满足云溪数据库中 Raft Log 在各种操作场景下的性能要求。
Part 4 – 后续优化
与故障重启无关的状态数据迁徙至 BadgerDB，进一步缩小 RocksDB 数据的写入量。
利用 RaftLog 与局部状态数据替换 RocksDB 的 WAL，BadgerDB 承当集群故障复原性能，为后续 RocksDB 进一步优化扫清阻碍。
优化 RaftLog 缓存，晋升缓存命中率缩小非必要的读盘，在将状态数据引入到 BadgerDB 后，进一步优化写入、查问性能优化，例如：并行写 MEMTable 等。
[1] https://dgraph.io/blog/post/b…
[2] https://www.usenix.org/system…
[3] https://raft.github.io/raft.pdf
[4] https://github.com/etcd-io/etcd