[文章作者：张宴 本文版本：v1.0 最后修改：2008.12.09 转载请注明原文链接：
http://blog.s135.com/post/385/]
曾经在七月，写过一篇文章──《
基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
①、Web应用服务器通过HTTP POST/GET方式，将搜索关键字等条件，传递给搜索引擎服务器的search.php接口；
②③、search.php通过Sphinx的API（我根据最新的Sphinx 0.9.9-rc1 API，改写了一个C语言的PHP扩展sphinx.so），查询Sphinx索引服务，取得满足查询条件的搜索引擎唯一ID（15位搜索唯一ID：前5位类别ID+后10位原数据表主键ID）列表；
④⑤、search.php将这些ID号作为key，通过Memcache协议一次性从Tokyo Tyrant中mget取回ID号对应的文本数据。
⑥⑦、search.php将搜索结果集，按查询条件，进行摘要和关键字高亮显示处理，以JSON格式或XML格式返回给Web应用服务器。
2、索引更新接口：
⑴、Web应用服务器通过HTTP POST/GET方式，将要增加、删除、更新的内容告知搜索服务器的update.php接口；
⑵、update.php将接收到的信息处理后，写入TT高速队列（我基于Tokyo Tyrant做的一个队列系统）；
注：这两步的速度可达到1500次请求/秒以上，可应对6000万PV的搜索索引更新调用。
3、搜索索引与数据存储控制：
㈠、“队列控制器”守护进程从TT高速队列中循环读取信息（每次50条，直到末尾）；
㈡、“队列控制器”将读取出的信息写入搜索引擎数据存储层Tokyo Tyrant；
㈢、“队列控制器”将读取出的信息
异步写入MySQL主表（这张主表按500万条记录进行分区，仅作为数据永久性备份用）；
㈣、“队列控制器”将读取出的信息写入MySQL增量表；
㈤、“队列控制器”在1分钟内，触发Sphinx更新增量索引，Sphinx的indexer会将MySQL增量表作为数据源，建立增量索引。Sphinx的增量索引和作为数据源的MySQL增量表成对应关系；
㈥、“队列控制器”每间隔3小时，短暂停止从TT高速队列中读取信息，并触发Sphinx将增量索引合并入主索引（这个过程非常快），同时清空MySQL增量表（保证了MySQL增量表的记录数始终只有几千条至几十万条，大大加快Sphinx增量索引更新速度），然后恢复从TT高速队列中取出数据，写入MySQL增量表。
本架构使用的开源软件：
1、Sphinx 0.9.9-rc1
2、Tokyo Tyrant 1.1.9
3、MySQL 5.1.30
4、Nginx 0.7.22
5、PHP 5.2.6
本架构自主研发的程序：
1、搜索查询接口（search.php）
2、索引更新接口（update.php）
3、队列控制器
4、Sphinx 0.9.9-rc1 API的PHP扩展（sphinx.so）
5、基于Tokyo Tyrant的高速队列系统
附1：MySQL FullText、Lucene搜索、Sphinx搜索的第三方对比结果：
1、查询速度：
MySQL FullText最慢，Lucene、Sphinx查询速度不相上下，Sphinx稍占优势。
2、建索引速度：
Sphinx建索引速度是最快的，比Lucene快9倍以上。因此，Sphinx非常适合做准实时搜索引擎。
3、详细对比数据见以下PDF文档：
下载文件
附2：国内各大中文搜索引擎搜索速度分析：
以“APMServ张宴”为关键字，比较在各大中文搜索引擎的搜索速度：
1、百度：
①、第一次搜索
②、第二次搜索
分析：百度对第一次搜索的搜索结果做了Cache，所以第二次查询非常快。
2、谷歌：
①、第一次搜索
②、第二次搜索
分析：谷歌也对第一次搜索的搜索结果做了Cache，但两次查询跟百度同比，都要慢一些。
3、搜狗：
①、第一次搜索
②、第二次搜索
③、第三次搜索
分析：搜狗疑似对第一次搜索的搜索结果做了短暂的Cache，第二次搜索速度非常快，第三次搜索的速度比第二次搜索的速度慢。搜狗第一次搜索的速度跟百度差不多。
4、中国雅虎：
①、第一次搜索
②、第二次搜索
分析：搜索结果没有做Cache。中国雅虎的搜索速度跟百度第一次搜索的速度差不多。
5、网易有道：
①、第一次搜索
②、第二次搜索
分析：有道对第一次搜索的搜索结果做了Cache。但是，跟谷歌一样，两次搜索同比都要较百度、搜狗、中国雅虎慢一些。
基于Sphinx构建准实时更新的分布式通用搜索引擎平台[原创]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.12.09 转载请注明原文链接：
http://blog.s135.com/post/385/]
曾经在七月，写过一篇文章──《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
①、Web应用服务器通过HTTP POST/GET方式，将搜索关键字等条件，传递给搜索引擎服务器的search.php接口；
②③、search.php通过Sphinx的API（我根据最新的Sphinx 0.9.9-rc1 API，改写了一个C语言的PHP扩展sphinx.so），查询Sphinx索引服务，取得满足查询条件的搜索引擎唯一ID（15位搜索唯一ID：前5位类别ID+后10位原数据表主键ID）列表；
④⑤、search.php将这些ID号作为key，通过Memcache协议一次性从Tokyo Tyrant中mget取回ID号对应的文本数据。
⑥⑦、search.php将搜索结果集，按查询条件，进行摘要和关键字高亮显示处理，以JSON格式或XML格式返回给Web应用服务器。
2、索引更新接口：
⑴、Web应用服务器通过HTTP POST/GET方式，将要增加、删除、更新的内容告知搜索服务器的update.php接口；
⑵、update.php将接收到的信息处理后，写入TT高速队列（我基于Tokyo Tyrant做的一个队列系统）；
注：这两步的速度可达到1500次请求/秒以上，可应对6000万PV的搜索索引更新调用。
3、搜索索引与数据存储控制：
㈠、“队列控制器”守护进程从TT高速队列中循环读取信息（每次50条，直到末尾）；
㈡、“队列控制器”将读取出的信息写入搜索引擎数据存储层Tokyo Tyrant；
㈢、“队列控制器”将读取出的信息 异步写入MySQL主表（这张主表按500万条记录进行分区，仅作为数据永久性备份用）；
㈣、“队列控制器”将读取出的信息写入MySQL增量表；
㈤、“队列控制器”在1分钟内，触发Sphinx更新增量索引，Sphinx的indexer会将MySQL增量表作为数据源，建立增量索引。Sphinx的增量索引和作为数据源的MySQL增量表成对应关系；
㈥、“队列控制器”每间隔3小时，短暂停止从TT高速队列中读取信息，并触发Sphinx将增量索引合并入主索引（这个过程非常快），同时清空MySQL增量表（保证了MySQL增量表的记录数始终只有几千条至几十万条，大大加快Sphinx增量索引更新速度），然后恢复从TT高速队列中取出数据，写入MySQL增量表。
本架构使用的开源软件：
1、Sphinx 0.9.9-rc1
2、Tokyo Tyrant 1.1.9
3、MySQL 5.1.30
4、Nginx 0.7.22
5、PHP 5.2.6
本架构自主研发的程序：
1、搜索查询接口（search.php）
2、索引更新接口（update.php）
3、队列控制器
4、Sphinx 0.9.9-rc1 API的PHP扩展（sphinx.so）
5、基于Tokyo Tyrant的高速队列系统
附1：MySQL FullText、Lucene搜索、Sphinx搜索的第三方对比结果：
1、查询速度：
MySQL FullText最慢，Lucene、Sphinx查询速度不相上下，Sphinx稍占优势。
2、建索引速度：
Sphinx建索引速度是最快的，比Lucene快9倍以上。因此，Sphinx非常适合做准实时搜索引擎。
3、详细对比数据见以下PDF文档：
下载文件
附2：国内各大中文搜索引擎搜索速度分析：
以“APMServ张宴”为关键字，比较在各大中文搜索引擎的搜索速度：
1、百度：
①、第一次搜索
②、第二次搜索
分析：百度对第一次搜索的搜索结果做了Cache，所以第二次查询非常快。
2、谷歌：
①、第一次搜索
②、第二次搜索
分析：谷歌也对第一次搜索的搜索结果做了Cache，但两次查询跟百度同比，都要慢一些。
3、搜狗：
①、第一次搜索
②、第二次搜索
③、第三次搜索
分析：搜狗疑似对第一次搜索的搜索结果做了短暂的Cache，第二次搜索速度非常快，第三次搜索的速度比第二次搜索的速度慢。搜狗第一次搜索的速度跟百度差不多。
4、中国雅虎：
①、第一次搜索
②、第二次搜索
分析：搜索结果没有做Cache。中国雅虎的搜索速度跟百度第一次搜索的速度差不多。
5、网易有道：
①、第一次搜索
②、第二次搜索
分析：有道对第一次搜索的搜索结果做了Cache。但是，跟谷歌一样，两次搜索同比都要较百度、搜狗、中国雅虎慢一些。
曾经在七月，写过一篇文章──《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
①、Web应用服务器通过HTTP POST/GET方式，将搜索关键字等条件，传递给搜索引擎服务器的search.php接口；
②③、search.php通过Sphinx的API（我根据最新的Sphinx 0.9.9-rc1 API，改写了一个C语言的PHP扩展sphinx.so），查询Sphinx索引服务，取得满足查询条件的搜索引擎唯一ID（15位搜索唯一ID：前5位类别ID+后10位原数据表主键ID）列表；
④⑤、search.php将这些ID号作为key，通过Memcache协议一次性从Tokyo Tyrant中mget取回ID号对应的文本数据。
⑥⑦、search.php将搜索结果集，按查询条件，进行摘要和关键字高亮显示处理，以JSON格式或XML格式返回给Web应用服务器。
2、索引更新接口：
⑴、Web应用服务器通过HTTP POST/GET方式，将要增加、删除、更新的内容告知搜索服务器的update.php接口；
⑵、update.php将接收到的信息处理后，写入TT高速队列（我基于Tokyo Tyrant做的一个队列系统）；
注：这两步的速度可达到1500次请求/秒以上，可应对6000万PV的搜索索引更新调用。
3、搜索索引与数据存储控制：
㈠、“队列控制器”守护进程从TT高速队列中循环读取信息（每次50条，直到末尾）；
㈡、“队列控制器”将读取出的信息写入搜索引擎数据存储层Tokyo Tyrant；
㈢、“队列控制器”将读取出的信息 异步写入MySQL主表（这张主表按500万条记录进行分区，仅作为数据永久性备份用）；
㈣、“队列控制器”将读取出的信息写入MySQL增量表；
㈤、“队列控制器”在1分钟内，触发Sphinx更新增量索引，Sphinx的indexer会将MySQL增量表作为数据源，建立增量索引。Sphinx的增量索引和作为数据源的MySQL增量表成对应关系；
㈥、“队列控制器”每间隔3小时，短暂停止从TT高速队列中读取信息，并触发Sphinx将增量索引合并入主索引（这个过程非常快），同时清空MySQL增量表（保证了MySQL增量表的记录数始终只有几千条至几十万条，大大加快Sphinx增量索引更新速度），然后恢复从TT高速队列中取出数据，写入MySQL增量表。
本架构使用的开源软件：
1、Sphinx 0.9.9-rc1
2、Tokyo Tyrant 1.1.9
3、MySQL 5.1.30
4、Nginx 0.7.22
5、PHP 5.2.6
本架构自主研发的程序：
1、搜索查询接口（search.php）
2、索引更新接口（update.php）
3、队列控制器
4、Sphinx 0.9.9-rc1 API的PHP扩展（sphinx.so）
5、基于Tokyo Tyrant的高速队列系统
附1：MySQL FullText、Lucene搜索、Sphinx搜索的第三方对比结果：
1、查询速度：
MySQL FullText最慢，Lucene、Sphinx查询速度不相上下，Sphinx稍占优势。
2、建索引速度：
Sphinx建索引速度是最快的，比Lucene快9倍以上。因此，Sphinx非常适合做准实时搜索引擎。
3、详细对比数据见以下PDF文档：
下载文件
附2：国内各大中文搜索引擎搜索速度分析：
以“APMServ张宴”为关键字，比较在各大中文搜索引擎的搜索速度：
1、百度：
①、第一次搜索
②、第二次搜索
分析：百度对第一次搜索的搜索结果做了Cache，所以第二次查询非常快。
2、谷歌：
①、第一次搜索
②、第二次搜索
分析：谷歌也对第一次搜索的搜索结果做了Cache，但两次查询跟百度同比，都要慢一些。
3、搜狗：
①、第一次搜索
②、第二次搜索
③、第三次搜索
分析：搜狗疑似对第一次搜索的搜索结果做了短暂的Cache，第二次搜索速度非常快，第三次搜索的速度比第二次搜索的速度慢。搜狗第一次搜索的速度跟百度差不多。
4、中国雅虎：
①、第一次搜索
②、第二次搜索
分析：搜索结果没有做Cache。中国雅虎的搜索速度跟百度第一次搜索的速度差不多。
5、网易有道：
①、第一次搜索
②、第二次搜索
分析：有道对第一次搜索的搜索结果做了Cache。但是，跟谷歌一样，两次搜索同比都要较百度、搜狗、中国雅虎慢一些。
[
2010-2-5 08:50 | by
张宴 ]
2010-2-5 08:50 | by
张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2010.02.05 转载请注明原文链接：
http://blog.s135.com/sphinx_search/]
前言：
2008年7月，我写过一篇文章《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》。有不少网友希望阅读全文，我将该文档整理了一下，分享出来。文档解压后大小为7.33M，共19页。
本站下载地址： http://blog.s135.com/book/sphinx/sphinx_mysql.zip
新浪下载分流： http://ishare.iask.sina.com.cn/f/6728201.html
上述文档架构存在的局限，我在2008年12月的文章《 亿级数据的高并发通用搜索引擎架构设计》中已经指出：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。虽然如此，但对于一些写入量不大的搜索应用，已经足够了，或许对很多人会有帮助。
正文：
在这之后，本人基于《 亿级数据的高并发通用搜索引擎架构设计》开发的Sphinx分布式通用站内搜索引擎平台，已经在生产环境运行9个月以上，经过运营中的不断完善与改进，目前已形成了一套可扩展的分布式通用站内搜索引擎框架。CMS、视频、论坛等产品发生的增、删、改操作，文本内容实时写入自行开发的 HTTPSQS 高性能简单消息队列服务，通过队列控制器更新索引和存储。提供支持XML、JSON的API查询接口，支持亿级数据的索引、分布式、中文分词、高亮显示、自动摘要、准实时（1分钟内）增量索引更新。
下面是Sphinx新的搜索架构中技术关键点实现方式的一些介绍，与大家分享、交流一下：
1、一元分词和中文分词的结合：
①、一元分词位于索引更新模块。Sphinx索引引擎对于CJK（中日韩）语言（必须是UTF-8编码）支持一元切分，假设【反恐行动是国产主视角射击网络游戏】这段文字，Sphinx会将其切成【反 恐 行 动 是 国 产 主 视 角 射 击 网 络 游 戏】，然后对每个字建立反向索引。如果用这句话中包含的字组成一个不存在的词语，例如【恐动】，也会被搜索到，所以搜索时，需要加引号，例如搜索【"反恐行动"】，就能完全匹配连在一起的四个字，不连续的【"恐动"】就不会被搜索到。但是，这样还有一个问题，搜索【"反恐行动游戏"】或【"国产网络游戏"】就会搜索不到。对于这个问题，采用位于搜索查询模块的中文分词来处理。
sphinx.conf配置文件中关于UTF-8中文一元分词的配置如下：
②、中文分词位于搜索查询模块。搜索“反恐行动游戏”、“国产网络游戏”，先调用独立的中文分词系统，分别切分为“反恐行动 游戏”、“国产 网络游戏”，这时候，再给以空格分隔的词语加上引号，去Sphinx搜索【"反恐行动" "游戏"】或【"国产" "网络游戏"】，就能搜索到这条记录了。中文分词词库发生增、删、改，无需重建整个Sphinx搜索索引。
2、使用自行开发的HTTPSQS（http://code.google.com/p/httpsqs）开源简单队列服务程序，来缓冲高并发数据写入
新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容通过更新接口实时写入HTTPSQS队列，再通过队列控制器更新到Sphinx搜索引擎索引中。
3、Sphinx不能严格按照字段排序的小问题
如果不想使用权重，只希望严格按照时间、主键等排序，而匹配模式（Matching modes）又为非SPH_MATCH_BOOLEAN时（比较常用的是SPH_MATCH_ALL、SPH_MATCH_EXTENDED），Sphinx搜索结果在某一页中的排序会不太准确。例如：按照UNIX时间戳倒序排序，0,20为第一页，20,40为第二页，第一页的最小时间戳一定会大于第二页的最大时间戳，但是，第一页中的0,20条记录却不会严格按照时间戳排序，第二页亦是如此。因此，如果需要精确排序，用户翻到搜索结果的某一页，就需要对Sphinx在某一搜索结果页中的记录另行再排序，在我的这套搜索架构中，这一再排序操作由search.php查询接口使用array_multisort()函数处理。一般情况下，一页只会显示5～30条记录，因此，只对几十条记录采用PHP再排序，速度也是非常快的。
4、队列控制器中“时间控制”与“数量控制”相结合，实现搜索索引的1分钟内准实时更新：
①、Sphinx 0.9.9生产环境的建索引速度大约在5.5 Mbytes/秒、6400文档/秒。队列控制器可以设置10秒钟更新一次增量索引，只要Sphinx增量索引数据源的文档数在38万以内，就能保证增量索引在1～60秒内得到更新，这是从“时间”上进行控制。
②、为了避免增量索引数据源的文档数增长到38万，队列控制器在增量索引数据源的文档数超过1万时，还将激活增量索引合并入主索引的操作，合并完成的文档将从增量索引数据源中删除，这是从“数量”上进行控制。
前言：
2008年7月，我写过一篇文章《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》。有不少网友希望阅读全文，我将该文档整理了一下，分享出来。文档解压后大小为7.33M，共19页。
本站下载地址： http://blog.s135.com/book/sphinx/sphinx_mysql.zip
新浪下载分流： http://ishare.iask.sina.com.cn/f/6728201.html
上述文档架构存在的局限，我在2008年12月的文章《 亿级数据的高并发通用搜索引擎架构设计》中已经指出：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。虽然如此，但对于一些写入量不大的搜索应用，已经足够了，或许对很多人会有帮助。
正文：
在这之后，本人基于《 亿级数据的高并发通用搜索引擎架构设计》开发的Sphinx分布式通用站内搜索引擎平台，已经在生产环境运行9个月以上，经过运营中的不断完善与改进，目前已形成了一套可扩展的分布式通用站内搜索引擎框架。CMS、视频、论坛等产品发生的增、删、改操作，文本内容实时写入自行开发的 HTTPSQS 高性能简单消息队列服务，通过队列控制器更新索引和存储。提供支持XML、JSON的API查询接口，支持亿级数据的索引、分布式、中文分词、高亮显示、自动摘要、准实时（1分钟内）增量索引更新。
下面是Sphinx新的搜索架构中技术关键点实现方式的一些介绍，与大家分享、交流一下：
1、一元分词和中文分词的结合：
①、一元分词位于索引更新模块。Sphinx索引引擎对于CJK（中日韩）语言（必须是UTF-8编码）支持一元切分，假设【反恐行动是国产主视角射击网络游戏】这段文字，Sphinx会将其切成【反 恐 行 动 是 国 产 主 视 角 射 击 网 络 游 戏】，然后对每个字建立反向索引。如果用这句话中包含的字组成一个不存在的词语，例如【恐动】，也会被搜索到，所以搜索时，需要加引号，例如搜索【"反恐行动"】，就能完全匹配连在一起的四个字，不连续的【"恐动"】就不会被搜索到。但是，这样还有一个问题，搜索【"反恐行动游戏"】或【"国产网络游戏"】就会搜索不到。对于这个问题，采用位于搜索查询模块的中文分词来处理。
sphinx.conf配置文件中关于UTF-8中文一元分词的配置如下：
...省略...
index t_source_main
{
source = t_source_main
path = /data0/search/sphinx/data/t_source_main
docinfo = extern
mlock = 0
morphology = none
min_word_len = 1
charset_type = utf-8
min_prefix_len = 0
html_strip = 1
charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
ngram_len = 1
ngram_chars = U+3000..U+2FA1F
}
...省略...
index t_source_main
{
source = t_source_main
path = /data0/search/sphinx/data/t_source_main
docinfo = extern
mlock = 0
morphology = none
min_word_len = 1
charset_type = utf-8
min_prefix_len = 0
html_strip = 1
charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
ngram_len = 1
ngram_chars = U+3000..U+2FA1F
}
...省略...
②、中文分词位于搜索查询模块。搜索“反恐行动游戏”、“国产网络游戏”，先调用独立的中文分词系统，分别切分为“反恐行动 游戏”、“国产 网络游戏”，这时候，再给以空格分隔的词语加上引号，去Sphinx搜索【"反恐行动" "游戏"】或【"国产" "网络游戏"】，就能搜索到这条记录了。中文分词词库发生增、删、改，无需重建整个Sphinx搜索索引。
2、使用自行开发的HTTPSQS（http://code.google.com/p/httpsqs）开源简单队列服务程序，来缓冲高并发数据写入
新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容通过更新接口实时写入HTTPSQS队列，再通过队列控制器更新到Sphinx搜索引擎索引中。
3、Sphinx不能严格按照字段排序的小问题
如果不想使用权重，只希望严格按照时间、主键等排序，而匹配模式（Matching modes）又为非SPH_MATCH_BOOLEAN时（比较常用的是SPH_MATCH_ALL、SPH_MATCH_EXTENDED），Sphinx搜索结果在某一页中的排序会不太准确。例如：按照UNIX时间戳倒序排序，0,20为第一页，20,40为第二页，第一页的最小时间戳一定会大于第二页的最大时间戳，但是，第一页中的0,20条记录却不会严格按照时间戳排序，第二页亦是如此。因此，如果需要精确排序，用户翻到搜索结果的某一页，就需要对Sphinx在某一搜索结果页中的记录另行再排序，在我的这套搜索架构中，这一再排序操作由search.php查询接口使用array_multisort()函数处理。一般情况下，一页只会显示5～30条记录，因此，只对几十条记录采用PHP再排序，速度也是非常快的。
4、队列控制器中“时间控制”与“数量控制”相结合，实现搜索索引的1分钟内准实时更新：
①、Sphinx 0.9.9生产环境的建索引速度大约在5.5 Mbytes/秒、6400文档/秒。队列控制器可以设置10秒钟更新一次增量索引，只要Sphinx增量索引数据源的文档数在38万以内，就能保证增量索引在1～60秒内得到更新，这是从“时间”上进行控制。
②、为了避免增量索引数据源的文档数增长到38万，队列控制器在增量索引数据源的文档数超过1万时，还将激活增量索引合并入主索引的操作，合并完成的文档将从增量索引数据源中删除，这是从“数量”上进行控制。
基于HTTP协议的开源中文分词系统：HTTPCWS 1.0.0 发布[原创]
[
2009-8-11 08:45 | by
张宴 ]
2009-8-11 08:45 | by
张宴 ]
发布版本：
httpcws 1.0.0 （最新版本：2009-08-10发布）
程序网址： http://code.google.com/p/httpcws
安装使用手册： http://blog.s135.com/httpcws_v100/
下载地址（32位版）： http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
下载地址（64位版）： http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
中文分词在线演示： http://blog.s135.com/demo/httpcws/
PHP演示程序下载： http://blog.s135.com/demo/httpcws/httpcws-php-demo.zip
httpcws 中文简介
1、什么是 httpcws ？
HTTPCWS 是一款基于HTTP协议的开源中文分词系统，目前仅支持Linux系统。HTTPCWS 使用“ICTCLAS 3.0 2009共享版中文分词算法”的API进行分词处理，得出分词结果。HTTPCWS 将取代本人之前开发的 PHPCWS 中文分词扩展。
ICTCLAS（Institute of Computing Technology, Chinese Lexical Analysis System）是中国科学院计算技术研究所在多年研究工作积累的基础上，基于多层隐马模型研制出的汉语词法分析系统，主要功能包括中文分词；词性标注；命名实体识别；新词识别；同时支持用户词典。ICTCLAS经过五年精心打造，内核升级6次，目前已经升级到了ICTCLAS3.0，分词精度98.45%，各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名，在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名，是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的，而免费提供的 ICTCLAS 3.0 共享版不开源，词库是根据人民日报一个月的语料得出的，很多词语不存在。所以本人补充的一个19万条词语的自定义词库，对ICTCLAS分词结果进行合并处理，输出最终分词结果。
由于 ICTCLAS 3.0 2009 共享版只支持GBK编码，因此，如果是UTF-8编码的字符串，可以先用iconv函数转换成GBK编码，再用httpcws进行分词处理，最后转换回UTF-8编码。
HTTPCWS 软件自身（包括httpcws.cpp源文件、dict/httpcws_dict.txt自定义词库）采用NewBSD开源协议，可以自由修改。HTTPCWS 使用的 ICTCLAS 共享版 API 及 dict/Data/ 目录内的语料库，版权及著作权归中国科学院计算技术研究所、ictclas.org所有，使用需遵循其相关协议。
2、httpcws 中文分词在线演示
演示网址： http://blog.s135.com/demo/httpcws/
3、httpcws 中文分词下载安装
32位版：
64位版：
命令行启动参数：
4、httpcws 使用方法
GET方法（文本长度受URL的长度限制，需要分词的文本为GBK编码，最好采用urlencode对文本进行编码）：
POST方法（文本长度无限制，适用于大文本分词，需要分词的文本为GBK编码，最好采用urlencode对文本进行编码）：
PHP 调用 HTTPCWS 示例：
①、对GBK编码的字符串进行中文分词处理（HTTP POST方式）：
httpcws 1.0.0 （最新版本：2009-08-10发布）
程序网址： http://code.google.com/p/httpcws
安装使用手册： http://blog.s135.com/httpcws_v100/
下载地址（32位版）： http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
下载地址（64位版）： http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
中文分词在线演示： http://blog.s135.com/demo/httpcws/
PHP演示程序下载： http://blog.s135.com/demo/httpcws/httpcws-php-demo.zip
httpcws 中文简介
1、什么是 httpcws ？
HTTPCWS 是一款基于HTTP协议的开源中文分词系统，目前仅支持Linux系统。HTTPCWS 使用“ICTCLAS 3.0 2009共享版中文分词算法”的API进行分词处理，得出分词结果。HTTPCWS 将取代本人之前开发的 PHPCWS 中文分词扩展。
ICTCLAS（Institute of Computing Technology, Chinese Lexical Analysis System）是中国科学院计算技术研究所在多年研究工作积累的基础上，基于多层隐马模型研制出的汉语词法分析系统，主要功能包括中文分词；词性标注；命名实体识别；新词识别；同时支持用户词典。ICTCLAS经过五年精心打造，内核升级6次，目前已经升级到了ICTCLAS3.0，分词精度98.45%，各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名，在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名，是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的，而免费提供的 ICTCLAS 3.0 共享版不开源，词库是根据人民日报一个月的语料得出的，很多词语不存在。所以本人补充的一个19万条词语的自定义词库，对ICTCLAS分词结果进行合并处理，输出最终分词结果。
由于 ICTCLAS 3.0 2009 共享版只支持GBK编码，因此，如果是UTF-8编码的字符串，可以先用iconv函数转换成GBK编码，再用httpcws进行分词处理，最后转换回UTF-8编码。
HTTPCWS 软件自身（包括httpcws.cpp源文件、dict/httpcws_dict.txt自定义词库）采用NewBSD开源协议，可以自由修改。HTTPCWS 使用的 ICTCLAS 共享版 API 及 dict/Data/ 目录内的语料库，版权及著作权归中国科学院计算技术研究所、ictclas.org所有，使用需遵循其相关协议。
2、httpcws 中文分词在线演示
演示网址： http://blog.s135.com/demo/httpcws/
3、httpcws 中文分词下载安装
32位版：
cd /usr/local/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
tar zxvf httpcws-1.0.0-i386-bin.tar.gz
rm -f httpcws-1.0.0-i386-bin.tar.gz
cd httpcws-1.0.0-i386-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-i386-bin/httpcws -d -x /usr/local/httpcws-1.0.0-i386-bin/dict/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-i386-bin.tar.gz
tar zxvf httpcws-1.0.0-i386-bin.tar.gz
rm -f httpcws-1.0.0-i386-bin.tar.gz
cd httpcws-1.0.0-i386-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-i386-bin/httpcws -d -x /usr/local/httpcws-1.0.0-i386-bin/dict/
64位版：
cd /usr/local/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
tar zxvf httpcws-1.0.0-x86_64-bin.tar.gz
rm -f httpcws-1.0.0-x86_64-bin.tar.gz
cd httpcws-1.0.0-x86_64-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-x86_64-bin/httpcws -d -x /usr/local/httpcws-1.0.0-x86_64-bin/dict/
wget http://httpcws.googlecode.com/files/httpcws-1.0.0-x86_64-bin.tar.gz
tar zxvf httpcws-1.0.0-x86_64-bin.tar.gz
rm -f httpcws-1.0.0-x86_64-bin.tar.gz
cd httpcws-1.0.0-x86_64-bin/
ulimit -SHn 65535
/usr/local/httpcws-1.0.0-x86_64-bin/httpcws -d -x /usr/local/httpcws-1.0.0-x86_64-bin/dict/
命令行启动参数：
4、httpcws 使用方法
GET方法（文本长度受URL的长度限制，需要分词的文本为GBK编码，最好采用urlencode对文本进行编码）：
http://192.168.8.42:1985/?w=有人的地方就有江湖
http://192.168.8.42:1985/?w=%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE
http://192.168.8.42:1985/?w=%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE
POST方法（文本长度无限制，适用于大文本分词，需要分词的文本为GBK编码，最好采用urlencode对文本进行编码）：
curl -d "有人的地方就有江湖"
http://192.168.8.42:1985
curl -d "%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE" http://192.168.8.42:1985
curl -d "%D3%D0%C8%CB%B5%C4%B5%D8%B7%BD%BE%CD%D3%D0%BD%AD%BA%FE" http://192.168.8.42:1985
PHP 调用 HTTPCWS 示例：
①、对GBK编码的字符串进行中文分词处理（HTTP POST方式）：
<?php
@header('Content-Type: text/html; charset=gb2312');
$text = "有人的地方就有江湖";
$text = urlencode($text);
$opts = array(
'http'=>array(
'method'=>"POST",
'header'=>"Content-type: application/x-www-form-urlencoded\r\n".
"Content-length:".strlen($data)."\r\n" .
"Cookie: foo=bar\r\n" .
"\r\n",
'content' => $text,
)
);
$context = stream_context_create($opts);
$result = file_get_contents("http://127.0.0.1:1985", false, $context);
echo $result;
?>
@header('Content-Type: text/html; charset=gb2312');
$text = "有人的地方就有江湖";
$text = urlencode($text);
$opts = array(
'http'=>array(
'method'=>"POST",
'header'=>"Content-type: application/x-www-form-urlencoded\r\n".
"Content-length:".strlen($data)."\r\n" .
"Cookie: foo=bar\r\n" .
"\r\n",
'content' => $text,
)
);
$context = stream_context_create($opts);
$result = file_get_contents("http://127.0.0.1:1985", false, $context);
echo $result;
?>
我的开源PHP中文分词扩展：PHPCWS 1.0.0[原创]
[
2009-2-16 23:40 | by
张宴 ]
2009-2-16 23:40 | by
张宴 ]
[文章/程序 作者：张宴 本文版本：v1.3 最后修改：2009.07.06 转载请注明原文链接：
http://blog.s135.com/phpcws_v100/]
注：最新的分词系统 HTTPCWS 已经发布，用来取代 PHPCWS。
请点击以下网址下载 HTTPCWS：
http://code.google.com/p/httpcws
原来的 PHPCWS 停止更新。
名称：PHPCWS（PHP中文分词扩展）
协议：New BSD License
作者：张宴
网址： http://code.google.com/p/phpcws/
SVN： http://code.google.com/p/phpcws/source/browse/#svn/trunk/phpcws
一、PHPCWS 简介
1、什么是 PHPCWS ？
PHPCWS 是一款开源的PHP中文分词扩展，目前仅支持Linux/Unix系统。
PHPCWS 先使用“ICTCLAS 3.0 共享版中文分词算法”的API进行初次分词处理，再使用自行编写的“逆向最大匹配算法”对分词和进行词语合并处理，并增加标点符号过滤功能，得出分词结果。
ICTCLAS（Institute of Computing Technology, Chinese Lexical Analysis System）是中国科学院计算技术研究所在多年研究工作积累的基础上，基于多层隐马模型研制出的汉语词法分析系统，主要功能包括中文分词；词性标注；命名实体识别；新词识别；同时支持用户词典。ICTCLAS经过五年精心打造，内核升级6次，目前已经升级到了ICTCLAS3.0，分词精度98.45%，各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名，在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名，是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的，而免费提供的 ICTCLAS 3.0 共享版不开源，词库是根据人民日报一个月的语料得出的，很多词语不存在。所以本人对ICTCLAS分词后的结果，再采用逆向最大匹配算法，根据自己补充的一个9万条词语的自定义词库（与ICTCLAS词库中的词语不重复），对ICTCLAS分词结果进行合并处理，输出最终分词结果。
由于 ICTCLAS 3.0 共享版只支持GBK编码，因此，如果是UTF-8编码的字符串，可以先用PHP的iconv函数转换成GBK编码，再用phpcws_split函数进行分词处理，最后转换回UTF-8编码。
2、PHPCWS 中文分词在线演示
演示网址： http://blog.s135.com/demo/phpcws/
3、PHPCWS 分词速度及用途
初次使用时，Apache 或 php-cgi(FastCGI) 进程，需要加载一次词库到内存中，需要0.0X秒。58字节的一句话——“2009年2月13日，我编写了一款PHP中文分词扩展：PHPCWS 1.0.0。”，分词速度只需0.0003秒。
PHPCWS 属于《 亿级数据的高并发通用搜索引擎架构设计》的一部分，用作“搜索查询接口”的关键字分词处理。在此架构中，Sphinx索引引擎对于CJK（中日韩）语言支持一元切分，假设【反恐行动是国产主视角射击网络游戏】这段文字，Sphinx会将其切成【反 恐 行 动 是 国 产 主 视 角 射 击 网 络 游 戏】，然后对每个字建立反向索引。如果用这句话中包含的字组成一个不存在的词语，例如【恐动】，也会被搜索到，所以搜索时，需要加引号，例如搜索【"反恐行动"】，就能完全匹配连在一起的四个字，不连续的【"恐动"】就不会被搜索到。但是，这样还有一个问题，搜索【"反恐行动游戏"】或【"国产网络游戏"】就会搜索不到。所以，我在搜索层写了个PHP中文分词扩展，搜索“反恐行动游戏”、“国产网络游戏”，会被PHPCWS中文分词函数分别切分为“反恐行动 游戏”、“国产 网络游戏”，这时候，用PHP函数给以空格分隔的词语加上引号，去搜索【"反恐行动" "游戏"】或【"国产" "网络游戏"】，就能搜索到这条记录了。由于PHPCWS位于搜索层，中文分词词库发生增、删、改，只需平滑重启一次Web服务器或php-cgi进程即可，无需重建搜索索引。
根据上述情况，对于那些采用二元交叉切分的搜索引擎，PHPCWS用在前端搜索层对用户输入的搜索关键字、短语进行分词处理，同样适合。PHPCWS开发的目的正在于此，对于短句、小文本中文分词切分，速度非常之快。
4、自定义词库
自定义词库名称为 userdict.tch，格式为 Tokyo Cabinet DBM 的 Abstract key-value 内存哈希数据库（key为GBK编码的词语名词，value为词频。目前词频均填1，暂时用不上）。自定义词库的修改在安装步骤中会详细介绍。
二、phpcws 1.0.1 安装步骤
注：最新的分词系统 HTTPCWS 已经发布，用来取代 PHPCWS。
请点击以下网址下载 HTTPCWS：
http://code.google.com/p/httpcws
原来的 PHPCWS 停止更新。
名称：PHPCWS（PHP中文分词扩展）
协议：New BSD License
作者：张宴
网址： http://code.google.com/p/phpcws/
SVN： http://code.google.com/p/phpcws/source/browse/#svn/trunk/phpcws
一、PHPCWS 简介
1、什么是 PHPCWS ？
PHPCWS 是一款开源的PHP中文分词扩展，目前仅支持Linux/Unix系统。
PHPCWS 先使用“ICTCLAS 3.0 共享版中文分词算法”的API进行初次分词处理，再使用自行编写的“逆向最大匹配算法”对分词和进行词语合并处理，并增加标点符号过滤功能，得出分词结果。
ICTCLAS（Institute of Computing Technology, Chinese Lexical Analysis System）是中国科学院计算技术研究所在多年研究工作积累的基础上，基于多层隐马模型研制出的汉语词法分析系统，主要功能包括中文分词；词性标注；命名实体识别；新词识别；同时支持用户词典。ICTCLAS经过五年精心打造，内核升级6次，目前已经升级到了ICTCLAS3.0，分词精度98.45%，各种词典数据压缩后不到3M。ICTCLAS在国内973专家组组织的评测中活动获得了第一名，在第一届国际中文处理研究机构SigHan组织的评测中都获得了多项第一名，是当前世界上最好的汉语词法分析器。
ICTCLAS 3.0 商业版是收费的，而免费提供的 ICTCLAS 3.0 共享版不开源，词库是根据人民日报一个月的语料得出的，很多词语不存在。所以本人对ICTCLAS分词后的结果，再采用逆向最大匹配算法，根据自己补充的一个9万条词语的自定义词库（与ICTCLAS词库中的词语不重复），对ICTCLAS分词结果进行合并处理，输出最终分词结果。
由于 ICTCLAS 3.0 共享版只支持GBK编码，因此，如果是UTF-8编码的字符串，可以先用PHP的iconv函数转换成GBK编码，再用phpcws_split函数进行分词处理，最后转换回UTF-8编码。
2、PHPCWS 中文分词在线演示
演示网址： http://blog.s135.com/demo/phpcws/
3、PHPCWS 分词速度及用途
初次使用时，Apache 或 php-cgi(FastCGI) 进程，需要加载一次词库到内存中，需要0.0X秒。58字节的一句话——“2009年2月13日，我编写了一款PHP中文分词扩展：PHPCWS 1.0.0。”，分词速度只需0.0003秒。
PHPCWS 属于《 亿级数据的高并发通用搜索引擎架构设计》的一部分，用作“搜索查询接口”的关键字分词处理。在此架构中，Sphinx索引引擎对于CJK（中日韩）语言支持一元切分，假设【反恐行动是国产主视角射击网络游戏】这段文字，Sphinx会将其切成【反 恐 行 动 是 国 产 主 视 角 射 击 网 络 游 戏】，然后对每个字建立反向索引。如果用这句话中包含的字组成一个不存在的词语，例如【恐动】，也会被搜索到，所以搜索时，需要加引号，例如搜索【"反恐行动"】，就能完全匹配连在一起的四个字，不连续的【"恐动"】就不会被搜索到。但是，这样还有一个问题，搜索【"反恐行动游戏"】或【"国产网络游戏"】就会搜索不到。所以，我在搜索层写了个PHP中文分词扩展，搜索“反恐行动游戏”、“国产网络游戏”，会被PHPCWS中文分词函数分别切分为“反恐行动 游戏”、“国产 网络游戏”，这时候，用PHP函数给以空格分隔的词语加上引号，去搜索【"反恐行动" "游戏"】或【"国产" "网络游戏"】，就能搜索到这条记录了。由于PHPCWS位于搜索层，中文分词词库发生增、删、改，只需平滑重启一次Web服务器或php-cgi进程即可，无需重建搜索索引。
根据上述情况，对于那些采用二元交叉切分的搜索引擎，PHPCWS用在前端搜索层对用户输入的搜索关键字、短语进行分词处理，同样适合。PHPCWS开发的目的正在于此，对于短句、小文本中文分词切分，速度非常之快。
4、自定义词库
自定义词库名称为 userdict.tch，格式为 Tokyo Cabinet DBM 的 Abstract key-value 内存哈希数据库（key为GBK编码的词语名词，value为词频。目前词频均填1，暂时用不上）。自定义词库的修改在安装步骤中会详细介绍。
二、phpcws 1.0.1 安装步骤
亿级数据的高并发通用搜索引擎架构设计[原创]
[
2008-12-9 08:47 | by
张宴 ]
2008-12-9 08:47 | by
张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.12.09 转载请注明原文链接：
http://blog.s135.com/post/385/]
曾经在七月，写过一篇文章──《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
曾经在七月，写过一篇文章──《 基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计[原创]
[
2008-7-27 22:29 | by
张宴 ]
2008-7-27 22:29 | by
张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.07.27 转载请注明原文链接：
http://blog.s135.com/post/360/]
前言：本文阐述的是一款经过生产环境检验的千万级数据全文检索（搜索引擎）架构。本文只列出前几章的内容节选，不提供全文内容。
在DELL PowerEdge 6850服务器（四颗64 位Inter Xeon MP 7110N处理器 / 8GB内存）、RedHat AS4 Linux操作系统、MySQL 5.1.26、MyISAM存储引擎、key_buffer=1024M环境下实测，单表1000万条记录的数据量（这张MySQL表拥有int、datetime、varchar、text等类型的10多个字段，只有主键，无其它索引），用主键（PRIMARY KEY）作为WHERE条件进行SQL查询，速度非常之快，只耗费0.01秒。
出自俄罗斯的开源全文搜索引擎软件 Sphinx，单一索引最大可包含1亿条记录，在1千万条记录情况下的查询速度为0.x秒（毫秒级）。Sphinx创建索引的速度为：创建100万条记录的索引只需3～4分钟，创建1000万条记录的索引可以在50分钟内完成，而只包含最新10万条记录的增量索引，重建一次只需几十秒。
基于以上几点，我设计出了这套搜索引擎架构。在生产环境运行了一周，效果非常不错。有时间我会专为配合Sphinx搜索引擎，开发一个逻辑简单、速度快、占用内存低、非表锁的MySQL存储引擎插件，用来代替MyISAM引擎，以解决MyISAM存储引擎在频繁更新操作时的锁表延迟问题。另外，分布式搜索技术上已无任何问题。
一、搜索引擎架构设计：
1、搜索引擎架构图：
2、搜索引擎架构设计思路：
(1)、调用方式最简化：
尽量方便前端Web工程师，只需要一条简单的SQL语句“SELECT ... FROM myisam_table JOIN sphinx_table ON (sphinx_table.sphinx_id=myisam_table.id) WHERE query='...';”即可实现高效搜索。
(2)、创建索引、查询速度快：
①、Sphinx Search 是由俄罗斯人Andrew Aksyonoff 开发的高性能全文搜索软件包，在GPL与商业协议双许可协议下发行。
Sphinx的特征：
•Sphinx支持高速建立索引（可达10MB/秒，而Lucene建立索引的速度是1.8MB/秒）
•高性能搜索（在2-4 GB的文本上搜索，平均0.1秒内获得结果）
•高扩展性（实测最高可对100GB的文本建立索引，单一索引可包含1亿条记录）
•支持分布式检索
•支持基于短语和基于统计的复合结果排序机制
•支持任意数量的文件字段（数值属性或全文检索属性）
•支持不同的搜索模式（“完全匹配”，“短语匹配”和“任一匹配”）
•支持作为Mysql的存储引擎
②、通过国外《High Performance MySQL》专家组的测试可以看出，根据主键进行查询的类似“SELECT ... FROM ... WHERE id = ...”的SQL语句（其中id为PRIMARY KEY），每秒钟能够处理10000次以上的查询，而普通的SELECT查询每秒只能处理几十次到几百次：
③、Sphinx不负责文本字段的存储。假设将数据库的id、date、title、body字段，用sphinx建立搜索索引。根据关键字、时间、类别、范围等信息查询一下sphinx，sphinx只会将查询结果的ID号等非文本信息告诉我们。要显示title、body等信息，还需要根据此ID号去查询MySQL数据库，或者从Memcachedb等其他的存储中取得。安装SphinxSE作为MySQL的存储引擎，将MySQL与Sphinx结合起来，是一种便捷的方法。
创建一张Sphinx类型表，将MyISAM表的主键ID和Sphinx表的ID作一个JOIN联合查询。这样，对于MyISAM表来所，只相当于一个WHERE id=...的主键查询，WHERE后的条件都交给Sphinx去处理，可以充分发挥两者的优势，实现高速搜索查询。
(3)、按服务类型进行分离：
为了保证数据的一致性，我在配置Sphinx读取索引源的MySQL数据库时，进行了锁表。Sphinx读取索引源的过程会耗费一定时间，由于MyISAM存储引擎的读锁和写锁是互斥的，为了避免写操作被长时间阻塞，导致数据库同步落后跟不上，我将提供“搜索查询服务”的和提供“索引源服务”的MySQL数据库进行了分开。监听3306端口的MySQL提供“搜索查询服务”，监听3406端口的MySQL提供“索引源服务”。
(4)、“主索引＋增量索引”更新方式：
一般网站的特征：信息发布较为频繁；刚发布完的信息被编辑、修改的可能性大；两天以前的老帖变动性较小。
基于这个特征，我设计了Sphinx主索引和增量索引。对于前天17:00之前的记录建立主索引，每天凌晨自动重建一次主索引；对于前天17:00之后到当前最新的记录，间隔3分钟自动重建一次增量索引。
(5)、“Ext3文件系统＋tmpfs内存文件系统”相结合：
为了避免每3分钟重建增量索引导致磁盘IO较重，从而引起系统负载上升，我将主索引文件创建在磁盘，增量索引文件创建在tmpfs内存文件系统“/dev/shm/”内。“/dev/shm/”内的文件全部驻留在内存中，读写速度非常快。但是，重启服务器会导致“/dev/shm/”内的文件丢失，针对这个问题，我会在服务器开机时自动创建“/dev/shm/”内目录结构和Sphinx增量索引。
(6)、中文分词词库：
我根据“自整理的中文分词库”＋“搜狗拼音输入法细胞词库”＋“LibMMSeg高频字库”＋... 综合整理成一份中文分词词库，出于某些考虑暂不提供。你可以使用LibMMSeg自带的中文分词词库。
前言：本文阐述的是一款经过生产环境检验的千万级数据全文检索（搜索引擎）架构。本文只列出前几章的内容节选，不提供全文内容。
在DELL PowerEdge 6850服务器（四颗64 位Inter Xeon MP 7110N处理器 / 8GB内存）、RedHat AS4 Linux操作系统、MySQL 5.1.26、MyISAM存储引擎、key_buffer=1024M环境下实测，单表1000万条记录的数据量（这张MySQL表拥有int、datetime、varchar、text等类型的10多个字段，只有主键，无其它索引），用主键（PRIMARY KEY）作为WHERE条件进行SQL查询，速度非常之快，只耗费0.01秒。
出自俄罗斯的开源全文搜索引擎软件 Sphinx，单一索引最大可包含1亿条记录，在1千万条记录情况下的查询速度为0.x秒（毫秒级）。Sphinx创建索引的速度为：创建100万条记录的索引只需3～4分钟，创建1000万条记录的索引可以在50分钟内完成，而只包含最新10万条记录的增量索引，重建一次只需几十秒。
基于以上几点，我设计出了这套搜索引擎架构。在生产环境运行了一周，效果非常不错。有时间我会专为配合Sphinx搜索引擎，开发一个逻辑简单、速度快、占用内存低、非表锁的MySQL存储引擎插件，用来代替MyISAM引擎，以解决MyISAM存储引擎在频繁更新操作时的锁表延迟问题。另外，分布式搜索技术上已无任何问题。
一、搜索引擎架构设计：
1、搜索引擎架构图：
2、搜索引擎架构设计思路：
(1)、调用方式最简化：
尽量方便前端Web工程师，只需要一条简单的SQL语句“SELECT ... FROM myisam_table JOIN sphinx_table ON (sphinx_table.sphinx_id=myisam_table.id) WHERE query='...';”即可实现高效搜索。
(2)、创建索引、查询速度快：
①、Sphinx Search 是由俄罗斯人Andrew Aksyonoff 开发的高性能全文搜索软件包，在GPL与商业协议双许可协议下发行。
Sphinx的特征：
•Sphinx支持高速建立索引（可达10MB/秒，而Lucene建立索引的速度是1.8MB/秒）
•高性能搜索（在2-4 GB的文本上搜索，平均0.1秒内获得结果）
•高扩展性（实测最高可对100GB的文本建立索引，单一索引可包含1亿条记录）
•支持分布式检索
•支持基于短语和基于统计的复合结果排序机制
•支持任意数量的文件字段（数值属性或全文检索属性）
•支持不同的搜索模式（“完全匹配”，“短语匹配”和“任一匹配”）
•支持作为Mysql的存储引擎
②、通过国外《High Performance MySQL》专家组的测试可以看出，根据主键进行查询的类似“SELECT ... FROM ... WHERE id = ...”的SQL语句（其中id为PRIMARY KEY），每秒钟能够处理10000次以上的查询，而普通的SELECT查询每秒只能处理几十次到几百次：
③、Sphinx不负责文本字段的存储。假设将数据库的id、date、title、body字段，用sphinx建立搜索索引。根据关键字、时间、类别、范围等信息查询一下sphinx，sphinx只会将查询结果的ID号等非文本信息告诉我们。要显示title、body等信息，还需要根据此ID号去查询MySQL数据库，或者从Memcachedb等其他的存储中取得。安装SphinxSE作为MySQL的存储引擎，将MySQL与Sphinx结合起来，是一种便捷的方法。
创建一张Sphinx类型表，将MyISAM表的主键ID和Sphinx表的ID作一个JOIN联合查询。这样，对于MyISAM表来所，只相当于一个WHERE id=...的主键查询，WHERE后的条件都交给Sphinx去处理，可以充分发挥两者的优势，实现高速搜索查询。
(3)、按服务类型进行分离：
为了保证数据的一致性，我在配置Sphinx读取索引源的MySQL数据库时，进行了锁表。Sphinx读取索引源的过程会耗费一定时间，由于MyISAM存储引擎的读锁和写锁是互斥的，为了避免写操作被长时间阻塞，导致数据库同步落后跟不上，我将提供“搜索查询服务”的和提供“索引源服务”的MySQL数据库进行了分开。监听3306端口的MySQL提供“搜索查询服务”，监听3406端口的MySQL提供“索引源服务”。
(4)、“主索引＋增量索引”更新方式：
一般网站的特征：信息发布较为频繁；刚发布完的信息被编辑、修改的可能性大；两天以前的老帖变动性较小。
基于这个特征，我设计了Sphinx主索引和增量索引。对于前天17:00之前的记录建立主索引，每天凌晨自动重建一次主索引；对于前天17:00之后到当前最新的记录，间隔3分钟自动重建一次增量索引。
(5)、“Ext3文件系统＋tmpfs内存文件系统”相结合：
为了避免每3分钟重建增量索引导致磁盘IO较重，从而引起系统负载上升，我将主索引文件创建在磁盘，增量索引文件创建在tmpfs内存文件系统“/dev/shm/”内。“/dev/shm/”内的文件全部驻留在内存中，读写速度非常快。但是，重启服务器会导致“/dev/shm/”内的文件丢失，针对这个问题，我会在服务器开机时自动创建“/dev/shm/”内目录结构和Sphinx增量索引。
(6)、中文分词词库：
我根据“自整理的中文分词库”＋“搜狗拼音输入法细胞词库”＋“LibMMSeg高频字库”＋... 综合整理成一份中文分词词库，出于某些考虑暂不提供。你可以使用LibMMSeg自带的中文分词词库。
MySQL中文全文索引插件 mysqlcft 1.0.0 安装使用文档[原创]
[
2008-7-1 22:57 | by
张宴 ]
2008-7-1 22:57 | by
张宴 ]
[文章+程序 作者：张宴 本文版本：v1.0 最后修改：2008.07.01 转载请注明原文链接：
http://blog.s135.com/post/356/]
MySQL在高并发连接、数据库记录数较多的情况下，SELECT ... WHERE ... LIKE '%...%'的全文搜索方式不仅效率差，而且以通配符%和_开头作查询时，使用不到索引，需要全表扫描，对数据库的压力也很大。MySQL针对这一问题提供了一种全文索引解决方案，这不仅仅提高了性能和效率（因为MySQL对这些字段做了索引来优化搜索），而且实现了更高质量的搜索。但是，至今为止，MySQL对中文全文索引无法正确支持。
中文与西方文字如英文的一个重要区别在于，西方文字以单词为单位，单词与单词之间以空格分隔。而中文以字为单位，词由一个或多个字组成，词与词之间没有空格分隔。当试图在一个含有中文字符的字段中使用全文搜索时，不会得到正确的结果，原因在于中文中没有像英文空格那样对词定界，不能以空格作为分割，对中文词语进行索引。
引用《 MySQL 5.1参考手册》中的一段话：
国内已有的MySQL中文全文索引解决方案有两个：一是海量科技的 MySQL5.0.37--LinuxX86-Chinese+，二是hightman开发的 mysql-5.1.11-ft-hightman，两者都是基于中文分词技术，对中文语句进行拆分。但是，两者都有弊端，一是不支持64位操作系统；二是对修改了MySQL源码，只支持某一MySQL版本，不便于跟进新版本；三是词库不能做到很大很全，对于专业性质较强的数据库内容（例如搜索“颐和园路东口”、“清华东路西口”等公交站点，“莱镇香格里”、“碧海云天”等楼盘名称），基于中文分词的全文索引经常搜索不出来任何内容，即使添加分词词库，也不会很全面。
由于精准全文查询的需要，我借鉴了二元交叉切分算法的思想，用自创的“三字节交叉切分算法”，写出了这款“MySQL中文全文索引插件──mysqlcft 1.0.0”。由于开发时间仓促，难免存在未发现的问题，这将后续的版本中不断完善。对于百万条记录的MySQL表进行全文检索，mysqlcft已经够用。
Mysqlcft 网址：http://code.google.com/p/mysqlcft/
Mysqlcft 作者：张宴
一、MySQL中文全文索引插件mysqlcft的特点：
1、优点：
①、精准度很高：采用自创的“三字节交叉切分算法”，对中文语句进行分割，无中文分词词库，搜索精准度远比中文分词算法高，能达到LIKE '%...%"的准确率。
②、查询速度快：查询速度比LIKE '%...%"搜索快3～50倍，文章末尾有测试结果；
③、标准插件式：以MySQL 5.1全文索引的标准插件形式开发，不修改MySQL源代码，不影响MySQL的其他功能，可快速跟进MySQL新版本；
④、支持版本多：支持所有的MySQL 5.1 Release Candidate版本，即MySQL 5.1.22 RC～最新的MySQL 5.1.25 RC；
⑤、支持字符集：支持包括GBK、GB2312、UTF-8、Latin1、BIG5在内的MySQL字符集（其他字符集没有测试过）；
⑥、系统兼容好：具有i386和x86_64两个版本，支持32位（i386）和64位（x86_64）CPU及Linux系统；
⑦、适合分布式：非常适合MySQL Slave分布式系统架构，无词库维护成本，不存在词库同步问题。
2、缺点：
①、mysqlcft中文全文索引只适用于MyISAM表，因为MySQL只支持对MyISAM表建立FULLTEXT索引；
②、MySQL不能静态编译安装，否则无法安装mysqlcft插件；
③、基于“三字节交叉切分算法”的索引文件会比海量、ft-hightman等基于“中文分词算法”的索引文件稍大，但不是大很多。根据我的测试，mysqlcft全文索引的.MYI索引文件是.MYD数据文件的2～5倍。
二、mysqlcft的核心思想──“三字节交叉切分算法”
注：本文以0～7数字序号代表“英文”、“数字”和“半个汉字”，以便说明。
1、按三字节对中文语句进行切分，建立全文索引：
例如：“全文索引”或“1台x光机”四个字会被交叉分拆为6份，建立反向索引：
012 123 234 345 456 567
2、按三字节对搜索的关键字进行切分，在全文索引中找出对应信息：
例①：搜索关键字“文索”，用数字序号表示就是“2～5”，那么它将被切分成：
234 345
这样，就与全文索引对上了。
例②：搜索关键字“x光机”，用数字序号表示就是“3～7”，那么它将被切分成：
345 456 567
这样，也与全文索引对上了。
例③：搜索关键字“1台 光机”，用数字序号表示就是“0～2”和“4～7”，那么它将被切分成：
012 456 567
这样，多关键字搜索也与全文索引对上了。
MySQL在高并发连接、数据库记录数较多的情况下，SELECT ... WHERE ... LIKE '%...%'的全文搜索方式不仅效率差，而且以通配符%和_开头作查询时，使用不到索引，需要全表扫描，对数据库的压力也很大。MySQL针对这一问题提供了一种全文索引解决方案，这不仅仅提高了性能和效率（因为MySQL对这些字段做了索引来优化搜索），而且实现了更高质量的搜索。但是，至今为止，MySQL对中文全文索引无法正确支持。
中文与西方文字如英文的一个重要区别在于，西方文字以单词为单位，单词与单词之间以空格分隔。而中文以字为单位，词由一个或多个字组成，词与词之间没有空格分隔。当试图在一个含有中文字符的字段中使用全文搜索时，不会得到正确的结果，原因在于中文中没有像英文空格那样对词定界，不能以空格作为分割，对中文词语进行索引。
引用《 MySQL 5.1参考手册》中的一段话：
引用
12.7. 全文搜索功能（
http://dev.mysql.com/doc/refman/5.1/zh/functions.html）
● MySQL支持全文索引和搜索功能。MySQL中的全文索引类型FULLTEXT的索引。FULLTEXT 索引仅可用于 MyISAM 表；他们可以从CHAR、 VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或 CREATE INDEX被添加。对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引， 其速度比把资料输入现有FULLTEXT索引的速度更为快。
● FULLTEXT分析程序会通过寻找某些分隔符来确定单词的起始位置和结束位置，例如' ' (间隔符号)、 , (逗号)以及 . (句号 )。假如单词没有被分隔符分开，(例如在中文里 ), 则 FULLTEXT 分析程序不能确定一个词的起始位置和结束位置。为了能够在这样的语言中向FULLTEXT 索引添加单词或其它编入索引的术语，你必须对它们进行预处理，使其被一些诸如"之类的任意分隔符分隔开。
● 诸如汉语和日语这样的表意语言没有自定界符。因此， FULLTEXT分析程序不能确定在这些或其它的这类语言中词的起始和结束的位置。
● MySQL支持全文索引和搜索功能。MySQL中的全文索引类型FULLTEXT的索引。FULLTEXT 索引仅可用于 MyISAM 表；他们可以从CHAR、 VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或 CREATE INDEX被添加。对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引， 其速度比把资料输入现有FULLTEXT索引的速度更为快。
● FULLTEXT分析程序会通过寻找某些分隔符来确定单词的起始位置和结束位置，例如' ' (间隔符号)、 , (逗号)以及 . (句号 )。假如单词没有被分隔符分开，(例如在中文里 ), 则 FULLTEXT 分析程序不能确定一个词的起始位置和结束位置。为了能够在这样的语言中向FULLTEXT 索引添加单词或其它编入索引的术语，你必须对它们进行预处理，使其被一些诸如"之类的任意分隔符分隔开。
● 诸如汉语和日语这样的表意语言没有自定界符。因此， FULLTEXT分析程序不能确定在这些或其它的这类语言中词的起始和结束的位置。
国内已有的MySQL中文全文索引解决方案有两个：一是海量科技的 MySQL5.0.37--LinuxX86-Chinese+，二是hightman开发的 mysql-5.1.11-ft-hightman，两者都是基于中文分词技术，对中文语句进行拆分。但是，两者都有弊端，一是不支持64位操作系统；二是对修改了MySQL源码，只支持某一MySQL版本，不便于跟进新版本；三是词库不能做到很大很全，对于专业性质较强的数据库内容（例如搜索“颐和园路东口”、“清华东路西口”等公交站点，“莱镇香格里”、“碧海云天”等楼盘名称），基于中文分词的全文索引经常搜索不出来任何内容，即使添加分词词库，也不会很全面。
由于精准全文查询的需要，我借鉴了二元交叉切分算法的思想，用自创的“三字节交叉切分算法”，写出了这款“MySQL中文全文索引插件──mysqlcft 1.0.0”。由于开发时间仓促，难免存在未发现的问题，这将后续的版本中不断完善。对于百万条记录的MySQL表进行全文检索，mysqlcft已经够用。
Mysqlcft 网址：http://code.google.com/p/mysqlcft/
Mysqlcft 作者：张宴
一、MySQL中文全文索引插件mysqlcft的特点：
1、优点：
①、精准度很高：采用自创的“三字节交叉切分算法”，对中文语句进行分割，无中文分词词库，搜索精准度远比中文分词算法高，能达到LIKE '%...%"的准确率。
②、查询速度快：查询速度比LIKE '%...%"搜索快3～50倍，文章末尾有测试结果；
③、标准插件式：以MySQL 5.1全文索引的标准插件形式开发，不修改MySQL源代码，不影响MySQL的其他功能，可快速跟进MySQL新版本；
④、支持版本多：支持所有的MySQL 5.1 Release Candidate版本，即MySQL 5.1.22 RC～最新的MySQL 5.1.25 RC；
⑤、支持字符集：支持包括GBK、GB2312、UTF-8、Latin1、BIG5在内的MySQL字符集（其他字符集没有测试过）；
⑥、系统兼容好：具有i386和x86_64两个版本，支持32位（i386）和64位（x86_64）CPU及Linux系统；
⑦、适合分布式：非常适合MySQL Slave分布式系统架构，无词库维护成本，不存在词库同步问题。
2、缺点：
①、mysqlcft中文全文索引只适用于MyISAM表，因为MySQL只支持对MyISAM表建立FULLTEXT索引；
②、MySQL不能静态编译安装，否则无法安装mysqlcft插件；
③、基于“三字节交叉切分算法”的索引文件会比海量、ft-hightman等基于“中文分词算法”的索引文件稍大，但不是大很多。根据我的测试，mysqlcft全文索引的.MYI索引文件是.MYD数据文件的2～5倍。
二、mysqlcft的核心思想──“三字节交叉切分算法”
注：本文以0～7数字序号代表“英文”、“数字”和“半个汉字”，以便说明。
1、按三字节对中文语句进行切分，建立全文索引：
例如：“全文索引”或“1台x光机”四个字会被交叉分拆为6份，建立反向索引：
012 123 234 345 456 567
2、按三字节对搜索的关键字进行切分，在全文索引中找出对应信息：
例①：搜索关键字“文索”，用数字序号表示就是“2～5”，那么它将被切分成：
234 345
这样，就与全文索引对上了。
例②：搜索关键字“x光机”，用数字序号表示就是“3～7”，那么它将被切分成：
345 456 567
这样，也与全文索引对上了。
例③：搜索关键字“1台 光机”，用数字序号表示就是“0～2”和“4～7”，那么它将被切分成：
012 456 567
这样，多关键字搜索也与全文索引对上了。
扫一扫
869
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
ttserver对php内容无法反序列化，不支持压缩，这两点也很讨厌。
要是没有这几个问题就好了。
一个人将记录写到了缓存,数据库中并更新索引,
另一个人通过索引从缓存或数据库中读出记录.
搜索引擎Cache命中率一般在60%略高的样子，索引所用的内存都是几百G几百G的
你这个只对增量增加敏感，好像删除的话不能更新索引吧？
不过不得不赞一下你这个也相当棒:)
所以，相对而言，我的这套索引单台机器支撑1亿索引，达到Google/Baidu/Sogou的查询速度，算不错了。
至于和Lucene的比较，Sphinx拥有下列与Lucene所对应的权重计算模式，那个PDF文档已经在各种类型下与Lucene进行比较：
SPH_RANK_PROXIMITY_BM25, default ranking mode which uses and combines both phrase proximity and BM25 ranking.
SPH_RANK_BM25, statistical ranking mode which uses BM25 ranking only (similar to most other full-text engines). This mode is faster but may result in worse quality on queries which contain more than 1 keyword.
SPH_RANK_NONE, disabled ranking mode. This mode is the fastest. It is essentially equivalent to boolean searching. A weight of 1 is assigned to all matches.
SPH_RANK_WORDCOUNT, ranking by keyword occurrences count. This ranker computes the amount of per-field keyword occurrences, then multiplies the amounts by field weights, then sums the resulting values for the final result.
SPH_RANK_PROXIMITY, added in version 0.9.9, returns raw phrase proximity value as a result. This mode is internally used to emulate SPH_MATCH_ALL queries.
SPH_RANK_MATCHANY, added in version 0.9.9, returns rank as it was computed in SPH_MATCH_ANY mode ealier, and is internally used to emulate SPH_MATCH_ANY queries.
增量索引能够实现索引的增加、更新。索引的删除更简单，Sphinx支持属性标记，假如正常状态is_delete属性为0，那么删除就将is_delete属性标记为1，属性标记是在内存中进行的，在Sphinx停止时自动写入磁盘，非常快，因而删除索引可以说是实时的。在合并索引时，通过--merge-dst-range参数，即可排除掉被标记为删除的索引。
我发现凡带 [ ] 号的会对检索结构有严重干扰.