solr 搜索架构优化

solr 搜索架构优化

 

     刚刚将solrt升级到最新版本3.6.1，除了精简了索引结构设计，新版本的天生优势更加重要，比之前solr1.4的性能算是小部分提升，响应由100ms以内占80%升到了90%，且搜索系统稳定性好了很多，出现挂掉的机率降低了，当然还得继续观察。同时优化了旧的搜索系统架构 ，加上系统的配置优化管理，方便修改调整，对外提供的接口重新设计了一翻，加入了一些请求的跟踪，方便接口升级时能找到对应的前端请求位置，对症下药。同时对后面的架构优化打下很好的基础 .

 

 

    将现在架构大小索引方式，一个大索引有几千万数据 ，小索引几万数据，还有另一个结点有三百万左右数据，现在每天有900万左右的请求量，已经可以达到90%以上在100ms以下响应。但还是有少许的搜索可能达到了两秒以上，还有一个就是现在索引是放在共享内存里，如果那天这两台神机没有了话就比较麻烦，这次的升级就是一个经验，说明我们更希望在某些情况能使用更普通的机器就能完成，特别是在机器比较不允许的条件下， 这样的架构的存活才有可能 .

 

     所以才开始有想过测试将大索引切分为多个核来使用，因为搜索默认排序是由多维度动态计算的值来排序，所以，特别是在命中特别多文档的时候，计算耗时比较大，比如搜索高频词的时候。所以切为多个核，可以将这些计算分到其它机器，大索引分拆为小索引，倒排表索引数据 也变小，轻量级了，搜索命中这个环节也会提升，动态计算的这个，由于分担到多个机器并行计算，这两者的提升对于整体性能来说很重要。

当然这个也是有代价的，要牺牲一定的网络带宽以及http连接数，以前三个结点，对于每次的请求就变成了2*3+1=7个请求，现在分了差不多要10个结点，那么一个请求就变为了2*10+1=21个请求，还好这些请求是并发进行的，所以只取两个阶段请求最耗时再加结果合并消耗的时间 .所以这样的设计理论上应该是可以提高性能的，当然再怎么优化都需要经过实践才能证实，所以为了更好了做压力测试，引用了tcpcopy这个工具，引流线上的真实用户请求模拟测试对比。

 

暂时只需要测试大索引切分的几个结点的耗时，使用4台8核8g的机器作测试：（8个核 ，每个核大概是1G多索引数据，所以每台机器放两个核）

将索引数据全放在内存里，测试性能 响应特快，比现在的架构快了几倍

然后再把其中一台机器索引放到了硬盘，使用MMapDirectory方式，作对比后，效果也不错，性能没减。

现在全部使用MMapDirectory，看看效果是不是一样，如果这种方式可行的话，比完全放内存的方式维护方面更佳。测试效果也不错

整体性能可以估计提升了3倍左右，单测试高频词，更不只3倍，即使命中文档在1千万左右，也能在一秒左右响应，当然现实搜索这种情况会比较少，测试搜索长词的时候大多也是在100-200ms,当然实际中用户搜索串都是在7个字以内，响应都能保持在100ms以内，并且cpu的负载也不会太高。

 

测试10万请求只有1%的响应高于100ms。

 

当然现在变多个核，管理方面的优化也是要的，方便升级与调整，还有分多结点的时候，索引应该如何切分也是个要解决的问题。。

现在只是确认方案可行性。

 

可以测试搜索效果：http://so.56.com/all/%E6%A2%A6%E6%83%B3%E7%A7%80/

 

摘自互联网