mysql+全文检索设计,基于sphinx+mysql全文检索架构设计.doc

基于sphinx+mysql全文检索架构设计.doc

还剩

2页未读，

继续阅读

下载文档到电脑，马上远离加班熬夜！

亲，喜欢就下载吧，价低环保！

内容要点：

创建一张 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 自带的中文分词词库。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 不负责文本字段的存储

发表评论

暂无评论，赶快抢占沙发吧。