【转载保存】基于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（毫秒）。