我的第一篇博文

发表于

##对目前几个主流的开源搜索框架进行调研分析

###Apache Solr

  • 先进的全文检索功能：Solr提供了强大的匹配能力，包括词组、通配符、连接、分组等等。
  • 为高流量进行了性能优化：在世界各地的应用中已被证明。
  • 基于标准的开放接口：XML、JSON和HTTP等。
  • 综合管理界面：Solr内置了一个用户管理界面，使你的Solr实例更易于管理和控制。
  • 轻松的监控：Solr通过JMX导出统计信息用于监控。
  • 高度可扩展性及容错性：由于建立在久经考验的Apache Zookeeper上，Solr很容易扩展和裁剪。
  • 灵活性、适应性、配置简单：适应各种需求的同时简化配置。
  • 准实时索引：Solr利用了Lucene的准实时索引功能。
  • 可扩展的插件架构：Solr发布了很多定义良好的扩展点，使其很容易的插入索引和时间查询等插件。

Lucene 和 solr 比较

Lucene是一套信息检索工具包，但并不包含搜索引擎系统，它包含了索引结构、读写索引工具、相关性工具、排序等功能，因此在使用Lucene时你仍需要关注搜索引擎系统，例如数据获取、解析、分词等方面的东西。而Solr的目标是打造一款企业级的搜索引擎系统，因此它更接近于我们认识到的搜索引擎系统，它是一个搜索引擎服务，通过各种API可以让你的应用使用搜索服务，而不需要将搜索逻辑耦合在应用中。而且Solr可以根据配置文件定义数据解析的方式，更像是一个搜索框架，它也支持主从、热换库等操作。还添加了飘红、facet等搜索引擎常见功能的支持。因而，Lucene使用上更加灵活，但是你需要自己处理搜素引擎系统架构，以及其他附加附加功能的实现。而Solr帮你做了更多，但是是一个处于高层的框架，Lucene很多新特性不能及时向上透传，所以有时候可能发现需要一个功能，Lucene是支持的，但是Solr上已经看不到相关接口。

Lucene更像是一个SDK。 有完整的API族以及对应的实现。你可以利用这些在自己的应用里实现高级查询（基于倒排索引技术的），Lucene对单机或者桌面应用很实用很方便。但是Lucene，需要开发者自己维护索引文件，在多机环境中备份同步索引文件很是麻烦。于是，就有了Solr。 而Solr是一个有HTTP接口的基于Lucene的查询服务器，封装了很多Lucene细节，自己的应用可以直接利用诸如 …/solr?q=abc 这样的HTTP GET/POST请求去查询，维护修改索引。

与Lucene 4.10配合的中文分词比较

  • mmseg4j：支持Lucene 4.10，且在github中最新提交代码是2014年6月，从09年～14年一共有：18个版本，也就是一年几乎有3个大小版本，有较大的活跃度，用了mmseg算法。

  • IK-analyzer： 支持Lucene 4.10从2006年12月推出1.0版开始， IKAnalyzer已经推出了4个大版本。最初，它是以开源项目Luence为应用主体的，结合词典分词和文法分析算法的中文分词组件。从3.0版本开 始，IK发展为面向Java的公用分词组件，独立于Lucene项目，同时提供了对Lucene的默认优化实现。在2012版本中，IK实现了简单的分词 歧义排除算法，标志着IK分词器从单纯的词典分词向模拟语义分词衍化。 但是也就是2012年12月后没有在更新。

  • Jcseg：最新版本在git.oschina.net/lionsoul/jcseg，支持Lucene 4.10，作者有较高的活跃度。利用mmseg算法。

测试结果

从几个指标对比来看：IK-analyzer的准确度稍差，Jcseg的时间消耗稍差

时间消耗上：在索引创建1,003,057 items, totalling 2.8 GB的文件:

将其索引放入磁盘

Jcseg + Lucene建索引消耗： 516971 total milliseconds

mmseg4j + Lucene建索引消耗： 256805 total milliseconds

IK-Analyzer + Lucene建索引消耗： 445591 total milliseconds

将索引放在内存中

Jcseg + Lucene 建索引消耗： 510146 total milliseconds

mmseg4j + Lucene建索引消耗： 262682 total milliseconds

IK-Analyzer + Lucene建索引消耗： 436900 total milliseconds

综上所有因素：

准确率为：Jcseg > mmseg4j > IK-Analyzer。

内存消耗和CPU使用率上，几个都在一个数量级上，很难分出胜负。

但是在时间消耗上明显mmseg4j的优势非常突出。

从活跃度来看，mmseg4j的活跃度也是非常可喜的。

参考：http://www.hansight.com/blog-lucene4.10-with-chinese-segment.html

sphinx vs solr

  • 中文分词的支持比较

sphinx目前只支持mmseg3,sphinx for chinese两种分词，目前大家使用的比较多的是mmseg3。mmseg3的词库需要预先编译，不利于词库的扩充。

Solr目前支持的词库比较多，目前支持的有庖丁，IK，mmsegj4,通过比较分词效果，IK在分词的查全和查准的效果上更好一些。IK分词支持设置停用词和扩展词库，扩展词库每个词一行的方式进行扩展。

  • 从Mysql数据库索引数据的支持

sphinx可以通过配置数据源的方式直接从mysql中索引数据，在数据量比较大的时候，可以设置主索引+增量索引的方式来同步数据。但是主索引需要是根据Ｍysql表的主键Ｉd来设置索引范围，比如Ｉd小于9000,000，Ｉd大于9000,000的通过增量索引来同步。这种只适应Ｉd小于9000,000的数据更新频繁的情况。
如果主索引和增量索引是以记录的最后更新时间来区分的话，由于主索引和增量索引使用的是2个不同的索引文件，这就会造成主索引和增量索引中的数据不一致，导致检索时出现本不该出现的记录。这种情况就需要把增量索引合并到主索引中，如果主索引的数据比较大，不确定合并的时间需要多少。
solr索引mysql数据时，可以配置成主索引+增量索引，主索引和增量索引之间以更新的时间戳为分割线，solr会记录每次更新的时间戳。由于solr的增量索引和增量索引使用的都是一个索引文件，所以在执行增量索引时会自动合并到最终的索引中。

  • 实时检索的支持

sphinx本身不支持中文分词，Coreseek是现在用的最多的sphinx中文全文检索，它提供了为Sphinx设计的中文分词包LibMMSeg。Coreseek目前稳定版是3.2.14(基于Sphinx 0.9.9 release开发)，该版本还不支持实时检索。目前Ｃoresekk4.1还是测试版，测试版本支持实时检索，但是不太稳定。

solr的索引支持实时新增、更新和删除，可以根据记录的最后更新时间实现增量更新，在增量更新数据不多的情况下，可以设置增量更新任务为10秒更新一次。从而达到数据的实时同步。

Sphinx的优点是，简历索引，搜索都比较快
缺点是对实时性支持比较差，语法上相对弱一些

在java中，那么从扩展性上来讲solr的当然好些，毕竟是一个原生的java应用。但是从使用上来说我觉得sphinx反而简单些

使用java开发推荐solr　他是基于lucene的对中文支持已经比较完善了。。中文分词也有。sphinx对支持中文比较差，要用修改过的才可以比如 coreseek