Solr与ElasticSearch优缺点及企业技术选型参考

Solr与ElasticSearch优缺点及企业技术选型参考

Solr:

优点

1、Solr有一个更大、更成熟的用户、开发和贡献者社区。 
    2、支持添加多种格式的索引,如:HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。 
    3、Solr比较成熟、稳定。 
    4、不考虑建索引的同时进行搜索,速度更快。

缺点

1、建立索引时,搜索效率下降,实时索引搜索效率不高。

使用案例:

Solr是传统搜索应用的有力解决方案,目前仍是最流行的搜索框架。

Elasticsearch

优点

1、Elasticsearch是分布式的。不需要其他组件,分发是实时的,被叫做”Push replication”。 
    2、Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。 
    3、处理多租户(multitenancy)不需要特殊配置,而Solr则需要更多的高级设置。 
    4、Elasticsearch 采用 Gateway 的概念,使得完备份更加简单。 
    5、各节点组成对等的网络结构,某些节点出现故障时会自动分配其他节点代替其进行工作。

缺点

1、只有一名开发者(当前Elasticsearch GitHub组织已经不只如此,已经有了相当活跃的维护者)
    2、还不够自动(不适合当前新的Index Warmup API)

使用案例:

维基百科使用Elasticsearch来进行全文搜做并高亮显示关键词,以及提供search-as-you-type、did-you-mean等搜索建议功能。

    英国卫报使用Elasticsearch来处理访客日志,以便能将公众对不同文章的反应实时地反馈给各位编辑。

    StackOverflow将全文搜索与地理位置和相关信息进行结合,以提供more-like-this相关问题的展现。

    GitHub使用Elasticsearch来检索超过1300亿行代码。

    每天,Goldman Sachs使用它来处理5TB数据的索引,还有很多投行使用它来分析股票市场的变动

总结:

1、当单纯的对已有数据进行搜索时,Solr更快。

2、当实时建立索引时, Solr会产生io阻塞,查询性能较差, Elasticsearch具有明显的优势。

3、随着数据量的增加,Solr的搜索效率会变得更低,而Elasticsearch却没有明显的变化。

4、Solr的架构不适合实时搜索的应用。

5、Solr 支持更多格式的数据,而 Elasticsearch 仅支持json文件格式

6、Solr 在传统的搜索应用中表现好于 Elasticsearch,但在处理实时搜索应用时效率明显低于 Elasticsearch

7、Solr 是传统搜索应用的有力解决方案,但 Elasticsearch 更适用于新兴的实时搜索应用

其他基于Lucene的开源搜索引擎解决方案

1、直接使用 Lucene

说明:Lucene 是一个 JAVA 搜索类库,它本身并不是一个完整的解决方案,需要额外的开发工作。

优点:成熟的解决方案,有很多的成功案例。apache 顶级项目,正在持续快速的进步。庞大而活跃的开发社区,大量的开发人员。它只是一个类库,有足够的定制和优化空间:经过简单定制,就可以满足绝大部分常见的需求;经过优化,可以支持 10亿+ 量级的搜索。

缺点:需要额外的开发工作。所有的扩展,分布式,可靠性等都需要自己实现;非实时,从建索引到可以搜索中间有一个时间延迟,而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善

2、Katta

说明:基于 Lucene 的,支持分布式,可扩展,具有容错功能,准实时的搜索方案。

优点:开箱即用,可以与 Hadoop 配合实现分布式。具备扩展和容错机制。

缺点:只是搜索方案,建索引部分还是需要自己实现。在搜索功能上,只实现了最基本的需求。成功案例较少,项目的成熟度稍微差一些。因为需要支持分布式,对于一些复杂的查询需求,定制的难度会比较大。

3、Hadoop contrib/index

说明:Map/Reduce 模式的,分布式建索引方案,可以跟 Katta 配合使用。

优点:分布式建索引,具备可扩展性。

缺点:只是建索引方案,不包括搜索实现。工作在批处理模式,对实时搜索的支持不佳。

LinkedIn 的开源方案

说明:基于 Lucene 的一系列解决方案,包括 准实时搜索 zoie ,facet 搜索实现 bobo ,机器学习算法 decomposer ,摘要存储库 krati ,数据库模式包装 sensei 等等

优点:经过验证的解决方案,支持分布式,可扩展,丰富的功能实现

缺点:与 linkedin 公司的联系太紧密,可定制性比较差

4、Lucandra

说明:基于 Lucene,索引存在 cassandra 数据库中

优点:参考 cassandra 的优点

缺点:参考 cassandra 的缺点。另外,这只是一个 demo,没有经过大量验证

5、HBasene

说明:基于 Lucene,索引存在 HBase 数据库中

优点:参考 HBase 的优点

缺点:参考 HBase 的缺点。另外,在实现中,lucene terms 是存成行,但每个 term 对应的 posting lists 是以列的方式存储的。随着单个 term 的 posting lists 的增大,查询时的速度受到的影响会非常大

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章