Sphinx 搜索性能优化 ―― 多线程搜索

MySQL、Sphinx及许多数据库和搜索引擎中的查询是单线程的。比如说，在一台32个CPU核心、16个磁盘的R910服务器上执行一个查询，它最多只会用到一个核心和一个磁盘。没错，只会使用一个。 如果查询是CPU密集型作业，那么会使用大约3%的整机CPU能力(以上述32核机器为例)。如果是磁盘密集型，则大约会使用6%的整机IO能力(也是与上例同样的配置，16个磁盘组成RAID10或RAID0)。

AlfredCheung 翻译于 9个月前 1人顶 顶 翻译的不错哦!

我再换个说法吧。如果你在一台单核单磁盘的机器上执行了某个查询，花了10秒，那么把同样的查询放到一台32核16磁盘的机器上去跑，同样需要10秒，不会有丝毫改善。 你早就知道这一点了，对吧？那么，我的问题是――有没有办法可以改善呢？ 如果是Sphinx，太棒了，答案是有！而且不需要花上太多的工夫。你甚至不需要修改应用和数据库，只需要稍微改下Sphinx的配置。

AlfredCheung 翻译于 9个月前 1人顶 顶 翻译的不错哦!

计划 首先，我来说明一下我们的目标。 Sphinx本身就支持分布式搜索，在很久以前就已经朝着水平扩展的目标来设计。如果索引在一台机器上放不下，可以让多台机器分别对不同的部分进行索引，设置一个聚合节点，负责从应用接收请求，然后把请求再同时发给所有的数据节点，最后将它们返回的结果合并起来，返回给应用。在应用看起来，就好像只有一台服务器在为它服务。

AlfredCheung 翻译于 8个月前 1人顶 顶 翻译的不错哦!

好，下面你猜怎么着？哈，我们可以把这个功能应用到单台机器上，让我们的查询快上n多倍。而且，现在Sphinx已经支持这种做法了，所以我们根本不用再假装查询哪些远程节点。 还有另外一个好处，配置分布式搜索以后，索引是可以并行建的！ 还是有一点需要注意，虽然这种做法可以加速绝大多数的查询，但还是有一些例外的情况。因为，并行的查询结果仍然需要合并起来，而这个合并过程是单线程的。而且，合并包括一些CPU密集的操作，如分级、排序，甚至用GROUP BY进行COUNT，如果数据量很大，合并过程就会变成瓶颈。 要确认这一点也很简单，只要查看Sphinx的查询日志，看看每个查询匹配的记录数有多少，我们就心里有数了。

AlfredCheung 翻译于 8个月前 0人顶 顶 翻译的不错哦!

执行 假设在服务器上一个索引配置如下 (很多细节都省略了): 01 source src1 02 { 03 type = mysql 04 sql_query = SELECT id, text FROM table 05 } 06 07 index idx1 08 { 09 type = plain 10 source = src1 11 } 12 13 searchd 14 { 15 dist_threads = 0 # default 16 } 现在我们使用有3个CPU核心和磁盘的机器来做这个索引--就是这个idx1.下面是我们更改的配置文件 : 01 source src1 02 { 03 type = mysql 04 sql_query = SELECT id, text FROM table 05 } 06 07 source src1p0 : src1 08 { 09 sql_query = SELECT id, text FROM table WHERE id % 3 = 0; 10 } 11 12 source src1p1 : src1 13 { 14 sql_query = SELECT id, text FROM table WHERE id % 3 = 1; 15 } 16 17 source src1p2 : src1 18 { 19 sql_query = SELECT id, text FROM table WHERE id % 3 = 2; 20 } 21 22 index idx1_template 23 { 24 type = plain 25 source = src1 26 } 27 28 index idx1p0 : idx1_template 29 { 30 source = src0 31 } 32 33 index idx1p1 : idx1_template 34 { 35 source = src1 36 } 37 38 index idx1p2 : idx1_template 39 { 40 source = src2 41 } 42 43 index idx1 44 { 45 type = distributed 46 local = idx1p0 47 local = idx1p1 48 local = idx1p2 49 } 50 51 searchd 52 { 53 dist_threads = 3 54 } 做完这些后，你需要重建索引. 但是现在idx1p0到idx1p2的索引indexer命令可以同步进行. 另外，用不同的操作来分离数据不是最好的办法, 你可以在MYSQL中用一个辅助表来区分它们的范围, 配合 sql_query_range使用或是别的什么, 具体根据你的数据来决定.

原文链接 http://www.oschina.net/translate/sphinx-search-performance-optimization-multi-threaded-search