之前是使用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的本身設計也是多執行緒，高峰的時候有幾十條執行緒併發，負載到了4左右，現在單機的瓶頸在cpu上，如果cpu再高些，基本上就可以安穩地頂起高峰時期，或者再多台同樣配置的機器負載。
現在的索引只有8g,如果到了20g（一億左右的資料量）的話，不知道會怎麼樣，請拭目以待。
如何提高和優化Lucene搜尋速度
這篇文章主要介紹了如何提高lucene的搜尋速度。介紹的大部分思路都是很容易嘗試的，當然另外一部分可能會加大你程式的複雜度。所以請確認搜尋速度確實很慢，而且很慢的原因確實是因為lucene自身而造成的。推薦姐妹篇 如何提高和優化lucene索引速度 遠端檔案系統一般來說都會降低搜尋速度。如果索引必須...
如何提高和優化Lucene搜尋速度（一）
這篇文章主要介紹了如何提高lucene的搜尋速度。介紹的大部分思路都是很容易嘗試的，當然另外一部分可能會加大你程式的複雜度。所以請確認搜尋速度確實很慢，而且很慢的原因確實是因為lucene自身而造成的。推薦姐妹篇 如何提高和優化lucene索引速度 遠端檔案系統一般來說都會降低搜尋速度。如果索引必須...
提高cin cout的速度
ios sync with stdio false 用來關閉iostream與stdio的同步，從而提高 cin cout 的效率，但是就不能再用 scanf printf 了，因為不關閉之前是c 為了與c相容，以免 cout 與 printf 一塊使用時造成混亂，才開啟同步，這樣可以提高一定的效率...