TerarkDB 能把 Pika 顶到多高的性能

* 手机浏览时建议横屏

Pika 简介

Pika 是一个支持持久化大容量存储的类 Redis 存储系统

Pika 解决了 Redis 无法应对数据尺寸超过内存容量的问题

Pika 支持全同步和部分同步的主从机制，可以提供更好的总体性能

  Pika 的架构图如下（摘自 Pika 官方）：

  如图所示，Pika 使用Blackwidow桥接了一个轻薄的壳层 Pika Process Layer 和 RocksDB 这一核心数据库，该壳层通过 Redis 协议与 Client 进行交互。（Blackwidowa是一个独立的 git repo，可以被看做一个“存储引擎”，将存储在 RocksDB 中的 key-value 形式的数据封装成 Redis 格式的数据结构(Strings, Hash, List, Set, ZSet)）

  显然，作为数据库核心的 RocksDB 是影响整个系统性能的最大因子。

RocksDB 简介

  RocksDB 作为一个继承了 LevelDB 衣钵的 key-value 数据库，使用和 LevelDB 一样的 LSM Tree（Log Structured Merge Trees）来存储数据，同时允许高度灵活的配置，从而可以应对各种不同的应用场景与需求。我们不妨看看 RocksDB 的架构设计 :

  简要的解释一下图中表示的架构 :

对于 RocksDB 的每个 DBImpl 实例，其中都存在唯一的 Wal Log 和 Manifest，供所有 ColumnFamily 共享。

内存数据的组织形式：ColumnFamily 及其御下的所有 MemTable 和 Immutable MemTables 组成了数据的内存形式；

磁盘文件的组织形式：VersionStorage 将物理存储中的 SST File 组织成 LSM Tree。

TerarkDB 简介

  TerarkDB 是 Terark 修改版的 RocksDB，包括了完全开源的 Terark RocksDB 和 部分依赖私有库的 Terark-Zip-RocksDB。 在兼容 RocksDB API 的同时，TerarkDB 使用了独创的可检索压缩算法，替代了 RocksDB 原有的数据压缩与索引算法。

  可检索压缩算法是 Terark 独创的高性能数据引擎技术簇的统称，其核心价值是可以直接在压缩的数据上执行搜索和访问，具体而言 :

摒弃了传统块压缩方法，使用全局压缩

在 Terark 的技术体系中，和是同一个东西的不同侧面：是手段，是目的，当我们强调或者时，我们称它为，当我们强调或时，我们称它为。

全局压缩的压缩率远高于块压缩

在 KeyValue 数据库模型中，我们把可检索压缩算法分为两类：

对 Key 使用具有快速搜索能力的CO-Index(CompressedOrderedIndex)

对 Value 使用具有定点访问能力的PA-Zip(PointAccessibleZip)

  CO-Index 和 PA-Zip 包含多种不同的算法：从常见的压缩算法，基本的索引结构，到使用了复杂的指令级优化的 Succinct 技术，Nested Succinct Trie 及其衍生结构等等，这些精心设计的算法与数据结构聚合成一系列强大的数据引擎支撑组件，可以承载不同工况下复杂的高性能数据压缩与索引需求。

  这些技术使得 TerarkDB 能够在拥有极高数据压缩率的同时，访问数据的粒度还能精确到单条数据。正是这种独创的思路，大大提升了随机读取性能，彻底消除了块压缩这种传统算法的缺陷（只需要一条数据，却被迫要解压整个压缩的数据块，白白浪费了 CPU 和内存）。与块压缩相反，TerarkDB 的数据密度显著提高，大大减小了内存需求，从而间接减小了 IO 压力，进一步提高了系统性能。

总结下来，TerarkDB 达到的效果 :

更高的随机读性能 ( QPS 更高 )

更高的数据压缩率 ( 磁盘文件更小 )

更低的内存占用率 ( 可检索压缩算法，没有双缓存问题 )

  接下来我们不妨来看看 Pika 在 RocksDB 和 TerarkDB 上的实际测试。

性能测试

测试平台测试数据Pika 配置测试方法

  redis-benchmark 是 redis 的标准性能测试工具，但它是通过生成随机数据的方法进行测试，无法反映现实世界的真实场景。所以，为了更好地贴近现实世界的真实场景，我们使用 redis 官方的 hiredis 库编写了专门的测试程序：

加载用户提供的数据 ( KeyValue ) 文件，写入 pika

这个数据我们选择了数据量较大的英文维基百科（109G）

持续读取用户提供的 Key 文件，用 batch=100 个 get 的方式去访问 pika

把维基百科中的 Key 提取出来，并进行 shuffle （Linux shuff 命令），达到均匀分布的随机效果

均匀分布的随机测试相当于工作集是整个数据库，而现实场景中往往会有热数据，所以这是一个比现实场景更加严苛的测试

由此，我们得到了以下测试结果：

总体情况

数据落盘尺寸与不限内存运行时的存储资源占用:

在这里，Official Pika（使用原版 RocksDB）的内存占用已经去除了操作系统缓存占用，因为数据全部加载进内存之后就不需要再访问操作系统 Cache

在真实世界中，数据不可能全部放进内存，操作系统缓存(OSCache)占用必不可少，除非使用 DirectIO

这就是我们常说的双缓存问题：DBCache 与 OSCache

如果计算双缓存的总量，不限内存时 Official Pika 的内存用量就是 180GB

一般情况下数据库对 DBCache 和 OSCache 的推荐配置是 50:50

随后在限制内存用量的测试中，我们均使用 50:50 的推荐配置

不限内存运行，并且完成数据库预热后（所有数据都加载进内存）再观察性能，Terark Pika 和 Official Pika 的 QPS 都达到了相近的上限（约 40万），然而，如果衡量每 GB 内存对 QPS 的贡献量，就得到了下面这个结果（根据上图计算，Official Pika 不计 OSCache）：

SATA SSD 上的具体测试结果

在 SATA SSD 上，不同可用内存下的平均 QPS :

在 SATA SSD 上，不同可用内存下的 CPU 占用百分比（top 命令）:

在 SATA SSD 上，不同可用内存下的，平均每个 CPU 提供的 QPS :

监控(例如 top 命令)中每 100% 的 CPU 视为一个 CPU

SATA SSD 的性能较差，当 IO 压力较高时，系统产生剧烈的抖动，QPS 急剧下降，CPU 用量很低，此时 CPU 用量存在“测量结果偏低”的问题，表现出来的就是平均每个 CPU 提供的 QPS 明显高于预期

NVME SSD 上的具体测试结果

在 NVME SSD 上，不同可用内存下的平均 QPS :

在 NVME SSD 上，不同可用内存下的 CPU 占用百分比（top 命令）:

在 NVME SSD 上，不同可用内存下的，平均每个 CPU 提供的 QPS :

监控(例如 top 命令)中每 100% 的 CPU 视为一个 CPU

NVMe SSD 的性能很高，当 IO 压力较高时，QPS 仍然比较高，未观察到 CPU 用量的“测不准”问题

结果解读

  从上面的测试结果中我们不难看出，在资源占用上，TerarkDB 的优势十分明显。仅仅占用了原版 Pika 约五分之一的内存，却能提供比原版 Pika 更高的 QPS，而每 GB 内存所贡献的 QPS 更是原版的数倍。在实际工况中，这种节省资源的同时还能提高效能的价值不言自明。

  具体而言，在内存有限，数据量大于内存容量的情况下，即大部分的实际工况中，Terark Pika 的性能远高于原版 Pika，而当我们将 Block-Size 调为 16KB 后 (默认为 4KB)，这一差距体现的更加明显。

  造成这种性能差距的原因其实很简单，在大部分的实际工况中，TerarkDB 的独创技术可以有效提高内存与 IO 效能，自然好于原版 Pika；而在内存可以肆意使用时，原版 Pika 可以将数据全部缓冲至内存，平均 QPS 有了显著的提高。但与 TerarkDB 相比，仍旧是 TerarkDB 凭借独有的算法与技术得以略胜一筹。

  另一方面，正如前文所述，Pika 上层的设计仅仅是轻薄的壳层，极大程度上减少了内核与壳层交互过程中的开销，使数据引擎更能发挥出本身的实力与素质，从而表现出更好的综合性能。但即使是 Pika 这样轻薄的壳层，也会有相当的性能损失，这使得 TerarkDB 引擎远远未达到性能上限，实际上，使用维基百科这个数据集，在针对 TerarkDB 引擎的性能测试中，只需要 24G 内存，随机读 QPS 就达到了137万！

  重剑无锋，大巧不工。 TerarkDB 卓越的性能背后是 Terark 团队为了追求极致性能而付出的不懈努力，是 Terark 研发团队对可检索压缩算法这一核心技术簇的不断精研与打磨。而结果也恰如测试所表现出来的一样，TerarkDB 能够在实际工作场景中节省资源与成本的同时，展现出卓越的性能。