相信很多人都看过火爆的美剧《硅谷》,里面描写的未来科技就是,可以在紧缩的数据上作检索,而无需事前将数据解压。在现实中,我们就在研发这类技术。基于这项核心技术,我们对外发布了存储引擎产品 TerarkDB,这个产品具有极高的技术壁垒。我们的目标就是超出 Facebook 的 RocksDB,Google的 LevelDB,MongoDB 的 Wiredtiger,作出世界上性能最好的存储引擎。
TerarkDB 是1个具有极高性能和数据紧缩率的存储引擎。使用方法类似Facebook的RocksDB,不过比 RocksDB 具有更多功能,下面是 TerarkDB 的功能特性:
TerarkDB 在互联网和传统行业都有相当广泛的利用场景。由于 TerarkDB 对读操作做了大量优化,因此更合适多读少写,和批量写大量读的场景。
TerarkDB 使用方法相当灵活,可以作为独立库使用以适应客户的定制化场景。官方提供了下载包和 Docker 以方便用户下载使用。目前支持Linux,Windows和Mac OS操作系统。
TerarkDB 作为1个存储引擎,有自己的原生接口,同时提供兼容 LevelDB 的接口,从而可以适配到所有使用 LevelDB 的系统和利用,例照实现了大部份 Redis 接口的 SSDB。另外,大家广泛使用的 RocksDB 接口是 LevelDB 接口的超集,所以大部份使用 RocksDB 的系统和利用也能够很容易地适配到 TerarkDB。
Terark 官方提供了 TerarkDB 到 MongoDB 的适配,到 MySQL 和其他散布式数据库系统的适配也在紧张的开发进程中,稳定版的 MongoTerark 产品已计划在近期发布。
本节内容来自 Terark 官网,查看原文
指标 | 描写 |
---|---|
CPU | Intel(R) Xeon(R) CPU E5⑵630 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⑶27.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对性能的影响:
一样,由于数量级相差较大,我们通过对数坐标看1下数据:
该测试中数据集仍然是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)。
当启用紧缩的时候,随之而来的是访问速度降落
,这是由于:
写入时,很多条记录被打包在1起紧缩成1个个的块,增大块尺寸,紧缩算法可以取得更大的上下文,从而提高紧缩率
;相反地,减小块尺寸,会下降紧缩率。
读取时,即使是读取很短的数据,也需要先把全部块解压
,再去读取解压后的数据。这样,块尺寸越大,同1个块内包括的记录数目越多,为读取1条数据,所做的没必要要的解压就也就越多,性能也就越差。相反地,块尺寸越小,性能也就越好。
1旦启用紧缩,为了减缓以上问题,传统数据库1般都需要比较大的专用缓存,用来缓存解压后的数据
,这样可以大幅提高热数据的访问性能
,但又引发了双缓存
的空间占用问题,1是操作系统缓存中的紧缩数据
,2是专用缓存中解压后的数据
。还有1个一样很严重的问题:专用缓存
终归是缓存,当缓存未命中时,仍需要解压全部块,这就是慢Query
问题的1个来源;慢Query 的另外一个来源是操作系统缓存未命中时……
传统数据库的 Btree 索引本身也会占据较大的空间,由于 Btree 通常使用的前缀紧缩
的紧缩率很低。
这些都致使现有传统数据库在访问速度
和空间占用
上是1个此消彼长,没法完全解决的问题,只能进行这样或那样的折衷。
对数据的紧缩(可以认为是 key-value 中对 value 的紧缩),TerarkDB 主要使用自己研发的专门针对数据库的全局紧缩
技术,紧缩率更高,并且没有块紧缩的概念,也没有双缓存的问题。这类紧缩技术可以按 RowID/RecordID 直接读取单条数据
,如果把这类读取单条数据
看做是1种解压,那末,按 RowID 顺序
解压时,解压速度1般在 500MB每秒(单线程),最高到达约 7GB/s;按 RowID 随机
解压时,解压速度1般在 300MB每秒(单线程),最高到达约3GB/s。
对索引的紧缩,Terark 主要使用 Succinct
技术,紧缩率高于现有技术,并且紧缩的同时,不用解压就能够高效地履行搜索
,除此以外,索引可以支持正则表达式搜索
(不用逐条遍历匹配正则表达式)。这类基于 Succinct
技术的索引,还额外支持 反向搜索
:正向是从 Key 获得 RowID,反向搜索就是从 RowID 获得 Key,这样,Key 就不需要再单独存储1份(传统Btree索引无这个功能)。这就为 TerarkDB 在同1个 Table 上支持多个索引提供了1个技术支点。
Succinct 技术诞生已有很长时间,但是1直由于性能问题未得到广泛利用,Terark Succinct 技术在 CPU 指令级别专门做了优化,大幅提升了 Succinct 的性能。
正是这些新技术的使用,TerarkDB 的紧缩率和访问速度同时大幅提升,并且功能非常丰富。
TerarkDB 数据库包括多个 segment,依照 segment 的状态可分为 writing segment,writable frozen segment,和 readonly segment。数据会首先写入 writing segment,这个 segment 中的数据可以直接更新及检索。当写入的数据到达1定的尺寸时,writing segment 会成为 writable frozen segment ,同时开始被后台线程进行紧缩。当后台紧缩结束时,就会生成 readonly segment,并删除 writable frozen segment。除此以外,数据的物理删除、segment 合并等工作也都在后台线程中履行。终究,大部份数据都会处于 readonly segment 中,从而具有极高的紧缩率和访问性能。
与 Terark 同时在工程化 Succinct 技术的还有著名的伯克利 AmpLab 实验室,Spark 就是在这个实验室诞生的。Terark 在算法、数据结构和工程技术上都有着本身的优势。
自动机技术在 TerarkDB 中有大量的利用,自动机就是1张状态转移图,这张图用来表达数据,沿着图中的边,依照某个肯定的规则访问节点,就能够抽取出所需要的数据。用传统技术来存储这个图,内存消耗很大,Terark 采取 Succinct 技术来紧缩这个状态转移图。Succinct 技术的本质就是使用 bitmap 来表示数据结构,内存用量大大下降的同时保持快速的访问性能。另外一方面,由因而基于自动机,也就能够原生支持正则表达式检索。
欢迎大家下载使用 Terark 产品。未来 Terark 计划把核心引擎移植到更多散布式系统以适用更多场景,比如 Elastic Search,Spark,手机和嵌入式装备等。Terark 现阶段的计划是,寻觅到更多的研发和商务合作,把产品尽快推向市场。我们目前也在招人,感兴趣的朋友可以直接联系我们。也能够访问 官方网站 来获得更多信息。