一 直接使用 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 的增大,查询时的速度受到的影响会非常大
欢迎补充!请到 几种常见的基于Lucene的开源搜索解决方案对比 原文处参与讨论。
参考材料: http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E