Tair LDB基于Prefixkey的范围查找性能优化项目提议方案

基于prefix bloomfilter的过滤思想和get_range接口数据的特点,在导师的指导下,提出如下的简单方案,对get_range接口的范围查找过程进行优化,使得能够根据prefix进行过滤,减少无效的磁盘IO。

待优化接口

int get_range(int area, const data_entry &pkey, const data_entry &start_key,
    const data_entry &end_key, int offset, int limit, vector<data_entry*>
    &values,shorttype=CMD_RANGE_ALL);

提议方案

1.   由于get_range接口的数据是从prefix_put/prefix_incr接口进来的,那么prefix的长度信息就可以从它们的pkey参数得到,pkey的数据类型是data_entry,有属性prefix_size,那么我们在客户端将pkey和skey合并为mkey(已经设置mkey的prefix_size为pkey的size)后与value一起传送到服务器端。

在客户端与服务器端的连接过程中,将key的类型封装成LdbKey类,value的类型封装成LdbItem类,LdbItem里面含有key的prefix_size信息,然后两者都转化为Slice类型发送到leveldb底层进行存储操作。注意此时value里面包含了prefix_szie信息(序列化信息,不能直接提取),因此我们在生成filter block时可以从value中提取出prefix_size信息(按LdbItem的格式进行分析提取)以生成我们所需要的prefix bloomfilter。提取的具体实现可以放在leveldb层的外面,在leveldb里面进行调用即可(分离操作)。

2. 提取到prefix_size信息后,我们 对所有的keys实现prefix bloomfilter,为了实现简单,我们可以在原有的filter block里加入新的prefix bloomfilter,与现有的bloomfilter一起存放,方法也很简单,就是在原有的filter block building过程中(filter_block.cc),将key的prefix也当作普通的key一起加入filter中,两者的过滤算法也是一致的。

注:目前filter的创建是每添加一个key,filter就会增大bits_per_key_个位,但由于一部分keys的prefix是相同的,也不会重复添加进filter,因此最终增加的bits应该可以接受。

3. 在get_range接口中,如果查找到了sstable这里(先查memtable和immutable memtable,两者没有磁盘IO操作),

(1)首先根据[pkey+skey,pkey+end]的范围查找可能的sstfiles。

(2)对于每一个file,对dataindex block里的信息继续进行范围查找,找到可能包含[pkey+skey,pkey+end]这个范围的blocks。

(3)在读每一个block之前,获取filter block中存储的filter,通过prefix的MayMatch方法判断该block是否包含前缀pkey,如果不包含,则直接跳过这个block,这样就通过prefix bloomfilter实现了block过滤,从而减少了不必要的磁盘IO操作。

关于get_range接口目前的实现方法可以参考:

tair中对get/get_range接口的理解及为get_range添加命令行测试接口

Tair LDB基于Prefixkey的范围查找性能优化项目提议方案

时间: 2024-08-29 08:53:12

Tair LDB基于Prefixkey的范围查找性能优化项目提议方案的相关文章

Tair LDB基于Prefixkey的范围查找性能优化项目测试及完成总结报告

项目这周就截止了,这算是我第一个有导师指导的真正意义上的C++项目,项目基本完成,想要实现的功能也已经实现,并做了大量的性能测试.不过这对于业界来说,可能完成的还不够成熟,还有许多待改进的地方,还不能马上投入使用,还需要进行严格的考验,毕竟tair的应用场景太重要了,不容一丝疏忽.但于我个人而言,帮助还是挺大的,不仅是多了一次有价值的项目经验,更是学到了一些项目之外的东西,比如计划的重要性,惰性的控制,时间的分配管理(找工作与项目进度产生冲突)等.好了,不多说了,在这最后一篇总结报告里首先给出性

Tair LDB基于Prefixkey的范围查找性能优化项目之如何提取key的prefix_size信息

New Document/* GitHub stylesheet for MarkdownPad (http://markdownpad.com) */ /* Author: Nicolas Hery - http://nicolashery.com */ /* Version: b13fe65ca28d2e568c6ed5d7f06581183df8f2ff */ /* Source: https://github.com/nicolahery/markdownpad-github */ /*

Tair LDB基于Prefixkey的范围查找性能优化项目之如何建立prefix bloomfilter

项目是按照"Tair LDB基于Prefixkey的范围查找性能优化项目提议方案"的步骤一步步完成的,上次解决了如何获取key的prefix_size问题"Tair LDB基于Prefixkey的范围查找性能优化项目之如何提取key的prefix_size".今天来继续解决第二个问题.在提案中有以下描述: 提取到prefix_size信息后,我们对所有的keys实现prefix bloomfilter,为了实现简单,我们可以在原有的filter block里加入新的

Tair LDB基于Prefixkey的范围查找性能优化项目之后续问题解决记录

项目是按照"Tair LDB基于Prefixkey的范围查找性能优化项目提议方案"的步骤一步步完成的,目前方案中提出的三个重点问题已经全部解决,如下所示: 如何获取key的prefix_size问题:Tair LDB基于Prefixkey的范围查找性能优化项目之如何提取key的prefix_size 如何建立prefix bloomfilter:Tair LDB基于Prefixkey的范围查找性能优化项目之如何建立prefix bloomfilter 如何在get_range过程中使用

Tair LDB基于Prefixkey的范围查找性能优化项目之如何使用prefix bloomfilter进行过滤

项目是按照"Tair LDB基于Prefixkey的范围查找性能优化项目提议方案"的步骤一步步完成的,目前已经解决了前面两个问题: 如何获取key的prefix_size问题"Tair LDB基于Prefixkey的范围查找性能优化项目之如何提取key的prefix_size". 如何建立prefix bloomfilter"Tair LDB基于Prefixkey的范围查找性能优化项目之如何建立prefix bloomfilter" 今天来继续解

Tair LDB基于Prefixkey的范围查找性能优化项目中期总结

"Tair LDB基于Prefixkey的范围查找性能优化"这个项目刚好进行了一个月,这一个月主要是熟悉项目.掌握项目和提出设计方案的过程,下面从几个方面总结下个人在该项目上所做的工作及自己的个人所得所感. 项目工作简单总结 下面是对阶段性的成果进行总结,并附有每个阶段的总结报告. 1. 项目实施计划的确定 不管什么类型的项目(大.小,难.易),在项目开展之前都应该有个可实施的计划,一方面能够确保项目的进度,另一方面也能防止有些人三天打鱼两天晒网的心态.在导师的细心指导下,我们确定了下

手机淘宝 521 性能优化项目揭秘

又是一年双十一,亿万用户都会在这一天打开手机淘宝,高兴地在会场页面不断浏览,面对琳琅满目的商品图片,抢着添加购物车,下单付款.为了让用户更顺畅更方便地实现这一切,做到“如丝般顺滑”,双十一前夕手机淘宝成立了“521”(我爱你)性能优化项目,在日常优化基础之上进行三个方面的专项优化攻关,分别是1)H5页面的一秒法则:2)启动时间和页面帧率提升20%:3)Android内存占用降低50%.优化过程中遇到的困难,思考后找寻的方案,实施后提取的经验都会在下面详细地介绍给读者. 第一章 一秒法则的实现 “

性能优化项目的总结

在性能优化项目中,我只是一个协助参与的角色,但也正好给了我从外部参看项目运作的机会,需要优化的系统已经是运行了6年的老系统,数据从来没有做过分离,涉及全库查询等致命的优化问题.另外本次项目的业主也希望对优化工作进行指导,造成走了不少弯路,同时由于垂直数据库技术不足,从外部找了合作伙伴进行深入性能优化研究.总之这个项目虽小,但具备了复杂项目的各方面的内容,我也将会对这个项目进行初步的分析. 基础方向 SQL优化 首先要做的就是找出执行慢的SQL或业务模块,调查SQL的业务逻辑是否存在可优化的空间.

MIS性能优化常见问题与方案(辅助项目组性能优化的总结贴)

最近帮忙公司的几个项目组进行了不同方面的性能优化,发现几个项目都出现了一些共性的问题.这里写一篇文章,总结一下这几类问题,以及其对应的解决方案.方便其它项目组参考.   常见问题一:打开页面非常慢,有的项目打开一个页面竟然要 20 多秒. 优化步骤: 降低每一个页面的请求数:使用浏览器跟踪打开页面后所有的请求,并逐一排查,把没有必要向服务端发起的请求优化掉,减少 Round Trip 次数. 针对每一个请求进行优化:对请求逐一排查,看看分别是哪些请求占用了较多的时间. 如果该请求是 JS 文件,