Coreseek:区段查询及增量索引取代实时索引
1.区段查询
索引系统须要通过主查询来获取所有的文档信息,一种简单的实现是将整个表的数据读入内存,可是这可能导致整个表被锁定并使得其它操作被阻止(比如:在MyISAM格式上的INSERT操作),同一时候,将浪费大量内存用于存储查询结果,诸如此类的问题吧。 为了避免出现这样的情况,CoreSeek/Sphinx支持一种被称为 区段查询的技术. 首先。CoreSeek/Sphinx从数据库中取出文档ID的最小值和最大值。将由最大值和最小值定义自然数区间分成若干份。一次获取数据,建立索引。现举比例如以下:
sql_query_range = SELECT MIN(id),MAX(id) FROM documents sql_range_step = 1000 sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end仅仅要在配置文件中面写三条语句就可以
from后面要跟的是你数据库里面的表名,如这里的表就是document
2.增量索引取代实时索引
有这么一种常见的情况:整个数据集很大,以至于难于常常性的重建索引,可是每次新增的记录却相当地少。一个典型的样例是:一个论坛有1000000个已经归档的帖子,但每天仅仅有1000个新帖子。
在这样的情况下能够用所谓的“主索引+增量索引”(main+delta)模式来实现“近实时”的索引更新。
这样的方法的基本思路是设置两个数据源和两个索引,对非常少更新或根本不更新的数据建立主索引,而对新增文档建立增量索引。在上述样例中。那1000000个已经归档的帖子放在主索引中。而每天新增的1000个帖子则放在增量索引中。增量索引更新的频率能够非常快。而文档能够在出现几分种内就能够被检索到。
确定详细某一文档的分属那个索引的分类工作能够自己主动完毕。一个可选的方案是,建立一个计数表,记录将文档集分成两部分的那个文档ID。而每次又一次构建主索引时。这个表都会被更新。
分辨要在mysql里建表,然后改动配置文件
# in MySQL CREATE TABLE sph_counter ( counter_id INTEGER PRIMARY KEY NOT NULL, max_doc_id INTEGER NOT NULL ); # in sphinx.conf source main { # ... sql_query_pre = SET NAMES utf8 sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(id) FROM documents sql_query = SELECT id, title, body FROM documents \ WHERE id<span style="color:#ff0000;"><=</span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) } source delta : main { sql_query_pre = SET NAMES utf8 sql_query = SELECT id, title, body FROM documents \ WHERE id<span style="color:#ff0000;">></span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) } index main { source = main path = /path/to/main # ... all the other settings } # note how all other settings are copied from main, # but source and path are overridden (they MUST be) index delta : main { source = delta path = /path/to/delta }
写好之后,还要写两个批处理文件。一个做增量索引。一个合并索引。
增量索引:g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --rotate main_delta
合并索引:g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --merge main main_delta --rotate
写好之后,再将两者放入到任务计划里,差点儿相同5分钟做一次增量索引。每天1点半时候做一次主索引