在MySQL中應用Sphinx完成多線程搜刮的辦法。本站提示廣大學習愛好者:(在MySQL中應用Sphinx完成多線程搜刮的辦法)文章只能為提供參考,不一定能成為您想要的結果。以下是在MySQL中應用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可以如斯輕易的擴大到你所須要的足夠多的機械上,而且這類方法在許多年前就曾經在被應用了。然後,我想,我並沒有和我平常一樣,應用這個特征來使得在一台機械上的查詢變得更快。嗯,這其實不是在說它很慢或許其實甚麼,只是,查詢永久不會太快,不是嗎?