zoukankan      html  css  js  c++  java
  • 几种常见的基于Lucene的开源搜索解决方案对比

    http://www.cnblogs.com/ibook360/archive/2011/12/05/2277054.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 的增大,查询时的速度受到的影响会非常大

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

    参考材料: http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E

  • 相关阅读:
    a标签去除默认样式
    js获取浏览器的get传值
    apache启动的时候报错非法协议
    获取iframe引入页面内的元素
    百度地图,画多边形后获取中心点
    echarts重写提示框信息,使提示框内的数字每3位以逗号分割
    echarts图例和图例文字位置的设置
    websocket socketJs
    winds添加静态路由
    pscp命令详解
  • 原文地址:https://www.cnblogs.com/lexus/p/2291016.html
Copyright © 2011-2022 走看看