作者介绍李萌（ynuosoft），Elastic-stack产品深度用户，ES认证工程师。2012年开始接触Elasticsearch，在Elastic-Stack的开发、架构、运维方面有着深入的经验，实践过多个Elasticsearch项目。最暴力的大数据分析应用，最复杂的业务系统应用；业余为企业提供Elastic-stack咨询培训和调优实施。PreambleElasticsearch目前的人气排名非常高。绿色比蓝色好，但又比蓝色好。本人长期从事Elastic-Stack技术栈。为了避免知识匮乏和眼界有限，有必要到外面的世界去看看，丰富自己的世界观。本文从Elastic的竞品角度进行分析和探讨。Elasticsearch在哪些应用场景下使用效果最好？哪些应用场景最好不要使用Elasticsearch？本文仅代表个人观点，不代表社区技术阵营。不一致。竞品Elasticseach从搜索引擎起家，现在专注于大数据分析领域。逐渐演化为全方位的数据产品。在Elasticsearch众多优秀的功能中，与众多数据产品的交叉竞争越来越多。有些功能很有特色，有些功能只是附带的。了解这些产品特性有助于更好地将它们应用到业务需求中。图：Elasticsearch比赛地图示意图1.LuceneLucene是一个核心的搜索库，Elastic也是建立在Lucene的基础上。它们之间的竞争关系由Lucene自身决定。在互联网2.0时代，检验互联网公司最简单的技术要求就是看他们的搜索做的怎么样。那时候大家的做法几乎是一样的。他们都是基于Lucene核心库搭建了一套搜索引擎，剩下的就看各家公司了。公司开发人员的水平。笔者有幸在2012年之前在基于Lucene的垂直行业做搜索引擎，遇到了很多问题，所以需要谈谈：项目基于Lucene封装，业务代码搭建发布与核心库一起。代码耦合度很高，每次有data字段变化都需要重新编译打包发布。这个过程非常麻烦，而且非常危险。重新发布程序时，需要关闭原来的程序，这就涉及到进程切换的问题。索引数据是定期全量重新生成的，还涉及到新旧索引切换、索引实时刷新等问题。需要设计复杂的程序机制来满足各个独立业务线的需求。需要单独搭建一个Lucene索引进程。有很多业务线。之后，管理就是一件麻烦的事情。当单个Lucene索引数据超过单个实例的限制时，需要进行分布式。原来的Lucene是没有办法的，所以常规的做法是按照特定的分类拆分成多个索引进程。客户端查询的时候携带一个具体的分类，后端根据具体的分类路由到具体的索引。Lucene库本身很难控制。对于经验尚浅的开发工程师来说，要考虑的因素太多了。稍有不慎就会导致严重的程序问题。图解：Lucene内部索引构建及查询流程Elasticsearch与Lucene核心库竞争的优势：完美封装了Lucene核心库，设计了友好的Restful-API。开发者无需过多关注底层机制，开箱即用。分片和复制机制直接解决了集群下的性能和高可用问题。近年来随着Elastic的快速发展，市面上基于Lucene构建搜索引擎的项目非常少。他们几乎都选择Elasticsearch作为基础数据库服务。由于其开源的特点，大部分云厂商也在此基础上进行定制开发。深度融合，也没有单独发展一个分支。在这场比赛中，Elasticsearch获胜。2、SolrSolr是第一个基于Lucene核心库的功能完备的搜索引擎产品。它的诞生比Elasticsearch早得多。在全文搜索的早期，Solr的优势非常大，几乎完全压倒了Elastic。在近几年大数据发展的时代，Elastic由于其分布式的特性，满足了很多大数据的处理需求，尤其是后来ELK概念的流行，几乎完全忘记了Solr的存在。Solr-Coud虽然也推出了分布式产品，但基本没有优势。.我接触过几家数据公司。全文检索基于Solr，是单节点模型。偶尔会出现一些问题。我找顾问来解决问题。很难找到人员。稍后，它们将迁移到Elasticsearch。现在市面上几乎所有大大小小的公司都在使用Elasticsearch。除了一些基于Solr的老系统，所有新系统项目都应该是Elasticsearch。个人认为有几个原因：ES比Solr更友好简洁，门槛更低。ES具有比Solr产品更丰富的功能特性、分片机制、数据分析能力。ES生态开发，Elastic-stack整个技术栈相当完善，易于与各种数据系统集成。ES社区比较活跃，几乎没有专门针对Solr的技术分析会议。图解：Solr产品功能模块内部架构图本次比赛，Elasticsearch获胜。3、与Elasticarch相比，RDBMS关系型数据库的主要优势在于事务隔离机制不可替代，但其局限性也很明显，具体如下：关系型数据库的查询性能，在数据量超过百万级后，急剧下降。本质是索引算法效率不高，B+树算法效率不如倒排索引算法。关系数据库索引受最左原则的限制。查询条件字段不能任意组合，否则索引失败。相反，Elasticserach可以任意组合。这种场景在使用数据表关联查询时尤为明显。Elasticsearch可以使用大表和宽表来解决问题，而关系数据库则不能。.关系数据库分表分库后，多条件查询难以实现。Elasticsearch具有天然的分布式设计，可以实现多索引多分片联合查询。关系型数据库聚合性能低，数据量稍大，查询列基数较大，性能下降较快。Elasticsearch使用列式存储进行聚合，效率极高。关系型数据库注重平衡，而Elasticsearch则注重特定的查询速度。如果数据不需要严格的事务机制隔离，个人认为可以使用Elasticsearch代替。如果数据同时需要事务隔离和查询性能，可以使用DB和ES的混合实现。图：RDBMS和ES各自优势示意图4.OpenTSDBOpenTSDB内部基于HBase实现，属于时序数据库。它针对具有时间特性和要求的数据优化处理了数据结构，适合存储具有时间特性的数据。比如监控数据，温度变化数据等，小米的开源监控系统open-falcon是基于OpenTSDB的。说明：OpenTSDB时序数据库内部实现了Elastic产品本身，无时序意图。随着ELK的流行，很多公司都使用ELK搭建监控系统。我们也接受了使用方便和生态技术栈的优势。Elasticsearch构建时间序列非常简单，性能也相当不错：索引创建规则可以按年、月、周、周、日、时等创建索引，非常方便。在数据填写方面，自定义了一个时间字段用于排序，其余字段不需要填写。在数据查询方面，除了按实际顺序查询外，还可以有更多的查询条件。除非对时序数据有非常苛刻的监控需求，否则选择Elasticsearch会比较合适。5、HBaseHBase是列式数据库的代表。它内部有几个致命的设计极大地限制了它的应用范围：访问HBase数据只能基于Rowkey，Rowkey设计的好坏直接决定了HBase的使用。它本身不支持二级索引。要实现它，你需要引入第三方。它的各种技术原理我就不多说了，说说它的一些用法。公司属于物流快递行业，一个与车辆相关的项目，记录了所有车辆的轨迹，车载设备会定期上报车辆轨迹信息。后端数据存储基于HBase，数据量在几十TB以上。由于业务方需要根据车辆轨迹信息计算其每公里油耗及相关费用，因此需要根据查询条件批量查询数据。查询条件有一些非rowkey的字段，比如时间范围、票号、城市号等，这几乎是不可能实现的。原来暴力Done，性能问题堪忧。这个项目的问题一是rowkey很难设计满足查询条件的要求，二是二级索引问题。查询条件有很多。如果列式数据库仅限于Rowkey访问场景，也可以使用Elastic，只要设计好_id就可以达到和HBase一样的效果。如果需要引入三方组件用列式数据库查询，直接在Elasticsearch上搭建更直接。除非对使用列式数据库有非常严格的要求，否则Elasticsearch更通用，更适用于业务需求场景。图解：列式数据库内部数据结构示意图6.MongoDBMongoDB是文档型数据库的代表。数据模型是基于Bson的，而Elasticsearch的文档数据模型是Json。Bson本质上是Json的扩展，可以直接相互转换。数据库的数据模型是可以自由扩展的，基本没有限制。MongoDB本身定位于与关系型数据库竞争，支持严格的事务隔离机制。在这个层面上，其实和Elasticsearch的产品定位是不一样的。但是在实际工作中，几乎没有公司会把核心业务数据放在MongoDB上。关系数据库仍然是首选。如果超过这个位置，Elasticsearch比MongoDB有以下优势：文档查询性能，倒排索引/KDB-Tree优于B+Tree。对于数据聚合和分析能力，ES本身提供了列式数据doc_value，比Mongo的行格式快很多。集群分片复制机制，ES架构设计更优。ES比MongoDB功能更多，适用场景范围更广。文档数据样本，ObjectId由MongoDB自动生成。公司刚刚有一个项目。原有的数据层是基于MongoDB设计构建的，存在很多查询问题。后来成功迁移到Elasticsearch平台。服务器数据量从15条减少到3条，查询性能大幅提升十倍。抛开数据事务隔离，Elasticsearch完全可以替代MongoDB。7.ClickHouseClickHouse是一个MPP查询分析数据库。近年来非常活跃，很多龙头企业都引进了它。我们为什么介绍它？原因可能和其他龙头公司不一样，如下：笔者长期从事大数据工作，经常会遇到数据聚合的实时查询需求。早期我们会选择关系型数据库进行聚合。MySQL/PostgreSQL等查询，稍不注意就容易出现性能瓶颈。后来推出了Elasticsearch这个产品。基于列式设计和分片架构，其性能确实明显优于单节点关系型数据库。Elasticsearch的局限性也很明显。第一，当数据量超过千万级或亿级时，如果聚合列数过多，性能也会达到瓶颈；二是不支持深度二次聚合，导致一些复杂的聚合需求需要人工操作。写代码在外部实现，增加了很多开发工作。后来引入了ClickHouse来替代Elasticserach用于深度聚合的需求。性能不错，数据量在千万级的时候性能很好，资源消耗也比以前低很多。相同的服务器资源可以承载更多的业务需求。与Elasticsearch一样，ClickHouse采用柱状存储结构，支持副本分片。不同的是，ClickHouse的底层有一些独特的实现，如下：MergeTree合并树表引擎，提供数据分区、主索引、二级索引。VectorEngineVector引擎，数据不仅存储在列中，还以向量（列的一部分）进行处理，可以更有效地使用CPU。图：ClickHouse在大数据平台中的地位8.DruidDurid是一款大数据MPP查询数据产品，核心功能为Rollup。所有需要Rollup的原始数据都必须有时间序列字段。Elasticsearch在6.3.X版本之后推出了该功能。这时，两种产品就形成了竞争关系。谁高谁低，就看应用场景需求了。Druid示例数据，必须有时间字段。笔者此前负责公司Elasticsearch技术栈相关的所有数据项目。当时也遇到了一些实时聚合查询返回一些数据，但是我们的需求不一样。索引数据是离线更新的，每天所有的数据都被删除和重新创建。插入数据。此时使用的Elastic版本为6.8.X，只支持离线数据Rollup，所以这个功能没用。Elastic在7.2.X版本之后推出了实时Rollup功能。Druid更专注，其产品设计围绕Rollup展开，而Elastic只是依附；Druid支持多种外部数据，可以直接连接Kafka数据流，也可以直接连接平台自身内部数据；而Elastic只支持内部索引数据，外部数据需要借助第三方工具导入索引；Druid会在数据Rollup后丢弃原来的数据；Elastic会在原有索引基础上进行Rollup后生成新的索引数据；Druid和Elastic的技术架构非常相似，都支持节点职责分离水平扩展；Druid和Elastic都支持在数据模型上建立倒排索引，并基于倒排索引进行搜索和过滤。图解：Druid产品技术架构体系示意图关于Rollup这个大数据分析领域，如果有大规模的Rollup场景需求，我个人更喜欢Druid。结语总结：Elasticsearch产品功能全面，应用广泛，性能良好。综合应用是首选。Elasticsearch在搜索查询领域几乎赢得了所有竞争产品。从笔者的技术栈来看，关系型数据库解决的是数据事务问题，而Elasticsearch则解决了几乎所有的搜索查询问题。在数据分析领域，Elasticsearch的产品能力相对薄弱。简单通用的场景需求，可以大规模使用。但是在具体的业务场景领域，还是需要选择更专业的数据产品，比如上面提到的复杂聚合和大规模Rollup。,大规模Key-Value。Elasticsearch越来越不像一个搜索引擎，而更像是一个全能的数据产品。它几乎应用于所有行业，在行业中非常受欢迎。Elasticsearch用的不错，下班早。注：内容来源于作者在实际工作中使用多种技术栈实现场景需求，一些实践经验和总结思考，为后来者提供参考。本文转载自微信公众号“DBAplus社区”，可通过以下二维码关注。转载本文请联系DBAplus社区公众号。
