ZNBase 是凋谢原子开源基金会旗下的首个分布式数据库我的项目，由浪潮大数据团队开源并捐献。本文将介绍 ZNBase 的存储架构，以及 ZNBase 技术团队在其 KV 存储引擎根底上所做的优化实际。
ZNBase 整体存储架构
云溪数据库 ZNBase 采纳分层架构，分为计算层与存储层，其总体架构如下图所示：
在 OLTP 场景下，当开发人员向集群发送 SQL 语句时，数据最终会以键值对 KV 的模式对存储层进行读写。每个 ZNBase 节点启动时，至多会蕴含一个存储节点。存储层默认采纳 KV 存储引擎 RocksDB 负责存储数据。每个存储实例都可能蕴含多个 Range，Range 是最底层的 KV 数据单元。Range 应用 Raft 一致性协定在集群间进行复制。
为了反对 HTAP 场景，ZNBase 的行存数据会通过 Raft Learner 同步到列存引擎，存储层还扩大了矢量接口，通过列式存储、计算下推、多节点并行计算满足业务利用的 AP 需要。另外存储层还扩大了时序接口，能够进行时序数据管理。
接下来将着重介绍 ZNBase 存储层架构中的 KV 存储集群。
RocksDB 引擎
ZNBase 的存储层默认采纳 RocksDB 来存储数据。RocksDB 是由 Facebook 开源的高性能 KV 存储引擎，读写数据能够是任意字节流，其官网架构如图所示，是一种 LSM-Tree 的实现：
RocksDB 写入流程如下：
1、以 batch 模式先程序写入 WAL 文件用于故障复原
2、再写入内存中的 Memtable，Memtable 默认以 SkipList 模式存储
3、Memtable 写满肯定大小，默认 64MB，会转为不可变的 Immutable。
4、异步线程会将 Immutable 刷到磁盘 L0 层，变为 SST 文件。
5、磁盘中应用多层来治理 SST 文件，通过合并过程将下层的 SST 文件落到上层，在合并过程中会进行 GC 清理。
由此可见，RokcsDB 最新的数据是在内存或者下层的 SST 文件里，所以读取时优先读取 Memtable 和 Immutable，再依此读取各层文件。刚写入的热数据，能够更快被读到。另外 RocksDB 还提供了 Block Cache 进行读缓存。
RocksDB 自身是一个 LSM-Tree 架构的高速 KV 存储引擎，读写都会尽量应用内存。RocksDB 提供原子的批量写入、快照等性能，不便下层实现事务管制。基于 RocksDB 也反对高度平安的 AES 算法对存储在磁盘上的数据加密，这样即便磁盘被窃取，磁盘里的数据也无奈被拜访。
因为 RocksDB 采纳 LSM-Tree 架构，同样也存在肯定的问题。比方在大数据量下有比拟高的读放大、写放大、空间放大，性能衰减也比拟厉害。为了进步 ZNBase 在海量数据下的性能体现，ZNBase 团队联合浪潮的硬件劣势，开发了应用 SPDK 驱动在专用硬件 ZNS SSD 上进行软硬件交融的存储引擎；另外为了更无效的利用内存，取得更快的读写速度，在大内存场景下也开发了准内存引擎的实现。
SPDK + ZNS SSD
固态硬盘（SSD）正在迅速扩大它在数据中心中的份额，相较于传统存储介质，新的闪存介质具备性能，耗电，机架空间等等方面的劣势。
而浪潮自研的 ZNS SSD，在容量、寿命、老本、易用性、性能等方面实现飞跃式晋升。ZNS SSD 即分区命名空间固态硬盘，能够将 FTL(Flash Translation Layer)裸露给用户以充分发挥 SSD 性能。ZNS 技术针对云场景利用，主实用于大容量空间存储的数据，例如高清视频、图像等。ZNBase 与 ZNS SSD 集成，通过智能数据部署能够实现更好的空间运⽤，取得升高一倍以上的写放大；文件可依据生命周期进行数据分区隔离，实现最低化垃圾回收；SST 文件可依据 LSM 分层进行清晰化冷热数据拆散，晋升拜访效率；最小化的写放大可晋升读取性能，缩小合并老本和垃圾回收开销；实践上，ZNS SSD 可带来 15% 的性能晋升和 10% 的老本收益。
因为 SSD 自身的物理个性，其数据的拜访相较于传统介质来说曾经十分快了，而性能的瓶颈就是出在计算机与设施连贯的接口和协定下面。举个直观的例子，咱们从北京乘飞机到美国，依照当初的飞行速度，在天上须要 13 个小时。这种状况下，安检的工夫，过海关的工夫，候机的工夫，加起来 3 个小时，绝对于总共的 13+3=16 个小时也不算长。构想如果当初飞机的飞行速度进步了 100 倍，航行工夫从 13 小时缩短至 10 分钟，这时 3 个小时的高空手续流程就显得很没有效率了。换言之，在存储硬件性能高速倒退的明天，存储软件协定栈的性能和效率在存储整体零碎中的位置越来越重要。
SPDK (Storage performance development kit) 由 Intel 发动，提供了一组用于编写高性能、可伸缩、用户态存储应用程序的工具和库。SPDK 的根底是用户态、轮询、异步、无锁 NVMe 驱动，提供了从用户空间应用程序到 NVMe 设施的零拷贝、高度并行的拜访。
NVMe 的全称是 Non-Volatile Memory Express，如果翻译过去就是非易失性内存主机控制器接口标准，是一种新型的存储设备接口标准，用于定义硬件接口和传输协定，领有比传统 SATA SSD 的 AHCI 规范更高的读写性能。咱们能够把 NVMe 看做一个硬件提高推动软件变革需要的例子，随着后续更快的存储介质投入市场，这种推动力将更为急切。
SPDK 我的项目也是一种硬件提高推动软件变革的产物，其指标就是可能把硬件平台的计算、网络、存储的最新性能停顿充分发挥进去。那么 SPDK 是如何工作的？它超高的性能实际上来自于两项核心技术：第一个是 用户态运行 ，第二个是 轮询模式驱动。
首先，将设施驱动代码运行在用户态，是和运行在“内核态”相对而言的。把设施驱动移出内核空间防止了内核上下文切换与中断解决，从而节俭了大量的 CPU 累赘，容许更多的指令周期用在理论解决数据存储的工作上。无论存储算法简单还是简略，也无论进行去重(deduplication)，加密(encryption)，压缩(compression)，还是简略的块读写，更少的指令周期节约意味着更好的整体性能。
其次，传统的中断式 IO 解决模式，采纳的是被动的派发式工作，有 IO 须要解决时就申请一个中断，CPU 收到中断后才进行资源调度来解决 IO。举一个出租车的例子做类比，传统磁盘设施的 IO 工作就像出租车乘客，CPU 资源被调度用来解决 IO 中断就像出租车。当磁盘速度远慢于 CPU 时，CPU 中断解决资源充分，中断机制是能对这些 IO 工作应答自若的。这就好比是非顶峰时段，出租车供大于求，路上总是有空车在扫马路，乘客随时都能叫到车。然而，在顶峰时段，比方周五黄昏在闹市区叫车 (不必滴滴或者专车)，经常是看到一辆车溜溜的近前来，而后却发现后座曾经有乘客了。须要期待多久，往往是不可预知的。置信你肯定见过在路边滞留，招手拦车的人群。同样，当硬盘速度上千倍的进步后，将随之产生大量 IO 中断，Linux 内核的中断驱动式 IO 解决(Interrupt Driven IO Process) 就显得效率不高了。
而在轮询模式驱动下，数据包和块失去迅速派发，等待时间最小化，从而达到低延时、更统一的延时(抖动变少)、更好的吞吐量的成果。
当然，轮询模式驱动并不是在所有的状况下都是最高效的 IO 解决形式。对于低速的 SATA HDD，PMD 的解决机制岂但给 IO 性能带来的晋升不显著，反而节约了 CPU 资源。
准内存引擎
除了采纳 SPDK+ZNSSD 软硬件联合的存储引擎以外，为了更无效的利用内存，取得更快的读写速度，ZNBase 在大内存场景下还开发了准内存引擎的实现。
准内存引擎开发的背景源自 RocksDB 的一些局限性：
1.WAL 的单线程写模式，不能充分发挥高速设施的性能劣势；
2. 读操作时，有可能须要查找 level 0 层的多个文件及其他层的文件，这也造成了很大的读放大。尤其是当纯随机写入后，读简直是要查问 level0 层的所有文件，导致了读操作的低效。
3. 针对第 2 点问题，RocksDB 中根据 level 0 层文件的个数来做前台写流控及后盾合并触发，以此来均衡读写的性能。这又导致了性能抖动及不能施展高速介质性能的问题。
4. 合并流程难以管制，容易造成性能抖动及写放大。
近年来，随着动态随机存储器（DRAM）容量的回升和单位价格的降落，使大量数据在内存中的存储和解决成为可能。绝对于磁盘，内存的数据读写速度要高出几个数量级，将数据保留在内存中相比从磁盘上拜访可能极大地提高利用的性能。
针对这一理念，准内存引擎设计准则如下：
1. 数据尽量寄存在内存中，充分利用内存的读写性能。
2. 基于索引与数据拆散存储的思维，索引常驻内存。数据能够依据内存容量，将局部存储到长久化存储设备中。
3. 晋升 cpu cache 命中率，通过数据块的重构（拆解、扩容、缩容）将 Key 相邻的 KV 数据在内存空间中也相邻，以晋升 key 值遍历的速度。
4. 应用异步落盘机制，保障平滑的 IO 速率，打消 IO 瓶颈。
基于 ART 索引的检索机制，保证数据访问速度。ART 算法应用基于乐观锁的的同步机制，读操作不阻塞，写操作应用版本信息的 CAS 原子操作以及重试机制。
因为已通过 Raft Log 实现数据的故障复原，能够去除 WAL 写入过程。
准内存引擎总体解决流程如下：
- 新插入的数据寄存在 内存长期区中的 Memtable 以及 Immutable 中。
- 异步线程 Mem-Flush 将 Immutable 中的数据转存到内存存储区。
- 内存存储区会尽可能占用更多的内存空间，用于存放数据。应用 ART 算法索引这些数据。
- 内存存储区内存空间行将有余时，启用 L1-Flush 后盾线程清理内存存储区中的数据。
- L1-Flush 后盾线程，将该内存存储区中所有的 KV 数据以及范畴删除数据进行落盘。因为数据量大且数据有序，因而，间接落盘到 L1 层。落盘前须要保障 L1 层无文件。落盘实现后，创立 L1 层文件向下合并的工作。
准内存引擎采纳 ART 算法作为主索引的实现，能够进行疾速的范畴查找，辅助应用 Hash 索引不便进行 Get 查问。之所以应用 ART 算法，是因为其在读写方面性能均优于 B+ 树、红黑树、二叉树，可比肩哈希表，而 ART 算法比哈希表的劣势是 ART 算法可按程序遍历所有数据。
参见论文：The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases
总结
本文为大家介绍了 ZNBase 基于 RocksDB 的存储引擎架构，以及 ZNBase 团队针对 RocksDB 的局限性，通过开发软硬件联合的 SPDK+ZNS SSD 存储引擎、大内存场景下的准内存引擎，大大提高了存储引擎的读写性能。
对于 ZNBase 的更多详情能够查看：
官网代码仓库：https://gitee.com/ZNBase/zn-kvs
ZNBase 官网：http://www.znbase.com/
对相干技术或产品有任何问题欢送提 issue 或在社区中留言探讨。同时欢送宽广对分布式数据库感兴趣的开发者独特参加 ZNBase 我的项目的建设。
分割邮箱：haojingyi@inspur.com