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