现在的位置: 首页 > 综合 > 正文

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

2019年09月26日 ⁄ 综合 ⁄ 共 1716字 ⁄ 字号 评论关闭

几种常见的基于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 公司的联系太紧密,可定制性比较差

六 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 的增大,查询时的速度受到的影响会非常大

抱歉!评论已关闭.