几种常见的基于Lucene的开源搜索解决方案对比

Sphinx: 功能很强大,遗憾的是Sphinx并不提供Java 编程API,需要绕道.

Sphinx是一个基于SQL的全文检索引擎，可以结合MySQL,PostgreSQL做全文搜索，它可以提供比数据库本身更专业的搜索功能，使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计搜索API接口，如PHP,Python,Perl,Ruby等，同时为MySQL也设计了一个存储引擎插件。

Sphinx的主要优势是：

1. 性能优异。

2. 容易学习：架构很清晰，学习成本很低。

3. 与数据库结合更加紧密：对于以数据库为中心的Web应用来说，实现全文检索的功能，使用Sphinx开发工作量更低。

Sphinx的开发人员好像只熟悉PHP开发，因此在其手册里面举的例子都是用PHP写的，不过Rails/Ruby开发人员也可以很方便地使用Sphinx。

Coreseek:2.X 3.X:

一个支持中文全文检索的Sphinx定制版本——Coreseek，除了支持中文的全文检索外，Coreseek最大的特点是支持使用Python提供自定义的数据源。我们可以简单地理解为：Coreseek = Sphinx + libmmseg +py_datasource。

Xapian:是一个用C++编写的全文检索程序，他的作用类似于Java的lucene。

2010年11月20日 星期六 上午 09:25

一 直接使用 Lucene ( http://lucene.apache.org )

说明：Lucene 是一个 JAVA 搜索类库，它本身并不是一个完整的解决方案，需要额外的开发工作
优点：成熟的解决方案，有很多的成功案例。apache 顶级项目，正在持续快速的进步。庞大而活跃的开发社区，大量的开发人员。它只是一个类库，有足够的定制和优化空间：经过简单定制，就可以满足绝大部分常见的需求；经过优化，可以支持 10亿+ 量级的搜索。
缺点：需要额外的开发工作。所有的扩展，分布式，可靠性等都需要自己实现；非实时，从建索引到可以搜索中间有一个时间延迟，而当前的“近实时”(Lucene
Near Real Time search)搜索方案的可扩展性有待进一步完善

二 Solr ( http://lucene.apache.org/solr/ )

说明：基于 Lucene 的企业级搜索的开箱即用的解决方案
优点：比较成熟的解决方案，也有很多的成功案例。Lucene 子项目，实现了大部分常见的搜索功能需求，包括
facet 搜索（搜索结果分类过滤）等。
缺点：可定制性比 Lucene 要差，一些不常见的需求，定制的难度比直接在 Lucene 上做要大的多。性能上，由于 Solr 的建索引和搜索是同一个进程，耦合度比较高，对于性能调优有一定的影响。

三 Katta ( http://katta.sourceforge.net/ )

说明：基于 Lucene 的，支持分布式，可扩展，具有容错功能，准实时的搜索方案。
优点：开箱即用，可以与 Hadoop 配合实现分布式。具备扩展和容错机制。
缺点：只是搜索方案，建索引部分还是需要自己实现。在搜索功能上，只实现了最基本的需求。成功案例较少，项目的成熟度稍微差一些。因为需要支持分布式，对于一些复杂的查询需求，定制的难度会比较大。

四 Hadoop contrib/index ( http://svn.apache.org/repos/asf/hadoop/mapreduce/trunk/src/contrib/index/README )

说明：Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。
优点：分布式建索引，具备可扩展性。
缺点：只是建索引方案，不包括搜索实现。工作在批处理模式，对实时搜索的支持不佳。

五 LinkedIn 的开源方案 ( http://sna-projects.com/ )

说明：基于 Lucene 的一系列解决方案，包括 准实时搜索
zoie ，facet 搜索实现
bobo ，机器学习算法
decomposer ，摘要存储库
krati ，数据库模式包装
sensei 等等
优点：经过验证的解决方案，支持分布式，可扩展，丰富的功能实现
缺点：与 linkedin 公司的联系太紧密，可定制性比较差

六 ElasticSearch ( http://www.elasticsearch.com/ )

说明：基于 Lucene 的，分布式，云端，提供 rest 接口的搜索解决方案
优点：开箱即用，分布式，rest 接口，支持云端调用
缺点：一个新的项目，没有经过很多的验证。（只有一个人在开发？）分片的数目不能动态调整，只能在初始化索引的时候指定（跟
HBase 不一样的地方）

七 Lucandra ( https://github.com/tjake/Lucandra )

说明：基于 Lucene，索引存在
cassandra 数据库中
优点：参考
cassandra 的优点
缺点：参考
cassandra 的缺点。另外，这只是一个 demo，没有经过大量验证

八 HBasene ( https://github.com/akkumar/hbasene )

说明：基于 Lucene，索引存在
HBase 数据库中
优点：参考
HBase 的优点
缺点：参考
HBase 的缺点。另外，在实现中，lucene terms 是存成行，但每个 term 对应的 posting lists 是以列的方式存储的。随着单个 term 的 posting lists 的增大，查询时的速度受到的影响会非常大

九：DBSight (http://www.dbsight.net )
全文数据库搜索工具

它主要能从一两个SQL出发，取出数据库内容，建立Lucene索引，加上facet搜索等许多功能，并能实现搜索平台的自动无人管理，免除了很多重新发明轮子的工作，源码未开放。

十： ompass: /article/3832236.html

Compass其实就是在Lucene外面包了一层持久化的壳

Nutch: 主要分为两个部分: 爬虫crawler和查询searcher, Crawler主要用于从网络上抓取网页并为这些网页建立索引。Searcher主要利用这些索引检索用户的查找关键词来产生查找结果。两者之间的接口是索引，所以除去索引部分，两者之间的耦合度很低。

Nutch是基于Lucene的。Lucene为Nutch提供了文本索引和搜索的API。一个常见的问题是：我应该使用Lucene还是Nutch？

最简单的回答是：如果你不需要抓取数据的话，应该使用Lucene。

常见的应用场合是：你有数据源，需要为这些数据提供一个搜索页面。在这种情况下，最好的方式是直接从数据库中取出数据并用Lucene API 建立索引，如果你没有本地数据源，或者数据源非常分散的情况下，应该使用Nutch。

http://www.iteye.com/topic/1051417

主题：全文检索 方案比较

1.Lucene+ RMI

在DB服务器(或其它服务器)部署RMI服务端,并将索引建立于该服务器上.索引的更新和查询都走RMI

优点: 易于实现

2. Lucene+NFS

类似于Lucene+RMI部署架构,由于索引数据量不大,检索时可采用RAMDirectory.

优点: 易于实现

缺点: 未使用过此类架构,对其网络延迟等问题缺乏评估

3. Lucene+Hadoop

利用Hadoop建立分布式文件系统.本人对Hadoop不熟悉,对此方案的可行性无法评估.

若有牛人成功实施过此方案,还望提供相关经验和资料. 如果此方案可行,本人非常希望借此机会学习Hadoop.

欢迎补充！请到
几种常见的基于Lucene的开源搜索解决方案对比 原文处参与讨论。

http://blog.fulin.org/2010/11/search_solutions_compare.html