提高solr的搜索速度

来源:转载


之前是使用12台机分布式搜索,1台为主机做索引并分发给子机,8台做大索引搜索服务,3 台做小索引搜索服务,配置基本是内存在4-8G,cpu:2-8core的服务器,索引的大小为8G。搜索的响应时间 是150ms左右。(使用solr架构的搜索服务)

 

   在一次技术群中,中听到一位sina的架构师,他们是采用基于lucene做的搜索服务,索引在20多G数据量,差不多是在亿的级别上,PV量在500万/天左右,高峰时期500个并发量/s,采用的是增量索引 ,读写索引都在同一台机上。他们并没有采用分布式,而是采用单机提供服务,主要是在配置上内存提高 到32-64G,再加cpu:32个core.

 

 

到底他们在架构上采取了什么样的优化,并不得而知。但从中可以得知,采取大内存的处理比使用硬盘的快1000倍左右。所以我们也测试 了一下采用大内存的设计。使用的机器配置是32G,4个core CPU。

 

使用的搜索服务是用solr搭建的,主要修改它的索引目录位置,将索引目录设置为内存(在linux中,可以将内存映射为硬盘),然后关掉了其它8台大索引的服务,即是将主要的搜索服务都分给新配置的机器。测试了几天,它的性能果真是好很多。平均响应时间是30ms。在取文档的时间上几乎为0ms,主要消耗的时间在计算跟排序上,由于排序时用了六个索引字段,动态计算bf分数,这里才是费了最多时间的。而这里其实也可以优化的,即在建索引的时候,就先计算好每个文档的bf分数(有时间再做优化)。相信可以提高到10ms左右的响应时间 。

      solr的本身设计也是多线程,高峰的时候有几十条线程并发,负载到了4左右,现在单机的瓶颈在CPU上,如果cpu再高些,基本上就可以安稳地顶起高峰时期,或者再多台同样配置的机器负载。

 

现在的索引只有8G,如果到了20G(一亿左右的数据量)的话,不知道会怎么样,请拭目以待。



分享给朋友:
您可能感兴趣的文章:
随机阅读: