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