MySQL、Sphinx及許多數(shù)據(jù)庫和搜索引擎中的查詢是單線程的。比如說,在一臺32個CPU核心、16個磁盤的R910服務器上執(zhí)行一個查詢,它最多只會用到一個核心和一個磁盤。沒錯,只會使用一個。
如果查詢是CPU密集型作業(yè),那么會使用大約3%的整機CPU能力(以上述32核機器為例)。如果是磁盤密集型,則大約會使用6%的整機IO能力(也是與上例同樣的配置,16個磁盤組成RAID10或RAID0)。
我再換個說法吧。如果你在一臺單核單磁盤的機器上執(zhí)行了某個查詢,花了10秒,那么把同樣的查詢放到一臺32核16磁盤的機器上去跑,同樣需要10秒,不會有絲毫改善。
你早就知道這一點了,對吧?那么,我的問題是——有沒有辦法可以改善呢?
如果是Sphinx,太棒了,答案是有!而且不需要花上太多的工夫。你甚至不需要修改應用和數(shù)據(jù)庫,只需要稍微改下Sphinx的配置。
計劃
首先,我來說明一下我們的目標。
Sphinx本身就支持分布式搜索,在很久以前就已經朝著水平擴展的目標來設計。如果索引在一臺機器上放不下,可以讓多臺機器分別對不同的部分進行索引,設置一個聚合節(jié)點,負責從應用接收請求,然后把請求再同時發(fā)給所有的數(shù)據(jù)節(jié)點,最后將它們返回的結果合并起來,返回給應用。在應用看起來,就好像只有一臺服務器在為它服務。
好,下面你猜怎么著?哈,我們可以把這個功能應用到單臺機器上,讓我們的查詢快上n多倍。而且,現(xiàn)在Sphinx已經支持這種做法了,所以我們根本不用再假裝查詢哪些遠程節(jié)點。
還有另外一個好處,配置分布式搜索以后,索引是可以并行建的!
還是有一點需要注意,雖然這種做法可以加速絕大多數(shù)的查詢,但還是有一些例外的情況。因為,并行的查詢結果仍然需要合并起來,而這個合并過程是單線程的。而且,合并包括一些CPU密集的操作,如分級、排序,甚至用GROUP BY進行COUNT,如果數(shù)據(jù)量很大,合并過程就會變成瓶頸。
要確認這一點也很簡單,只要查看Sphinx的查詢日志,看看每個查詢匹配的記錄數(shù)有多少,我們就心里有數(shù)了。
假設在服務器上一個索引配置如下 (很多細節(jié)都省略了):
現(xiàn)在我們使用有3個CPU核心和磁盤的機器來做這個索引--就是這個idx1.下面是我們更改的配置文件 :
做完這些后,你需要重建索引. 但是現(xiàn)在idx1p0到idx1p2的索引indexer命令可以同步進行.
另外,用不同的操作來分離數(shù)據(jù)不是最好的辦法, 你可以在MYSQL中用一個輔助表來區(qū)分它們的范圍, 配合 sql_query_range使用或是別的什么, 具體根據(jù)你的數(shù)據(jù)來決定.