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的查询可能会快一些,位图解压缩有一个最低消耗时间。

你可能感兴趣的:(sphinx,epoll)