全文索引Lucene学习小结之项目设计

以媒资4.5或央广媒资为原型，实现搜索功能，具体软件功能说明如下：

1.索引文本增量更新

【需求描述】：检索引擎索引的数据来源于业务系统，业务系统需要检索的数据会经常发生变化，当业务数据发生变化的时候需要检索引擎在最短的时间内对变化进行处理。最为常见的情况是当业务数据增加一天数据的时候，检索引擎需要在尽可能短的时间内将给数据加入到检索引擎中。

索引增量更新的时间间隔要求可以进行配置。

 

在源数据（acm_program）有变化时，在添加、修改和删除节目数据的时会对全文信息表(fulltext)通过数据库的三个触发器向index_task_log表中添加相应的索引任务记录（ id，节目Id  obj_id，任务类型 task_type）其中Id采用Oracle序列，初始为0，每次加1

 

定时器每隔一段时间（该时间间隔是从config.properties文件中读取的）从index_task_log表中取得指定范围的记录（从系统配置表获取上次任务到的logId以及每批次要执行的任务数量Task_Size），将其插入到任务待办表index_task_todo中（与index_task_log表的表结构一致）。

然后遍历待办表中的记录，根据任务类型和节目id进行相应的操作：add：那就把全文信息表中的那条记录转换成Document，添加到索引文件中；update:那就把索引文件中对应的文档删掉，然后再用新的文档添加到索引文件中；delete:那就把索引文件中对应的文档删掉；任务全部执行完毕后，调用writer.commit(),并将任务的执行情况（取任务时的Id范围，实际插入到task_to表中的任务数目，批量提交任务的时间）记录到任务完成表index_task_done中。同时清空index_task_todo表，并更新sysconfig表中last_logid值（正常来说，maxLogId很大，够todo来取任务,此时更新lastLogId为lastLogId+TaskSize即可；如果任务没有可以往下执行了，那就会出现lastLogId  = maxLogId，此时则不用对lastLogId进行更新；如果index_task_log表中未执行过的任务记录小于TaskSize，那么在定时器执行时程序会动态地将TaskSize调小为maxLogId - lastLogId）

 

在该功能上，定时器执行任务的时间间隔和一次要执行的索引增量更新任务的数目是可以由管理员进行设置的，分别改变的是config.properties中的TASK_TIME_INTERVAL和sysconfig表中的TASK_SIZE。

 

这个如果要优化，可以通过区分fullText的类型来使索引重建时不生成task_log信息，这样可以避免taskLog表在索引进行重建时生成大量无用的记录。

 

2.索引文本全量更新

【需求描述】：由于检索引擎每天要对针对业务系统进行多次的增量更新，检索引擎的索引文件格式会慢慢变的低效和更加庞大，需要通过全量更新索引的方式来解决这个问题。

索引全量更新的时间点要求可以进行配置。

 索引的全量更新（也称为索引的重构）也是通过定时器定时执行的。时间间隔是24个小时，每天执行的时间点（时、分、秒）是通过config.properties进行配置的。

每次的全量更新要执行的动作是，删除掉先前的索引文件，也删除全文信息表中的所有记录，遍历所有的节目记录，为每一条节目生成全文信息到fullText表中，并添加到索引，在添加完成后并将索引的更新情况记录在index_task_done表中。由于在全量更新索引时，触发器会向index-_task_log表中插入大量add类型的任务记录，而这些任务是不需要被增量更新的定时任务执行的，所以最后需要在将lastLogId更新为当前最大的logId.

 

3.检索输入自动提示

【需求描述】：根据互联网商用搜索引擎的特点，都会为用户提供输入提示的功能，本功能即是为用户提供输入自动提示功能，为用户的检索提供更加良好的体验。

当前用户已经输入的词语，在提示的时候优先展示。

 

使用网上的jqueryUI插件autocomplete.js，原理大致是用户在搜索框中每次键入关键词的字符时，调用Ajax方法从后台获取匹配的数据项列表，添加到输入框下边的div中。于是，自己的任务核心变成了“如何根据用户已经输入的信息呈现出最合理的补全项”。合理的提示应该都是用户输入的搜索词中挖掘出来的，并且需要优先匹配当前用户的搜索历史记录，然后匹配公共的热门搜索词汇。

 

所以，可以设计两张表，一张存储公共的热词，一张来存储用户的搜索历史记录。

用户的搜索历史记录表存放着用户的每一次搜索情况，搜索词、搜索时间、用户Id、匹配的记录数；而公共的热词表，则主要存储搜索词、搜索次数、最近一次的搜索时间，对同一个词语多人次的搜索，会增加该词的搜索次数。

 

可以进行的优化是：在用户登录时，把这两张表中的信息全部转移到内存中，采用一定的策略同步内存中的数据和数据库表中的数据，这样能保证提示的及时性。

 

4.搜索日志记录

【需求描述】：用户的任何一次提交给检索引擎的请求内容需要完整记录下来，方便对用户的检索行文进行挖掘和分析。

搜索日志需要单独记录一类日志，需要记录用户请求查询的时间，查询的词语，查询结果的记录条数，当前请求返回的结果条数。

 

 在每一次用户点击搜索时，后台都要记录这次的搜索情况。完整地记录在一张表，即用户搜索历史记录表。

在管理员页面，支持对用户检索历史的查询功能。

 

可以进行优化的地方是：可以采用log4j对日志进行记录，形成文件。 

5.拼音全拼检索

【需求描述】： 检索引擎支持用户输入汉字全拼，希望完成对对应中文汉字的检索功能。

在检索的结果中，需要包含对应中文词语的检索信息也需要包含拼音检索的信息。

 

使用了pinyin4j的jar包，将长文本分词后，使用Tokenier 、TokenFilter、TokenFilter三个类构造一个自定义的带拼音的同义词分词器，使得长文本中的词语在建立索引前能追加上它的同义词（如果有同义词的话）以及该词语的拼音。这样同义词和拼音就会存储到索引文件中。

 

 全拼已经实现，另外可以考虑拼音的简写，以及拼音的拼写检查

6.同义词检索

【需求描述】： 用户检索某一个词语的时候，在检索结果中需要包括该词语对应的同义词结果。例如：用户检索“儿童”，结果中可以包括“少儿”。

检索词的结果需要排在其同义词结果的前面。

 

同上：在向索引文件添加索引时，先将索引文档中的索引域进行分词，会将每个分词的拼音以及其同义词和同义词的拼音追加在词语后边，使得检索时能通过拼音和同义词以及同义词的拼音检索到目标记录。

 

可以优化的地方是：将检索词排在了同义词的前面，这个实现是通过自定义评分实现的。

 

7.支持集群部署

【需求描述】： 检索引擎在大并发情况下，需要方便进行横向扩展，同时考虑到提升系统的可靠性，都要求系统支持集群部署。

 

8.词库在线更新

【需求描述】： 检索引擎需要支持对词库的在线更新，词库包括用户词库、同义词词库等，考虑到词库更新对检索引擎的影响，允许词库更新的最大延迟时间为24小时。

词库更新的时间要求可以进行配置。

 

暂时支持对用户对词典的在线续写。词库的在线定时更新暂未实现。

 

9.相关搜索

【需求描述】： 根据用户输入的搜索关键词，为用户推荐一批相关的搜索关键词。

 思路：从公共热词表中对数据进行挖掘，如果两个热门搜索词匹配的文档是相同的几个文档，，那么可以认为这两个词是相关词。如，在分别搜索“致青春”和“赵薇”时，如果选中的文档，有相当数量的重叠，那么就可以将这两个词作为相关词，在用户搜索其中一个词语时，自动为用户提示另一个词语。