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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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