基于Lucene的商业搜索应用架构研究(上)——架构设计

    本文旨在探索基于Lucene的搜索架构问题，也就是怎么应用Lucene来构造一个应用于业务系统的搜索引擎框架的问题。

    一直对做搜索有不少幻想，也曾尝试着自己小打小闹的搞过几个demo，前不久，这个机会来了，目前我们开发的系统业务数据在跨越千万级的门槛上了，主管和项目经理打起了搜索引擎的主意，我也主动请缨要来搞一下。

   

    做过搜索的人都知道。对于使用Lucene做个简单的demo 很简单，只要把Lucene 包下载下来，网上看点资料应该很快就有效果的，但是应用于商业系统有很多的问题需要考虑：什么样的架构足够灵活，删除的数据怎么在索引中删除，同一时间有很大数据时会不会导致内存溢出，事务区的数据怎么办，索引数据是否要用缓存，业务框架和搜索服务的耦合度要多大，加字段是不是要重新建索引，在原有的搜索服务上提供新的搜索服务是不是足够方便等等。

 

一.概要设计阶段：

 

    开始我们思路也不是很开阔，虽然有两个搜索框架可以参考，但是过早的陷入了细节，幸亏项目经理还是比较会梳理问题，虽然他也不是太懂搜索，但他提供了解决问题的思路，让我们从几个大的方面进行思考，我们在对原有两个框架研究的基础上展开思路，主要思考成果如下：

 

   

DMP搜索引擎模块概略设计

 

 

	架构A	架构B	实现思路	问题
索引任务启动和关闭	当有两个以上索引任务时,可以停掉一个索引的任务,一个索引任务改造时,不影另外的任务	依附于服务器，Jboss启动时，任务启动，关闭时所有的任务都关闭。	Spring配置Schedule。把两个任务都加进去，依赖于jboss服务器
配置方式	配置非常灵活，但是加一套索引的时候，要加建索引，Dao与Document转化，shell脚本重新搞一遍。	Index. Properties可以非常灵活的配置某个字段的分词器等，可以满足个性化的查询需求。	1.很容易的扩展任务。 2.容易扩展业务 3.支持索引列的配置  4. 基于xml，不使用Spring bean的配置。【详细1】
数据扫描		删除任务时向任务表插入记录，不考虑大数据量变更时，修改时间一致导致的内存溢出等问题。	1.限制时间来取数据，采用步长的增量式取数据 2.注意补偿时间 3.任务可以配置在某台服务器上跑	1.大数据量，较多数据同一修改时间的解决 2.第一次跑数据时时间非常长。
索引建立和优化	使用indexWriter对象的三级缓存cache，采用线程池的方式。	使用RAM的内存目录，最后刷新到硬盘。有很多indexWriter使用cache	1.需要使用cache，不使用cache每次从硬盘读数据非常耗费性能 2.采用线程池方式写索引。3.不用RAM	CacheIndexWriter在使用时，四个参数是否需要优化，怎么优化。
业务集成（搜索客户端和服务端的调用关系）			将查询条件，放到Map里面，传输的实体都是java内建对象，任何业务端查询都不需要修改条件实体，业务端进行Map到DO的转化，搜索引擎端没有POJO
查询组件			1.查询端封装condition的like equal等条件2.业务搜索端提供搜索的service封装对于hessian的应用和条件的构造。3.搜索引擎采用根据条件进行组合和查询。
分词	只能配置一个分词方式	可以自定义分词方式，每个字段各不相同。	参考架构B实现，可以灵活配置的分词方式。	对于like的实现，目前考虑采用WizardFiter进行二次过滤，实现通配符搜索，寻找下分字母的解决方案。由于这种中文夹英文的情况较少，不考虑分词带来的效率。
缓存			1.Hit内部的缓存最大值支持每次取200条数据到缓存，多余了则清空 ，可以调整这个值。2.其它地方不使用缓存。
Hessian接口提供	提供基于内置jetty web服务器的hessian服务	用http-invoker发布的服务，序列化机制基于Spring，只能支持基于Spring的客户端平台	绑定JBOSS提供接口，Spring内配置。

 

 

 备注：

 

【详细1】：xml格式配置，

 

1.       字段索引建立类型。

2.       扫描的频率

3.       取数据sql

4.       索引目录

5.       跑不跑任务，跑哪种类型。

 

 

 

二.搜索模块架构设计

 

     搜索模块主要基于如下考虑：索引和搜索的服务器都是单端的，采用hessian发布的服务可以提供给任何外部系统使用， 还有上面提到的，采用java内建对象，map，set等作为传输实体的参数，可以降低耦合，也不存在序列化跟平台有关的问题,主要架构如下：

 

    主要设计还是看附件，刚才csdn转战到javaeye

 

 

 

 

 

 

------------------文章太长-------------------未完待续------------------------------------