在MySQL中使用Sphinx實(shí)現(xiàn)多線程搜索的方法
MySQL、Sphinx及許多數(shù)據(jù)庫(kù)和搜索引擎中的查詢是單線程的。比如說(shuō),在一臺(tái)32個(gè)CPU核心、16個(gè)磁盤(pán)的R910服務(wù)器上執(zhí)行一個(gè)查詢,它最多只會(huì)用到一個(gè)核心和一個(gè)磁盤(pán)。沒(méi)錯(cuò),只會(huì)使用一個(gè)。
如果查詢是CPU密集型作業(yè),那么會(huì)使用大約3%的整機(jī)CPU能力(以上述32核機(jī)器為例)。如果是磁盤(pán)密集型,則大約會(huì)使用6%的整機(jī)IO能力(也是與上例同樣的配置,16個(gè)磁盤(pán)組成RAID10或RAID0)。
我再換個(gè)說(shuō)法吧。如果你在一臺(tái)單核單磁盤(pán)的機(jī)器上執(zhí)行了某個(gè)查詢,花了10秒,那么把同樣的查詢放到一臺(tái)32核16磁盤(pán)的機(jī)器上去跑,同樣需要10秒,不會(huì)有絲毫改善。
你早就知道這一點(diǎn)了,對(duì)吧?那么,我的問(wèn)題是——有沒(méi)有辦法可以改善呢?
如果是Sphinx,太棒了,答案是有!而且不需要花上太多的工夫。你甚至不需要修改應(yīng)用和數(shù)據(jù)庫(kù),只需要稍微改下Sphinx的配置。
計(jì)劃
首先,我來(lái)說(shuō)明一下我們的目標(biāo)。
Sphinx本身就支持分布式搜索,在很久以前就已經(jīng)朝著水平擴(kuò)展的目標(biāo)來(lái)設(shè)計(jì)。如果索引在一臺(tái)機(jī)器上放不下,可以讓多臺(tái)機(jī)器分別對(duì)不同的部分進(jìn)行索引,設(shè)置一個(gè)聚合節(jié)點(diǎn),負(fù)責(zé)從應(yīng)用接收請(qǐng)求,然后把請(qǐng)求再同時(shí)發(fā)給所有的數(shù)據(jù)節(jié)點(diǎn),最后將它們返回的結(jié)果合并起來(lái),返回給應(yīng)用。在應(yīng)用看起來(lái),就好像只有一臺(tái)服務(wù)器在為它服務(wù)。
好,下面你猜怎么著?哈,我們可以把這個(gè)功能應(yīng)用到單臺(tái)機(jī)器上,讓我們的查詢快上n多倍。而且,現(xiàn)在Sphinx已經(jīng)支持這種做法了,所以我們根本不用再假裝查詢哪些遠(yuǎn)程節(jié)點(diǎn)。
還有另外一個(gè)好處,配置分布式搜索以后,索引是可以并行建的!
還是有一點(diǎn)需要注意,雖然這種做法可以加速絕大多數(shù)的查詢,但還是有一些例外的情況。因?yàn)?,并行的查詢結(jié)果仍然需要合并起來(lái),而這個(gè)合并過(guò)程是單線程的。而且,合并包括一些CPU密集的操作,如分級(jí)、排序,甚至用GROUP BY進(jìn)行COUNT,如果數(shù)據(jù)量很大,合并過(guò)程就會(huì)變成瓶頸。
要確認(rèn)這一點(diǎn)也很簡(jiǎn)單,只要查看Sphinx的查詢?nèi)罩荆纯疵總€(gè)查詢匹配的記錄數(shù)有多少,我們就心里有數(shù)了。
執(zhí)行
假設(shè)在服務(wù)器上一個(gè)索引配置如下 (很多細(xì)節(jié)都省略了):
source src1
{
type = mysql
sql_query = SELECT id, text FROM table
}
index idx1
{
type = plain
source = src1
}
searchd
{
dist_threads = 0 # default
}
現(xiàn)在我們使用有3個(gè)CPU核心和磁盤(pán)的機(jī)器來(lái)做這個(gè)索引--就是這個(gè)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
}
做完這些后,你需要重建索引. 但是現(xiàn)在idx1p0到idx1p2的索引indexer命令可以同步進(jìn)行.
另外,用不同的操作來(lái)分離數(shù)據(jù)不是最好的辦法, 你可以在MYSQL中用一個(gè)輔助表來(lái)區(qū)分它們的范圍, 配合 sql_query_range使用或是別的什么, 具體根據(jù)你的數(shù)據(jù)來(lái)決定.
寫(xiě)在最后
我一直都很喜歡 Sphinx,Sphinx可以如此容易的擴(kuò)展到你所需要的足夠多的機(jī)器上,并且這種方式在很多年前就已經(jīng)在被使用了。然后,我想,我并沒(méi)有和我往常一樣,利用這個(gè)特性來(lái)使得在一臺(tái)機(jī)器上的查詢變得更快。嗯,這并不是在說(shuō)它很慢或者其實(shí)什么,只是,查詢永遠(yuǎn)不會(huì)太快,不是嗎?
- 淺談Coreseek、Sphinx-for-chinaese、Sphinx+Scws的區(qū)別
- centos+php+coreseek+sphinx+mysql之一coreseek安裝篇
- 使用rst2pdf實(shí)現(xiàn)將sphinx生成PDF
- php啟用sphinx全文搜索的實(shí)現(xiàn)方法
- 關(guān)于Sphinx創(chuàng)建全文檢索的索引介紹
- 深入解析php之sphinx
- sphinxql如何得到結(jié)果數(shù)及show meta的詳細(xì)說(shuō)明
- Sphinx/MySQL 協(xié)議支持與SphinxQL應(yīng)用實(shí)例
- sphinx增量索引的一個(gè)問(wèn)題
- Python Sphinx使用實(shí)例及問(wèn)題解決
相關(guān)文章
MYSQL查詢時(shí)間范圍內(nèi)的數(shù)據(jù)示例代碼
這篇文章主要介紹了MYSQL查詢時(shí)間范圍內(nèi)的數(shù)據(jù),本文通過(guò)實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-06-06解析mysql中如何獲得數(shù)據(jù)庫(kù)的大小
本篇文章是對(duì)mysql中如何獲得數(shù)據(jù)庫(kù)的大小的解決方法進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下2013-06-06MySQL索引詳解及演進(jìn)過(guò)程及面試題延伸
這篇文章主要介紹了MySQL索引詳解及演進(jìn)過(guò)程以及延申出面試題,索引在關(guān)系型數(shù)據(jù)庫(kù)中,是一種單獨(dú)的、物理的對(duì)數(shù)據(jù)庫(kù)表中的一列或者多列值進(jìn)行排序的一種存儲(chǔ)結(jié)構(gòu)2022-07-07MySQL數(shù)據(jù)類(lèi)型優(yōu)化原則
這篇文章主要介紹了MySQL數(shù)據(jù)類(lèi)型優(yōu)化原則的相關(guān)資料,幫助大家更好的理解和使用MySQL數(shù)據(jù)庫(kù),感興趣的朋友可以了解下2020-11-11mysql之validate_password_policy的使用
這篇文章主要介紹了mysql之validate_password_policy的使用,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-05-05