Elasticsearch用得好，下班下得早！

刚接触ES的小伙伴可能会有这样的疑问: 哪些场景下该使用ES?今天我们主要从市面上一些主流的产品对比分析, 看下那些场景下使用ES, 哪些场景下不适ES.

主要竞品如下:

Solr

Solr是第一个基于Lucene核心库功能完备的搜索引擎产品，诞生较早于Elasticsearch。在早期的全文搜索领域，Solr拥有巨大的优势，几乎完全超过了Elasticsearch。然而，在近几年的大数据发展时代，由于Elasticsearch具备分布式特性，满足了许多大数据处理需求。

特别是随着ELK概念的流行，人们几乎完全忽略了Solr的存在。尽管Solr推出了Solr Cloud分布式产品，但已经基本失去了优势。我曾接触过几家数据类公司，他们的全文搜索都是基于Solr构建的，而且通常使用单节点模式。然而，当出现一些问题时，很难找到咨询顾问来排查问题。因此，后来他们都迁移到了Elasticsearch上。

现在几乎所有大小公司都在使用Elasticsearch，除了一些老旧系统仍然使用Solr外，新的项目都应该使用Elasticsearch。我个人认为有以下几个原因：

• Elasticsearch比Solr更加友好和简洁，门槛更低。
• Elasticsearch具有比Solr更丰富的产品功能特点，如分片机制和数据分析能力。
• Elasticsearch的生态系统发展得非常完善，整个Elastic Stack技术栈与各种数据系统都很容易集成。
• Elasticsearch社区发展更加活跃，而Solr几乎没有专门的技术分析大会。

RDBMS

关系型数据库与 Elasticsarch 相比主要优点是事务隔离机制无可替代，但其局限性很明显。主要体现在以下几个方面:

OpenTSDB

OpenTSDB 内部基于 HBase 实现，属于时间序列数据库，主要针对具有时间特性和需求的数据，进行过数据结构的优化和处理，从而适合存储具有时间特性的数据，如监控数据、温度变化数据等。

小米公司开源监控体系 open-falcon 的就是基于 OpenTSDB 实现。

OpenTSDB 时间序列数据库内部实现

Elastic 产品本身无意时间序列这个领域，随着 ELK 的流行，很多公司采用ELK来构建监控体系，虽然在数值类型上不像时间序列数据库做过特别处理，但由于其便利的使用，以及生态技术栈的优势，我们也接受了这样的事实。

HBase

HBase 是列式数据库的代表，其内部有几个致命设计大大限制了它的应用范围：

• 访问 HBase 数据只能基于 Rowkey，Rowkey 设计的好坏直接决定了HBase使用优劣。
• 本身不支持二级索引，若要实现，则需要引入第三方。关于其各种技术原理就不多说了，说说它的一些使用情况。

列式数据库内部数据结构示意图

MongoDB

MongoDB 是文档型数据库的代表，数据模型基于 BSON，而 Elasticsearch 的文档数据模型是 JSON。BSON 本质上是 JSON 的一种扩展，两者可以相互直接转换。另外，它们的数据模式都可以自由扩展，并且没有基本限制。

尽管 MongoDB 在技术上与关系型数据库有竞争关系，并支持严格的事务隔离机制，但在实际工作中，很少有公司会将核心业务数据存储在 MongoDB 中。相对而言，关系型数据库仍然是首选。

若超出这个定位，则 Elasticsearh 相比 MongoDB 有如下优点：

• 文档查询性能，倒排索引/KDB-Tree 比 B+Tree 厉害。
• 数据的聚合分析能力，ES 本身提供了列式数据 doc_value，比 MongoDB 的行式要快不少。
• 集群分片副本机制，ES 架构设计更胜一筹。
• ES 特色功能比 MongoDB 提供的更多，适用的场景范围更宽泛。
• 文档数据样例，ObjectId 由 MongoDB 内置自动生成。

公司刚好有个项目，原来数据层基于 MongoDB 设计构建的，查询问题不少 ，后面成功迁移到 Elasticsearch 平台上，服务器数据量从 15 台降低到 3 台，查询性能还大幅度提升十倍.

Druid

Durid 是一个大数据 MPP 查询型数据产品，核心功能 Rollup，所有的需要 Rollup 原始数据必须带有时间序列字段。

Elasticsearch 在 6.3.X 版本之后推出了此功能，此时两者产品形成竞争关系，谁高谁下，看应用场景需求。

Druid 样本数据，必须带有 time 时间字段。

笔者之前负责过公司所有 Elasticsearch 技术栈相关数据项目，当时也有碰到一些实时聚合查询返回部分数据的需求。

但我们的需求不太一样，索引数据属于离线型更新，每天都会全部删除并重新创建索引插入数据。

Druid 产品技术架构体系示意图

关于 Rollup 这个大数据分析领域，若有大规模的 Rollup 的场景需求，个人更倾向于 Druid。

结语

• Elasticsearch 产品功能全面，适用范围广，性能也不错，综合应用是首选。
• Elasticsearch 在搜索查询领域，几乎完胜所有竞争产品，在笔者的技术栈看来，关系型数据库解决数据事务问题，Elasticsearch 几乎解决一切搜索查询问题。
• Elasticsearch 在数据分析领域，产品能力偏弱一些，简单通用的场景需求可以大规模使用，但在特定业务场景领域，还是要选择更加专业的数据产品，如前文中提到的复杂聚合、大规模 Rollup、大规模的 Key-Value。
• Elasticsearch 越来越不像一个搜索引擎，更像是一个全能型的数据产品，几乎所有行业都在使用，业界非常受欢迎。
• Elasticsearch 用得好，下班下得早。