ES vs. Lucene：

完美封装了Lucene核心库；友好的Restful-API，开发者无需过多关注底层机制，开箱即用。

分片与副本机制，直接解决了集群下性能与高可用问题。

 ES vs. Solr

 友好简洁门槛低，产品功能丰富，支持分片机制。ES整个技术栈相对更全，与各种数据系统更容易集成。

ES vs. RDBMS

 1. B+树算法不如倒排索引算法高效

2. 关系型数据库索引最左原则限制导致查询条件字段不能任意组合，否则索引失效，相反ES可以任意组合，在数据表关联查询时特别明显，ES可以采用大宽表解决，而RDBMS不能。

3. 关系型数据库分库分表后多条件查询难于实现，ES天然分布式设计，多个索引多个分片皆可联合查询。

4. 关系型数据库聚合性能低下，数据量和查询列基数稍多则性能下降很快，而ES在聚合上采用的是列式存储，效率极高。

5. 关系型数据库侧重均衡性，Elasticsearch侧重专一查询速度。 但注意：：：RDBMS优点是事务隔离机制无可替代。

ES vs. OpenTSDB

OpenTSDB内部基于HBase实现，属于时间序列数据库，针对具有时间特性的数据结构进行了优化和处理 。ELK的流行导致ES构建时间序列很简单，性能也相当不错：索引创建规则，可以按年、按月、按周、按星期、按天、按小时等都创建索引。数据填充方面，定制一个时间字段做区分排序，其余的字段无需。

ES vs. HBase

HBase是列式数据库的代表，其内部有几个致命设计大大限制了它的应用范围，即访问HBase数据只能基于Rowkey，Rowkey设计的好坏直接决定了HBase使用优劣，本身不支持二级索引，若要实现，则需要引入第三方。

 如果用列式数据库仅限于Rowkey访问场景，其实采用ES也可以，只要设计好 _id，与HBase可以达到相同的效果。

ES vs. MongoDB

MongoDB是文档型数据库的代表，数据模型基于Bson，而Elasticsearch的文档数据模型是Json，Bson本质是Json的一种扩展，可以相互直接转换，且它们的数据模式都是可以自由扩展的，基本无限制。 ES相比MongoDB优点：

1.文档查询性能，倒排索引/KDB-Tree比B+Tree厉害。

2.数据的聚合分析能力，ES本身提供了列式数据doc_value，比Mongo的行式要快不少。

3.集群分片副本机制，ES架构设计更胜一筹。

4.ES特色功能比MongoDB提供的更多，适用的场景范围更宽泛。

5.文档数据ObjectId由MongoDB内置自动生成。

ClickHouse  vs. ES

数据聚合的实时查询需求使用MySQL很容易出现性能瓶颈。ES基于列式设计以及分片架构，但局限性也很明显，一是数据量超过千万或者亿级时，若聚合的列数太多，性能也到达瓶颈；二是不支持深度二次聚合，导致一些复杂的聚合需求，需要编写代码在外部实现。 而这方面ClickHouse替代Elasticserach做深度聚合需求，性能表现不错，在数据量千万级亿级表现很好，且资源消耗相比之前降低不少。

ClickHouse是一款MPP查询分析型数据库，也采用列式存储结构，都支持副本分片，不同的是ClickHouse底层有一些独特的实现：MergeTree 合并树表引擎，提供了数据分区、一级索引、二级索引；Vector Engine 向量引擎，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，可以更加高效地使用CPU。

ES vs. Druid

Durid是一款MPP查询型数据产品，核心功能Rollup，所有的需要Rollup原始数据必须带有时间序列字段，ES在7.2.X版本后才推出实时Rollup功能。但Druid更加专注，产品设计围绕Rollup展开，ES只是附带；

Druid支持多种外接数据，直接可以对接Kafka数据流，也可直接对接平台自身内部数据；而ES仅支持内部索引数据，外部数据需要借助三方工具导入到索引里；

Druid在数据Rollup之后，会丢弃原始数据；ES在原有索引基础之后，生成新的Rollup之后的索引数据；

Druid与ES都支持节点职责分离，支持横向扩展；

Druid与ES在数据模型上都支持倒排索引， 并进行搜索与过滤。

若有大规模的Rollup的场景需求更倾向于Druid。

总结：

Elasticsearch产品功能全面，适用范围广，性能也不错，综合应用是首选。在搜索查询领域，几乎完胜所有竞争产品； 从技术栈看来，关系型数据库解决数据事务问题，Elasticsearch几乎解决一切搜索查询问题。但在数据分析领域，产品能力偏弱，在特定业务场景还是要选择更加专业的数据产品，如复杂聚合、大规模Rollup、大规模的Key-Value。