标签:朋友 单位 table 性能对比 google facebook benchmark 行业 后缀
作为数据库,在系统资源(CPU、内存、SSD、磁盘等)一定的前提下,我们希望:
几乎所有压缩算法都严重依赖上下文:
对于普通的以数据块/文件为单位的压缩,传统的(流式)数据压缩算法工作得不错,时间长了,大家也都习惯了这种数据压缩的模式。基于这种模式的数据压缩算法层出不穷,不断有新的算法实现。包括使用最广泛的gzip、bzip2、Google的Snappy、新秀Zstd等。
对于数据库,在计算机世界的太古代,为I/O优化的Btree一直是不可撼动的,为磁盘优化的Btree block/page size比较大,正好让传统数据压缩算法能得到较大的上下文,于是,基于block/page的压缩也就自然而然地应用到了各种数据库中。在这个蛮荒时代,内存的性能、容量与磁盘的性能、容量泾渭分明,各种应用对性能的需求也比较小,大家都相安无事。
现在,我们有了SSD、PCIe SSD、3D XPoint等,内存也越来越大,块压缩的缺点也日益突出:
于是,对于很多实时性要求较高的应用,只能关闭压缩。
使用通用压缩技术(Snappy、LZ4、zip、bzip2、Zstd等),按块/页(block/page)进行压缩(块尺寸通常是4KB~32KB,以压缩率著称的TokuDB块尺寸是2MB~4MB),这个块是逻辑块,而不是内存分页、块设备概念中的那种物理块。
启用压缩时,随之而来的是访问速度下降,这是因为:
一旦启用压缩,为了缓解以上问题,传统数据库一般都需要比较大的专用缓存,用来缓存解压后的数据,这样可以大幅提高热数据的访问性能,但又引起了双缓存的空间占用问题:一是操作系统缓存中的压缩数据;二是专用缓存(例如RocksDB中的DBCache)中解压后的数据。还有一个同样很严重的问题:专用缓存终归是缓存,当缓存未命中时,仍需要解压整个块,这就是慢Query问题的一个主要来源(慢Query的另一个主要来源是在操作系统缓存未命中时)。
这些都导致现有传统数据库在访问速度和空间占用上是一个此消彼长、无法彻底解决的问题,只能采取一些折衷。
以RocksDB为例,RocksDB中的BlockBasedTable就是一个块压缩的SSTable,使用块压缩,索引只定位到块,块的尺寸在dboption里设定,一个块中包含多条(key,value)数据,例如M条,这样索引的尺寸就减小到了1/M:
创建BlockBasedTable时,Key Value被逐条填入buffer,当buffer尺寸达到预定大小(块尺寸,当然,一般buffer尺寸不会精确地刚好等于预设的块尺寸),就将buffer压缩并写入BlockBasedTable文件,并记录文件偏移和buffer中的第一个Key(创建index要用),如果单条数据太大,比预设的块尺寸还大,这条数据就单独占一个块(单条数据不管多大也不会分割成多个块)。所有Key Value写完以后,根据之前记录的每个块的起始Key和文件偏移,创建一个索引。所以在BlockBasedTable文件中,数据在前,索引在后,文件末尾包含元信息(作用相当于常用的FileHeader,只是位置在文件末尾,所以叫footer)。
搜索时,先使用searchkey找到searchkey所在的block,然后到DB Cache中搜索这个块,找到后就进一步在块中搜索searchkey,如果找不到,就从磁盘/SSD读取这个块,解压后放入DB Cache。RocksDB中的DB Cache有多种实现,常用的包括LRU Cache,另外还有Clock Cache、Counting Cache(用来统计Cache命中率等),还有其他一些特殊的Cache。
一般情况下,操作系统会有文件缓存,所以同一份数据可能既在DB Cache中(解压后的数据),又在操作系统Cache中(压缩的数据)。这样会造成内存浪费,所以RocksDB提供了一个折衷:在dboption中设置DIRECT_IO选项,绕过操作系统Cache,这样就只有DB Cache,可以节省一部分内存,但在一定程度上会降低性能。
FM-Index的全名是Full Text Matching Index,属于Succinct Data Structure家族,对数据有一定的压缩能力,并且可以直接在压缩的数据上执行搜索和访问。
FM-Index的功能非常丰富,历史也已经相当悠久,不算是一种新技术,在一些特殊场景下也已经得到了广泛应用,但是因为各种原因,一直不温不火。最近几年,FM-Index开始有些活跃,首先是GitHub上有个大牛实现了全套Succinct算法,其中包括FM-Index,其次Berkeley的Succinct项目也使用了FM-Index。
FM-Index属于Offline算法(一次性压缩所有数据,压缩好之后不可修改),一般基于BWT变换(BWT变换基于后缀数组),压缩好的FM-Index支持以下两个最主要的操作:
FM-Index还支持更多其他操作,感兴趣的朋友可以进一步调研。
但是,在笔者看来,FM-Index有几个致命的缺点:
可以用一种简单的方式把Flat Model转化成KeyValue Model:挑选一个在Key和Value中都不会出现的字符“#”(如果无法找出这样的字符,需要进行转义编码),每个Key前后都插入该字符,Key之后紧邻的就是Value。如此,search(#key#)返回了#key#出现的位置,我们就能很容易地拿到Value了。
Berkeley的Succinc项目在FM-Index的Flat Text模型上实现了更丰富的行列(Row-Column)模型,付出了巨大的努力,达到了一定的效果,但离实用还相差太远。
感兴趣的朋友可以仔细调研下FM-Index,以验证笔者的总结与判断。
Terark公司提出了“可检索压缩(Searchable Compression)”的概念,其核心也是直接在压缩的数据上执行搜索(search)和访问(extract),但数据模型本身就是KeyValue模型,根据其测试报告,速度要比FM-Index快得多(两个数量级),具体阐述:
我们需要对Key进行索引,才能有效地进行搜索,并访问需要的数据。
普通的索引技术,索引的尺寸相对于索引中原始Key的尺寸要大很多,有些索引使用前缀压缩,能在一定程度上缓解索引的膨胀,但仍然无法解决索引占用内存过大的问题。
我们提出了CO-Index(Compressed Ordered Index)的概念,并且通过一种叫做Nested Succinct Trie的数据结构实践了这一概念。
较之传统实现索引的数据结构,Nested Succinct Trie的空间占用小十几倍甚至几十倍。而在保持该压缩率的同时,还支持丰富的搜索功能:
与FM-Index相比,CO-Index也有其优势(假定FM-Index中所有的数据都是Key)。
实际上我们实现了很多种CO-Index,其中Nested Succinct Trie是适用性最广的一种,在这里对其原理做一个简单介绍:
Succinct Data Structure介绍
Succinct Data Structure是一种能够在接近于信息论下限的空间内来表达对象的技术,通常使用位图来表示,用位图上的rank和select来定位。
虽然能够极大降低内存占用量,但实现起来较为复杂,并且性能低很多(时间复杂度的常数项很大)。目前开源的有SDSL-Lite,我们则使用自己实现的Rank-Select,性能也高于开源实现。
以二叉树为例
传统的表现形式是一个结点中包含两个指针:struct Node { Node *left, *right; };
每个结点占用 2ptr,如果我们对传统方法进行优化,结点指针用最小的bits数来表达,N个结点就需要2*[log2(N)]个bits。
Succinct Tree
Succinct Tree有很多种表达方式,这里列出常见的两种:
Succinct Trie = Succinct Tree + Trie Label
Trie可以用来实现Index,图2这个Succinct Trie用的是LOUDS表达方式,其中保存了hat、is、it、a、四个Key。
Patricia Trie加嵌套
仅使用Succinct技术,压缩率远远不够,所以又应用了路径压缩和嵌套。这样一来,压缩率就上了一个新台阶。
把上面这些技术综合到一起,就是我们的Nest Succinct Trie。
我们研发了一种叫做PA-Zip (Point Accessible Zip)的压缩技术:每条数据关联一个ID,数据压缩好之后,就可以用相应的ID访问那条数据。这里,ID就是那个Point,所以叫做Point Accessible Zip。
PA-Zip对整个数据库中的所有Value(KeyValue数据库中所有Value的集合)进行全局压缩,而不是按block/page进行压缩。这是针对数据库的需求(KeyValue 模型),专门设计的一个压缩算法,用来解决传统数据库压缩的问题:
压缩率更高,没有双缓存的问题,只要把压缩后的数据装进内存,不需要专用缓存,可以按ID直接读取单条数据,如果把这种读取单条数据看作是一种解压,那么:
与FM-Index相比,PA-Zip解决的是FM-Index的extract操作,但性能和压缩率都要好得多:
Key以全局压缩的形式保存在CO-Index中,Value以全局压缩的形式保存在 PA-Zip中。搜索一个Key,会得到一个内部ID,根据这个ID,去PA-Zip中定点访问该ID对应的Value,整个过程中只触碰需要的数据,不需要触碰其他数据。
如此无需专用缓存(例如RocksDB中的DBCache),仅使用mmap,完美配合文件系统缓存,整个DB只有mmap的文件系统缓存这一层缓存,再加上超高的压缩率,大幅降低了内存用量,并且极大简化了系统的复杂性,最终完成数据库性能的大幅提升,从而同时实现了超高的压缩率和超高的随机读性能。
从更高的哲学层面看,我们的存储引擎很像是用构造法推导出来的,因为CO-Index和PA-Zip紧密配合,完美匹配KeyValue模型,功能上“刚好够用”,性能上压榨硬件极限,压缩率逼近信息论的下限。相比其他方案:
数据集:Amazon movie data
Amazon movie data (~8 million reviews),数据集的总大小约为9GB, 记录数大约为800万条,平均每条数据长度大约1K。
Benchmark代码开源:参见Github仓库。
这是在内存足够的情况下,各个存储引擎的性能。
数据集:Wikipedia英文版
Wikipedia英文版的所有文本数据,109G,压缩到23G。
数据集:TPC-H
在TPC-H的lineitem数据上,使用TerarkDB和原版RocksDB(BlockBasedTable)进行对比测试:
TerarkDB = Terark SSTable + RocksDB
RocksDB最初是Facebook对Google的LevelDB的一个fork,编程接口上兼容LevelDB,并增加了很多改进。
RocksDB对我们有用的地方在于其SSTable可以plugin,所以我们实现了一个RocksDB的SSTable,将我们的技术优势通过RocksDB发挥出来。
虽然RocksDB提供了一个相对完整的KeyValueDB框架,但要完全适配我们特有的技术,仍有一些欠缺,所以需要对RocksDB本身也做一些修改。将来可能有一天我们会将自己的修改提交到RocksDB官方版。
Github链接:TerarkDB(https://github.com/Terark/terarkdb),TerarkDB包括两部分:
为了更好的兼容性,TerarkDB对RocksDB的API没有做任何修改,为了进一步方便用户使用TerarkDB,我们甚至提供了一种方式:程序无需重新编译,只需要替换 librocksdb.so并设置几个环境变量,就能体验TerarkDB。
如果用户需要更精细的控制,可以使用C++ API详细配置TerarkDB的各种选项。
目前大家可以免费试用,可以做性能评测,但是不能用于production,因为试用版会随机删掉0.1%的数据。
Terark命令行工具集
我们提供了一组命令行工具,这些工具可以将输入数据压缩成不同的形式,压缩后的文件可以使用Terark API或(该工具集中的)其他命令行工具解压或定点访问。
标签:朋友 单位 table 性能对比 google facebook benchmark 行业 后缀
原文地址:http://www.cnblogs.com/gongxiaojiu/p/7044511.html