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的负载也不会太高。