MySQL中使用Sphinx實現多線程搜索的方法

 　　這篇文章主要介紹了在MySQL中使用Sphinx實現多線程搜索的方法,修改Sphinx的搜索引擎配置即可,需要的朋友可以參考下

　　MySQL、Sphinx及許多數據庫和搜索引擎中的查詢是單線程的。比如說，在一台32個CPU核心、16個磁盤的R910服務器上執行一個查詢，它最多只會用到一個核心和一個磁盤。沒錯，只會使用一個。

　　如果查詢是CPU密集型作業，那麼會使用大約3%的整機CPU能力(以上述32核機器為例)。如果是磁盤密集型，則大約會使用6%的整機IO能力(也是與上例同樣的配置，16個磁盤組成RAID10或RAID0)。

　　我再換個說法吧。如果你在一台單核單磁盤的機器上執行了某個查詢，花了10秒，那麼把同樣的查詢放到一台32核16磁盤的機器上去跑，同樣需要10秒，不會有絲毫改善。

　　你早就知道這一點了，對吧?那麼，我的問題是——有沒有辦法可以改善呢?

　　如果是Sphinx，太棒了，答案是有!而且不需要花上太多的工夫。你甚至不需要修改應用和數據庫，只需要稍微改下Sphinx的配置。

　　計劃

　　首先，我來說明一下我們的目標。

　　Sphinx本身就支持分布式搜索，在很久以前就已經朝著水平擴展的目標來設計。如果索引在一台機器上放不下，可以讓多台機器分別對不同的部分進行索引，設置一個聚合節點，負責從應用接收請求，然後把請求再同時發給所有的數據節點，最後將它們返回的結果合並起來，返回給應用。在應用看起來，就好像只有一台服務器在為它服務。

　　好，下面你猜怎麼著?哈，我們可以把這個功能應用到單台機器上，讓我們的查詢快上n多倍。而且，現在Sphinx已經支持這種做法了，所以我們根本不用再假裝查詢哪些遠程節點。

　　還有另外一個好處，配置分布式搜索以後，索引是可以並行建的!

　　還是有一點需要注意，雖然這種做法可以加速絕大多數的查詢，但還是有一些例外的情況。因為，並行的查詢結果仍然需要合並起來，而這個合並過程是單線程的。而且，合並包括一些CPU密集的操作，如分級、排序，甚至用GROUP BY進行COUNT，如果數據量很大，合並過程就會變成瓶頸。

　　要確認這一點也很簡單，只要查看Sphinx的查詢日志，看看每個查詢匹配的記錄數有多少，我們就心裡有數了。

　　執行

　　假設在服務器上一個索引配置如下 (很多細節都省略了):

　　 代碼如下:

　　source src1

　　{

　　type = mysql

　　sql_query = SELECT id, text FROM table

　　}

　　index idx1

　　{

　　type = plain

　　source = src1

　　}

　　searchd

　　{

　　dist_threads = 0 # default

　　}

　　現在我們使用有3個CPU核心和磁盤的機器來做這個索引--就是這個idx1.下面是我們更改的配置文件 :

　　代碼如下:

　　source src1

　　{

　　type = mysql

　　sql_query = SELECT id, text FROM table

　　}

　　source src1p0 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 0;

　　}

　　source src1p1 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 1;

　　}

　　source src1p2 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 2;

　　}

　　index idx1_template

　　{

　　type = plain

　　source = src1

　　}

　　index idx1p0 : idx1_template

　　{

　　source = src0

　　}

　　index idx1p1 : idx1_template

　　{

　　source = src1

　　}

　　index idx1p2 : idx1_template

　　{

　　source = src2

　　}

　　index idx1

　　{

　　type = distributed

　　local = idx1p0

　　local = idx1p1

　　local = idx1p2

　　}

　　searchd

　　{

　　dist_threads = 3

　　}

　　做完這些後，你需要重建索引. 但是現在idx1p0到idx1p2的索引indexer命令可以同步進行.

　　另外，用不同的操作來分離數據不是最好的辦法, 你可以在MYSQL中用一個輔助表來區分它們的范圍, 配合 sql_query_range使用或是別的什麼, 具體根據你的數據來決定.

　　寫在最後

　　我一直都很喜歡 Sphinx，Sphinx可以如此容易的擴展到你所需要的足夠多的機器上，並且這種方式在很多年前就已經在被使用了。然後，我想，我並沒有和我往常一樣，利用這個特性來使得在一台機器上的查詢變得更快。嗯，這並不是在說它很慢或者其實什麼，只是，查詢永遠不會太快，不是嗎?