Lucene,Elasticsearch,Solr,Xapian,Sphinx主流搜索引擎的对比

Lucene

系别:JAVA

基于Java的一个开放源代码的全文检索引擎工具包，注意是工具包，所以严格来说它并不是一个搜索引擎服务程序，开发者需要了解搜索引擎的基本原理和Lucene的用法，然后根据需求用Java来开发。

Elasticsearch

系别:JAVA

基于Lucene，仅支持json(可通过插件支持各种主流富文本)，索引插入效率高，对比solr更适合近实时查询，但是对历史数据查询速度较solr慢。可用于索引更新频繁需求近实时查询较强的系统。支持分布式，无需额外中间件管理。支持中文分词。社区庞大，Java支持好，有spring-data

Solr(solar)

系别:JAVA

基于Lucene，支持pdf，word，txt等富文本索引(内容索引)，索引插入时查询效率会降低，不适合近实时查询(索引更新频繁)，对历史数据查询速度快，多用于传统应用。支持分布式，但需要zookeeper管理。支持中文分词。社区庞大，Java支持好。

Sphinx

系别:C++

与MySQL紧密结合，无需额外工具即可将MySQL数据上传到搜索引擎，增量索引支持麻烦， sphinx本身不支持中文分词，Coreseek是现在用的最多的sphinx中文全文检索，它提供了为Sphinx设计的中文分词包LibMMSeg。Coreseek目前稳定版是3.2.14(基于Sphinx 0.9.9 release开发)，该版本还不支持实时检索。目前Ｃoresekk4.1还是测试版，测试版本支持实时检索，但是不太稳定。

Xapian

系别:C++

 和Lucene一样，Xapian只是一个搜索引擎工具库，用户可以在其上自己扩展其适合的应用，它是基于概率模型来做为查询分数计算的基本，当然，它还提供了丰富的Boolean查询功能。

 

 

由于lucene，xapian是工具包故排除，以下仅对成型产品作对比

	solr	ElasticSearch	Sphinx	Xapian	lucene
中文分词	支持	支持	国内有版本支持(Coreseek)，但不支持实时检索且稳定性不佳	略	略
支持文档类型	xml，pdf，word，csv等富文本以及json	仅支持json但通过插件也支持各类主流大文本。	无资料显示支持pdf，word等富文本。	略	略
索引速度	10MB/秒，实时索引会阻塞导致查询速度变慢	快(找不到具体数据)	10-15MB/秒，增量索引麻烦	略	略
查询速度	高性能搜索，8G的索引文件，检索响应时间为150ms。高峰支持500并发/秒	比solr慢，但实时索引时比solr快(找不到具体数据)	高性能搜索，在2-4GB的文本数据上，平均每次检索响应时间小于0.1秒;在1.2G文本，100万条文档上进行搜索，支持高达每秒150~250次查询	略	略
分布式	支持，需要zookeeper管理，扩展性好	自带分布式管理，扩展性好	支持分布式	略	略
支持Java	基于Java并支持Java有Javaclient资料丰富	支持Java并有spring-data支持，资料丰富	支持Java但资料比较少	官方标注支持Java，资料很少	Java支持性好
百度指数(日均)	576	839	355	未收录
特点	仅对已有数据进行检索时非常快	实时索引插入速度快，数据量大时检索速度无明显变化	对RDBMS更友好。	是开发工具包，定制性强	是开发工具包，定制性强

 

 

各方面资料显示Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。对于此处所提及的传统搜索以及实时搜索我个人理解便是，实时搜索具体指的是微博，知乎等需要实时更新索引并能被搜索到的应用，与之相对应的传统搜索应该是指数据恒定或增量极少的应用？比如图书馆索引？因为多数资料都从solr检索已经索引的数据时效率比es要快，但是又提到，solr随着数据量增大，检索效率会降低得出solr更适合传统应用。

档案管理系统是基于Java开发的springboot应用，故应选择对Java/spring整合比较友好的检索引擎，故xapian可以排除，另外档案管理系统是中文应用，应选择支持中文分词的搜索引擎，有资料显示sphinx引擎的中文分词插件Coreseek已经停止维护并不太稳定，故也应该排除，剩下的lucene，solr，es均为Java开发，并且solr，es是基于lucene开发的具体解决方案而lucene是搜索工具包，如需要实现搜索功能需自行开发，适合需定制或自研检索引擎的企业/团队，故lucene也被排除，剩下es，solr各有好处，性能不相伯仲。在传统应用中，也就是静态索引中，solr查询速度更快，但是由于增量索引solr会阻塞导致查询变慢，而es则对实时查询支持比较好，虽静态索引中，速度比不上solr但是增量索引时查询并不会影响效率。加上近段时间es的热度迅速上升，易用程度比solr要高，所以我认为可以选择elasticsearch作为档案管理系统的检索引擎。

在文章中我也提到了自己的一些疑问比如solr既然说对既有索引检索速度有优势又提到solr在数据量多的时候会变慢，这个问题我们以后必须去搞懂