【转载保存】基于Lucene的近实时搜索引擎优化总结

一、搜索优化:

    在工程领域,越是看起来“简单、确定”的问题,越是难以解决。近实时搜索引擎需要解决的问题只有一个:性能!它包含快速索引,快速搜索,以及索引到搜索的快速生效。

    以下为百万条数据级(适用于千万级)快速滚动数据近实时搜索引擎实践经验总结:

 

 1. 针对技术优化

    1.1 数值搜索优化: 将数值的范围缩小,能用 int值 的不要用 long值,能用 float值 的不用要 double值;能用string 替换的,就不要用范围查询(特别是大范围查询),这些都基于Lucene搜索引擎对数值建索引和范围查询的原理和特点所决定;

    1.2 搜索语法的简化和高级搜索的支持取得一个平衡点: 谨慎用"*","?"(Wildcard搜索),禁止出现 "*AA"的查询,如果必须支持这样的查询,则需要培训用户了解"*"可能引起的性能问题。

 

 2. 针对业务优化

    2.1 特别强调范围查询,必须优化。避免大范围数值查询,数值范围查询不可避免的情况下,尽量使用小范围,这是由业务性质决定的,比如:说 A > 0的查询,需要优化为某个更有意义的查询: [A : 0-100]。

    2.2 能使用短字符串(特别是不做分词的字符串)搜索的来替代,一定不要用数值搜索。数值搜索的特定虽然快,但对范围查询,它有一定的代价,如果使用不合适,代价会很大。

 

二、索引优化:

    优秀的搜索引擎是快速创建索引和快速搜索的一个平衡体。特别对近实时搜索引擎而言,这个平衡点更为难以达到。

    通过一系列测试和验证,Lucene在【搜索】,【索引】以及【优化】之间要达到平衡其实很不容易。在频繁的搜索和索引下,在线的优化难以真正起效果。可以理解为优先级有这样的特性:搜索 > 索引 > 优化。搜索的时间相对最短,优化的时间最长。在前二者频繁操作下,优化没有机会(强行优化只能导致,搜索和索引停顿,对近实时系统来说不可接受)。因而必须设置好相应的参数,主要包括:缓存大小,索引内存大小,索引单次提交数量上限(等同Merge因子,Lucene不一定严格执行),搜索最大并发数等。

    大部分的索引优化是基于搜索业务的,如上述一所描述的用字符串字段替代数值范围查询。而索引本身的创建方式又直接影响到搜索,对Lucene来说Merge因子的配置是个关键(内存足够大的情况下)。简单的说,Merge因子小,索引慢,但对大批量建索引性能影响却不大(索引内存足够大为前提),但同时它会使得索引段落数被限制在合理范围值(直接影响索引段数——搜索性能)。相反如果Merge因子小,搜索会很快,段数也大,如果不及时做索引优化,对搜索性能的影响是致命的。

 

三、分布式平衡

    一台Lucene服务器要想达到近实时搜索基本是不可能的,除非搜索量非常小。单台搜索量5个/s以上,一台基于Lucene的实时搜索基本上会吃不消,原因不在于搜索本身,而在于索引的同时,保证搜索实时性。而建索引的过程如果产生的碎片(段)过多,会直接影响搜索。总结下来,给予建索引的服务器一定的空闲时间是必须的,也就是说在建索引的时间段,搜索不能太过频繁。因而分布式分摊搜索压力是很有必要的。

 

 

总结:

    1. 目前3台基于Lucene的PC服务器,高峰并发数量在15个/s左右;

    2. 数据量为百万条级别(不到200万),单条数据80个字段,每条大概为200字符(中文、英文、数字);

    3. 搜索条件基本在7-20关键字,平均搜索速度为98ms;

  4. 最慢的搜索为350ms(毫秒)。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值