程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> 在MySQL中應用Sphinx完成多線程搜刮的辦法

在MySQL中應用Sphinx完成多線程搜刮的辦法

編輯:MySQL綜合教程

在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可以如斯輕易的擴大到你所須要的足夠多的機械上,而且這類方法在許多年前就曾經在被應用了。然後,我想,我並沒有和我平常一樣,應用這個特征來使得在一台機械上的查詢變得更快。嗯,這其實不是在說它很慢或許其實甚麼,只是,查詢永久不會太快,不是嗎?

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved