sphinx搜索引擎优化及测试
2015-01-12 18:53
302 查看
原创,转载请务必保留作者及本文出处(连接形式)。
2年前工作中的内容,已成过眼烟云,分享一下,欢迎交流。
1.之前的优化效果
之前对sphinx线程处理,网络IO做了很多优化(netty、epoll、libevent),索引部分也做了优化,从目前测试结果来看,性能提升已经到了瓶颈,尤其是全部搜索,线程调度,网络 IO优化对于这种查询方式帮助很小。对于单节点性能提升,还得从索引本身查询算法入手优化。sphinx的属性过滤对性能本身有很大影响,但是优化空间不 是很大,读取的属性是离散的,不像索引是可以连续读取的,这种操作受限于物理硬件性能。目前可以优化的主要还是索引查询部分,这两天通过写一些demo, 模拟索引和查询算法对搜索流程定量分析。
2.索引分析
目前只考虑了两种算法和索引的性能分析,第一种是sphinx现在的查询方式和索引结构,第二种是某兄之前说的某搜索公司的位图索引。
现在的查询方式性能统计:
1.1000万数据,通过增量压缩的方式(这里面为了方便对比,增量都是1个字节),压缩后读取索引时间是2597us。
在读取缓存区大于8K以后,基本 上变化不大。加载到内存后,循环一个一个读取字节,不做解压缩,需要时间65645us,
循环了1000万次;如果边读取边解压,需要142438us, 相当于77ms的时间用在了解压操作上。
2.1000万数据,不做压缩,以int的方式直接存储(目前sphinx用的long,对于我们来说,只保存内存属性偏移地址,
int就足够了),存储 文件是原来的4倍,读取时间10470us,多了8ms的读取时间,循环读取int ,无需解压操作,
用了86493us。
3.两个1000万数据列表做and操作,都采用不压缩的形式存储,整个操作时间为482461us,平均下来300ms的时间
用在了比较操作上了
基于位图运算:
1. 2000万位的两个位图列表,对位图执行and 操作,用时1855us,基本上不耗什么时间。对位图结果,遍历查询结果,
这个时间受结果集的大小限制。结果为空的时候,时间最短,不到2ms,如果结果很多,需要27ms。
2.位图压缩操作使用的是zlib,这个比较耗时,2000万的位图压缩需要300-600ms, 压缩的大小和位图相关,即时空位
图,压缩后也有2K,最大不会超过原始大小。
3.位图解压操作,耗时需要10-30ms,即时空位图,最小耗时也会在10ms。
读取文件 逐个读取 解压缩 And操作 提取结果
sphinx压缩索引 <3ms <65ms <77ms 未测试 无需此项操作
sphinx不压缩索引 <12ms <86ms 无需解压缩 300ms 无需此项操作
位图 <1ms 无需此项操作 10~30ms <2ms <27ms
对比结果:
sphinx 查询方式 查询时间在1ms~500ms
位图查询方式查询时间在30ms~90ms
位图and 操作快,是因为采用64位与运算,相当于一次对64个数据比较,在倒排列表很大的情况下,性能优势就很突出了,如果倒排列表很小,大部分操作都是无用功。
新的测试结果
使用位图的数据直接存储并不合适,只有倒排列表超过两百万的时候,位图存储有优势,解压缩时间优于存储未压缩倒排
列表时间。在实际中,2000万数据中一个倒排列表超过200万的数据是少数。所以还是使用未压缩的int存储比较合适,在
读的时候再设置位图,用位图做后续与或运算,这样可以既可以兼容之前的索引结构, 又可以提高倒排列表合并的性能。
3.结论
总体上来看,sphinx 查询方式性能波动很大,在大数据量的情况下,下降很明显,位图相比之下性能波动更加平滑。sphinx目前采用的这种压缩方式,实际上意义不大,反而增加了cpu开销。对于普通搜索(查询结果,返回结果数),这种查询方式使用位图优势更加明显一些。对于不需要结果数,只返回前n条结果的这种查询方式,sphinx的查询可能会快一些,位图解压缩有一个最低消耗时间。
2年前工作中的内容,已成过眼烟云,分享一下,欢迎交流。
1.之前的优化效果
之前对sphinx线程处理,网络IO做了很多优化(netty、epoll、libevent),索引部分也做了优化,从目前测试结果来看,性能提升已经到了瓶颈,尤其是全部搜索,线程调度,网络 IO优化对于这种查询方式帮助很小。对于单节点性能提升,还得从索引本身查询算法入手优化。sphinx的属性过滤对性能本身有很大影响,但是优化空间不 是很大,读取的属性是离散的,不像索引是可以连续读取的,这种操作受限于物理硬件性能。目前可以优化的主要还是索引查询部分,这两天通过写一些demo, 模拟索引和查询算法对搜索流程定量分析。
2.索引分析
目前只考虑了两种算法和索引的性能分析,第一种是sphinx现在的查询方式和索引结构,第二种是某兄之前说的某搜索公司的位图索引。
现在的查询方式性能统计:
1.1000万数据,通过增量压缩的方式(这里面为了方便对比,增量都是1个字节),压缩后读取索引时间是2597us。
在读取缓存区大于8K以后,基本 上变化不大。加载到内存后,循环一个一个读取字节,不做解压缩,需要时间65645us,
循环了1000万次;如果边读取边解压,需要142438us, 相当于77ms的时间用在了解压操作上。
2.1000万数据,不做压缩,以int的方式直接存储(目前sphinx用的long,对于我们来说,只保存内存属性偏移地址,
int就足够了),存储 文件是原来的4倍,读取时间10470us,多了8ms的读取时间,循环读取int ,无需解压操作,
用了86493us。
3.两个1000万数据列表做and操作,都采用不压缩的形式存储,整个操作时间为482461us,平均下来300ms的时间
用在了比较操作上了
基于位图运算:
1. 2000万位的两个位图列表,对位图执行and 操作,用时1855us,基本上不耗什么时间。对位图结果,遍历查询结果,
这个时间受结果集的大小限制。结果为空的时候,时间最短,不到2ms,如果结果很多,需要27ms。
2.位图压缩操作使用的是zlib,这个比较耗时,2000万的位图压缩需要300-600ms, 压缩的大小和位图相关,即时空位
图,压缩后也有2K,最大不会超过原始大小。
3.位图解压操作,耗时需要10-30ms,即时空位图,最小耗时也会在10ms。
读取文件 逐个读取 解压缩 And操作 提取结果
sphinx压缩索引 <3ms <65ms <77ms 未测试 无需此项操作
sphinx不压缩索引 <12ms <86ms 无需解压缩 300ms 无需此项操作
位图 <1ms 无需此项操作 10~30ms <2ms <27ms
对比结果:
sphinx 查询方式 查询时间在1ms~500ms
位图查询方式查询时间在30ms~90ms
位图and 操作快,是因为采用64位与运算,相当于一次对64个数据比较,在倒排列表很大的情况下,性能优势就很突出了,如果倒排列表很小,大部分操作都是无用功。
新的测试结果
使用位图的数据直接存储并不合适,只有倒排列表超过两百万的时候,位图存储有优势,解压缩时间优于存储未压缩倒排
列表时间。在实际中,2000万数据中一个倒排列表超过200万的数据是少数。所以还是使用未压缩的int存储比较合适,在
读的时候再设置位图,用位图做后续与或运算,这样可以既可以兼容之前的索引结构, 又可以提高倒排列表合并的性能。
3.结论
总体上来看,sphinx 查询方式性能波动很大,在大数据量的情况下,下降很明显,位图相比之下性能波动更加平滑。sphinx目前采用的这种压缩方式,实际上意义不大,反而增加了cpu开销。对于普通搜索(查询结果,返回结果数),这种查询方式使用位图优势更加明显一些。对于不需要结果数,只返回前n条结果的这种查询方式,sphinx的查询可能会快一些,位图解压缩有一个最低消耗时间。
相关文章推荐
- 实时进行GZIP压缩优化Asp.Net页面的CompressionModule对Asp.Net Ajax及搜索引擎的兼容性测试!
- 实时进行GZIP压缩优化Asp.Net页面的CompressionModule对Asp.Net Ajax及搜索引擎的兼容性测试!
- sphinx搜索引擎索引结构优化
- Web下的性能测试与优化
- 搜索引擎优化排名
- 针对Yahoo做搜索引擎优化SEO
- 面向搜索引擎的URL优化
- 减少低级劳动: 优化UI测试方法
- 概述:WEB应用程序的测试与优化
- 针对博客园Blog的SEO(Search Engine Optimization – 搜索引擎优化)
- 搜索引擎优化法则
- 搜索引擎优化SEO全攻略
- 动态网页的搜索引擎优化
- 阿里巴巴网站的搜索引擎优化案例分析
- 谈一谈动态网站的搜索引擎优化策略
- 解决页面设计和搜索引擎优化的两难
- seo搜索引擎优化在大型网站的策略
- 优化代码时要选用正确的测试方法
- 网页为搜索引擎可以做的优化
- 基于相关关键字搜索引擎优化的网站排名分析项目