提高solr的搜索速度

來自： 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（一億左右的數據量）的話，不知道會怎么樣，請拭目以待。