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 )
八 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: http://jetway.iteye.com/blog/1041114
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的开源搜索解决方案对比 原文处参与讨论。