在MySQL中使用Sphinx實現(xiàn)多線程搜索的方法
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本身就支持分布式搜索，在很久以前就已經(jīng)朝著水平擴展的目標來設計。如果索引在一臺機器上放不下，可以讓多臺機器分別對不同的部分進行索引，設置一個聚合節(jié)點，負責從應用接收請求，然后把請求再同時發(fā)給所有的數(shù)據(jù)節(jié)點，最后將它們返回的結果合并起來，返回給應用。在應用看起來，就好像只有一臺服務器在為它服務。
好，下面你猜怎么著？哈，我們可以把這個功能應用到單臺機器上，讓我們的查詢快上n多倍。而且，現(xiàn)在Sphinx已經(jīng)支持這種做法了，所以我們根本不用再假裝查詢哪些遠程節(jié)點。
還有另外一個好處，配置分布式搜索以后，索引是可以并行建的！
還是有一點需要注意，雖然這種做法可以加速絕大多數(shù)的查詢，但還是有一些例外的情況。因為，并行的查詢結果仍然需要合并起來，而這個合并過程是單線程的。而且，合并包括一些CPU密集的操作，如分級、排序，甚至用GROUP BY進行COUNT，如果數(shù)據(jù)量很大，合并過程就會變成瓶頸。
要確認這一點也很簡單，只要查看Sphinx的查詢日志，看看每個查詢匹配的記錄數(shù)有多少，我們就心里有數(shù)了。
執(zhí)行
假設在服務器上一個索引配置如下 (很多細節(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個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
}
做完這些后，你需要重建索引. 但是現(xiàn)在idx1p0到idx1p2的索引indexer命令可以同步進行.
另外，用不同的操作來分離數(shù)據(jù)不是最好的辦法, 你可以在MYSQL中用一個輔助表來區(qū)分它們的范圍, 配合 sql_query_range使用或是別的什么, 具體根據(jù)你的數(shù)據(jù)來決定.
寫在最后
我一直都很喜歡 Sphinx，Sphinx可以如此容易的擴展到你所需要的足夠多的機器上，并且這種方式在很多年前就已經(jīng)在被使用了。然后，我想，我并沒有和我往常一樣，利用這個特性來使得在一臺機器上的查詢變得更快。嗯，這并不是在說它很慢或者其實什么，只是，查詢永遠不會太快，不是嗎？
相關文章
這篇文章主要介紹了MySQL中關于超鍵和主鍵及候選鍵的區(qū)別說明，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-07-07
MySQL的優(yōu)化指的是一個很大的系統(tǒng),面試的時候我之前是從sql的語句優(yōu)化方面去說的,這種優(yōu)化也有作用,不過是從邏輯方面去優(yōu)化,下面這篇文章主要給大家介紹了關于MySQL查詢緩存優(yōu)化的相關資料,需要的朋友可以參考下2022-10-10
AlmaLinux 9 安裝 MySQL 8.0.32的詳細過程
這篇文章主要介紹了AlmaLinux 9 安裝 MySQL 8.0.32的相關知識，本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2023-04-04
MySQL 有多種類型存儲日期和時間，例如 YEAR 和 DATE。MySQL 的時間類型存儲的精確度能到秒（MariaDB 可以到毫秒級）。但是，也可以通過時間計算達到毫秒級。時間類型的選擇沒有最佳，而是取決于業(yè)務需要如何處理時間的存儲。2021-06-06
本文主要介紹了MYSQL與sqlyog連接的實現(xiàn),文中通過圖文介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2023-10-10
本文介紹了MySQL服務端反向讀取客戶端任意文件的漏洞原理,利用LOADDATAINFILE語法實現(xiàn),通過偽造MySQL服務器,客戶端讀取的文件內容由服務端決定,漏洞復現(xiàn)步驟包括獲取腳本、修改配置、運行服務器、客戶端連接并查看日志,防范措施包括使用SSL模式和設置local_infile為02025-02-02
2022最新版MySQL 8.0.30 安裝及配置教程(小白入門)
這篇文章主要介紹了2022最新版MySQL 8.0.30 安裝及配置教程,安裝過程算是比較簡單的，今天給大家分享的此文比較適合mysql數(shù)據(jù)庫的小白，需要的朋友可以參考下2022-09-09
本文主要介紹了MySQL9.0默認路徑安裝下重置root密碼,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2025-02-02
MySQL數(shù)據(jù)庫引擎介紹、區(qū)別、創(chuàng)建和性能測試的深入分析
本篇文章是對MySQL數(shù)據(jù)庫引擎介紹、區(qū)別、創(chuàng)建和性能測試進行了詳細的分析介紹，需要的朋友參考下2013-06-06
深入理解SQL的四種連接-左外連接、右外連接、內連接、全連接
本篇文章是對SQL中的四種連接-左外連接、右外連接、內連接、全連接進行了詳細的分析介紹，需要的朋友參考下2013-07-07