来自： http://blog.csdn.net//wgw335363240/article/details/37922459

之前是使用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（一亿左右的数据量）的话，不知道会怎么样，请拭目以待。