相信很多人都看过火爆的美剧《硅谷》,里面描述的未来科技就是,可以在压缩的数据上作检索,而无需事先将数据解压。在现实中,我们就在研发这种技术。基于这项核心技术,我们对外发布了存储引擎产品 TerarkDB,这个产品具有极高的技术壁垒。我们的目标就是超越 Facebook 的 RocksDB,Google的 LevelDB,MongoDB 的 Wiredtiger,作出世界上性能最好的存储引擎。
TerarkDB 是一个拥有极高性能和数据压缩率的存储引擎。使用方法类似Facebook的RocksDB,不过比 RocksDB 具有更多功能,下面是 TerarkDB 的功能特性:
TerarkDB 在互联网以及传统行业都有相当广泛的应用场景。由于 TerarkDB 对于读操作做了大量优化,因此更适合多读少写,以及批量写大量读的场景。
TerarkDB 使用方法相当灵活,可以作为独立库使用以适应客户的定制化场景。官方提供了下载包以及 Docker 以方便用户下载使用。目前支持Linux,Windows以及Mac OS操作系统。
TerarkDB 作为一个存储引擎,有自己的原生接口,同时提供兼容 LevelDB 的接口,从而可以适配到所有使用 LevelDB 的系统和应用,例如实现了大部分 Redis 接口的 SSDB。另外,大家广泛使用的 RocksDB 接口是 LevelDB 接口的超集,所以大部分使用 RocksDB 的系统和应用也可以很容易地适配到 TerarkDB。
Terark 官方提供了 TerarkDB 到 MongoDB 的适配,到 MySQL 以及其他分布式数据库系统的适配也在紧张的开发过程中,稳定版的 MongoTerark 产品已计划在近期发布。
本节内容来自 Terark 官网,查看原文
指标 | 描述 |
---|---|
CPU | Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz (2 x 8个物理核) |
Memory | 64 GB of DDR4 RAM |
SSD | Intel® SSD 520 Series (480GB, 2.5in SATA 6Gb/s, 25nm, MLC) |
Linux Kernel | 3.10.0-327.10.1.el7.x86_64 |
产品名称 | 版本 | 公司 |
---|---|---|
rocksdb | v4.4 | |
wiredtiger | v2.8.0 | MongoDB |
hyperleveldb | v1.2.2 | |
leveldb | v1.18 |
Amazon movie data (~8 million reviews), 平均每条数据长度大约 1K
product/productId: B00006HAXW
review/userId: A1RSDE90N6RSZF
review/profileName: Joseph M. Kotow
review/helpfulness: 9/9
review/score: 5.0
review/time: 1042502400
review/summary: Pittsburgh - Home of the OLDIES
review/text: I have all of the doo wop DVD's and this one is as good or better than the
1st ones. Remember once these performers are gone, we'll never get to see them again.
Rhino did an excellent job and if you like or love doo wop and Rock n Roll you'll LOVE
this DVD !!
movies
数据集的总大小约为 9GB
, 记录数大约为 800万条
Benchmark 源代码参见 Github仓库
snappy
所有的读操作,都是单条记录随机查询。所有的写操作,也都是单条记录随机插入或更新。
snappy
算法在这种情况下我们的内存足够大,可以把所有的数据装入内存,同时 TerarkDB 不需要专有缓存,但其它数据库需要专有缓存(主要用来缓存对块压缩解压后的数据),我们为这些数据库设置专有缓存设置为3GB。
同时这项测试我们不限制操作系统对内存的使用(总内存64GB),数据量远小于内存,操作系统可以把所有数据缓存起来。
我们可以看到TerarkDB在这种情况下要好于其他数据库:
当数据量无法全部载入内存的情况下,我们需要把数据存储在物理磁盘上(我们此处使用 SSD 作为存储介质)。
这种情况下,TerarkDB 的优势更明显 :
由于TerarkDB比其他数据库的数据高出太多,下面这幅图使用对数坐标,更便于查看数量级(请观察纵坐标轴)
随机写测试和随机读(Random Read)测试的环境类似:
与随机读测试的环境类似:
在SSD上的测试结果,更真实的反应了磁盘I/O对性能的影响:
同样,由于数量级相差较大,我们通过对数坐标看一下数据:
该测试中数据集依然是9G的电影点评数据,仅测试的 Read Query 延迟,测试中无 Write 操作。
因为 TerarkDB 的压缩率很高,系统内存3G就可以装下全部数据(实际上压缩后的数据只有2.1G,但测试程序本身要占大约750M内存),所以以下3组对比中,TerarkDB都是在3G内存的条件下测试的。对于rocksdb和wiredtiger,我们分别在8G,4G和3G内存的条件下进行了测试。所有测试中,我们均使用了8个线程。
Average | Median | 99th Percentile | StdDev |
---|---|---|---|
rocksdb | 40.86 | 24 | 300 |
wiredtiger | 58.82 | 41 | 450 |
terarkdb | 6.66 | 6 | 25 |
对数
的 X, Y%
) 表示 延迟低于 X
微秒的Query数 占 总Query数 的 Y%
Average | Median | 99th Percentile | StdDev |
---|---|---|---|
rocksdb | 1338.88 | 1210 | 5000 |
wiredtiger | 273.06 | 353 | 600 |
terarkdb | 6.67 | 6 | 25 |
Average | Median | 99th Percentile | StdDev |
---|---|---|---|
rocksdb | 964.21 | 970.36 | 2500 |
wiredtiger | 204.85 | 56.25 | 600 |
terarkdb | 6.67 | 6 | 25 |
TerarkDB使用了非常先进并且复杂的技术,同时也申请了4个专利。其核心技术与其他数据库产品的B+树、LSM树、以及块压缩技术有着本质的区别。带来的好处就是压缩率与性能的同时大幅提高,并非简单的时间空间互换。本文简要介绍几个技术点,更多的技术细节请大家到 terark.com 上查看文档。
现有的主流数据库也在使用压缩技术,只不过它们主要是对时间与空间的折衷
:压缩的方式都是使用通用压缩技术按块/页(block/page)压缩
(块尺寸通常是 4K~32K,以压缩率著称的 TokuDB 块尺寸是 2M~4M)。
当启用压缩的时候,随之而来的是访问速度下降
,这是因为:
写入时,很多条记录被打包在一起压缩成一个个的块,增大块尺寸,压缩算法可以获得更大的上下文,从而提高压缩率
;相反地,减小块尺寸,会降低压缩率。
读取时,即便是读取很短的数据,也需要先把整个块解压
,再去读取解压后的数据。这样,块尺寸越大,同一个块内包含的记录数目越多,为读取一条数据,所做的不必要的解压就也就越多,性能也就越差。相反地,块尺寸越小,性能也就越好。
一旦启用压缩,为了缓解以上问题,传统数据库一般都需要比较大的专用缓存,用来缓存解压后的数据
,这样可以大幅提高热数据的访问性能
,但又引起了双缓存
的空间占用问题,一是操作系统缓存中的压缩数据
,二是专用缓存中解压后的数据
。还有一个同样很严重的问题:专用缓存
终归是缓存,当缓存未命中时,仍需要解压整个块,这就是慢Query
问题的一个来源;慢Query 的另一个来源是操作系统缓存未命中时……
传统数据库的 Btree 索引本身也会占据较大的空间,因为 Btree 通常使用的前缀压缩
的压缩率很低。
这些都导致现有传统数据库在访问速度
和空间占用
上是一个此消彼长,无法彻底解决的问题,只能进行这样或那样的折衷。
对于数据的压缩(可以认为是 key-value 中对 value 的压缩),TerarkDB 主要使用自己研发的专门针对数据库的全局压缩
技术,压缩率更高,并且没有块压缩的概念,也没有双缓存的问题。这种压缩技术可以按 RowID/RecordID 直接读取单条数据
,如果把这种读取单条数据
看作是一种解压,那么,按 RowID 顺序
解压时,解压速度一般在 500MB每秒(单线程),最高达到约 7GB/s;按 RowID 随机
解压时,解压速度一般在 300MB每秒(单线程),最高达到约3GB/s。
对于索引的压缩,Terark 主要使用 Succinct
技术,压缩率高于现有技术,并且压缩的同时,不用解压就可以高效地执行搜索
,除此之外,索引可以支持正则表达式搜索
(不用逐条遍历匹配正则表达式)。这种基于 Succinct
技术的索引,还额外支持 反向搜索
:正向是从 Key 获取 RowID,反向搜索就是从 RowID 获取 Key,这样,Key 就不需要再单独存储一份(传统Btree索引无这个功能)。这就为 TerarkDB 在同一个 Table 上支持多个索引提供了一个技术支点。
Succinct 技术诞生已有很长时间,但是一直因为性能问题未得到广泛应用,Terark Succinct 技术在 CPU 指令级别专门做了优化,大幅提升了 Succinct 的性能。
正是这些新技术的使用,TerarkDB 的压缩率和访问速度同时大幅提升,并且功能非常丰富。
TerarkDB 数据库包含多个 segment,按照 segment 的状态可分为 writing segment,writable frozen segment,以及 readonly segment。数据会首先写入 writing segment,这个 segment 中的数据可以直接更新及检索。当写入的数据达到一定的尺寸时,writing segment 会成为 writable frozen segment ,同时开始被后台线程进行压缩。当后台压缩结束时,就会生成 readonly segment,并删除 writable frozen segment。除此之外,数据的物理删除、segment 合并等工作也都在后台线程中执行。最终,大部分数据都会处于 readonly segment 中,从而拥有极高的压缩率和访问性能。
与 Terark 同时在工程化 Succinct 技术的还有著名的伯克利 AmpLab 实验室,Spark 就是在这个实验室诞生的。Terark 在算法、数据结构和工程技术上都有着自身的优势。
自动机技术在 TerarkDB 中有大量的应用,自动机就是一张状态转移图,这张图用来表达数据,沿着图中的边,按照某个确定的规则访问节点,就可以抽取出所需要的数据。用传统技术来存储这个图,内存消耗很大,Terark 采用 Succinct 技术来压缩这个状态转移图。Succinct 技术的本质就是使用 bitmap 来表示数据结构,内存用量大大降低的同时保持快速的访问性能。另一方面,由于是基于自动机,也就可以原生支持正则表达式检索。
欢迎大家下载使用 Terark 产品。未来 Terark 计划把核心引擎移植到更多分布式系统以适用更多场景,比如 Elastic Search,Spark,手机和嵌入式设备等。Terark 现阶段的计划是,寻找到更多的研发和商务合作,把产品尽快推向市场。我们目前也在招人,感兴趣的朋友可以直接联系我们。也可以访问 官方网站 来获取更多信息。