转载：几种常见的基于Lucene的开源搜寻解决方案对比

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

一 ?直接使用 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 的增大，查询时的速度受到的影响会非常大

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