在一次技術群中，中聽到一位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（一億左右的資料量）的話，不知道會怎麼樣，請拭目以待。