Elasticsearch对垒8大竞品技术分析，孰优孰劣？

　　

Elasticsearch对垒8大竞品技术分析，孰优孰劣？

　　

　　作者介绍：李萌（ynuosoft），Elastic-stack产品深度用户，ES认证工程师，2012年接触Elasticsearch，在Elastic-Stack开发、架构、运维方面有深入的经验，拥有实践过各种Elasticsearch项目，最猛烈的大数据分析应用，最复杂的业务系统应用；业余爱好者为企业提供 Elastic-stack 咨询培训和调优实施。

　　Elasticsearch 知道什么是 Elasticsearch

　　什么是 Elasticsearch？不同的人有不同的理解和定位。我写过Elasticsearch对比其他数据产品文章《 Elasticsearch与8大竞争技术竞争，哪个更好？ 》，看了文章下面的评论，很多人都把它当成了搜索引擎。我觉得也是很片面的。下面谈谈我的看法：

　　1）Elasticsearch 是一个搜索引擎

　　Elasticsearch 在搜索引擎数据库领域绝对排名第一。内核建立在 Lucene 之上。它负责支持全文搜索，并提供丰富友好的API。在我早期基于 Lucene 构建搜索应用程序时，要考虑的因素太多了。自从接触到 Elasticsearch，我就不再独立开发搜索应用了。普通工程师控制Lucene需要一定的代价，而且很多机制还不完善，需要做很多*敏*感*词*辅助程序，Elasticsearch几乎已经为你做了。

　　2）Elasticsearch 不是搜索引擎

　　据说不是搜索引擎，估计很多从业者不认可。在个人涉及的项目中，传统使用Elasticsearch进行全文检索的项目占比越来越少，大部分时间用于精准查询。加速，查询条件多，可以随时组合，查询速度非常快，替代了很多其他数据库复杂查询场景的需求；甚至有些数据库产品直接使用Elasticsearch做二级索引，比如HBase、Redis等。Elasticsearch由于自身的一些特点，更像是一个多模态的数据库。

　　

　　图解：Elasticsearch综合数据库排名热度达到第7位

　　3）Elasticsearch 是数据库

　　Elasticsearch 使用 Json 格式承载数据模型，已经成为事实上的文档数据库。虽然底层存储不是Json格式，同类型产品有大名鼎鼎的MongoDB，但两者在产品定位上存在差异。 Elasticsearch更擅长基于查询搜索的分析型数据库倾向于OLAP； MongoDB定位于事务性应用层面的OLTP，虽然也支持数据分析，但作者简单应用后不会用，谁知道谁用。

　　4）Elasticsearch 不是数据库

　　Elasticsearch 不是关系型数据库。内部数据更新采用乐观锁，没有严格的ACID事务特性。任何尝试在关系数据库场景中使用它的应用程序都会遇到很多问题。其他领域的从业者喜欢用这个作为它的缺陷，重申这不是Elasticsearch的本质缺陷，而是产品设计定位。

　　

　　Elasticsearch 是做什么的

　　虽然 Elasticsearch 是建立在 Lucene 之上的，但它的应用领域确实非常广泛。

　　1）全文搜索

　　Elasticsearch 以全文搜索起步，将 Lucene 开发包变成了数据产品，屏蔽了 Lucene 的各种复杂设置，为开发者提供了非常友好的便利。许多传统的关系数据库也提供全文搜索。有的基于Lucene嵌入，有的基于自研。与Elasticsearch相比，功能单一，性能较差，几乎没有可扩展性。

　　如果你的应用有全文搜索需求，建议先迁移到Elasticsearch平台。它提供了丰富的全文查询，让您大吃一惊。使用一次，永远使用它。

　　

　　2）应用查询

　　Elasticsearch 最擅长查询。基于倒排索引的核心算法，查询性能强于所有B-Tree类型的数据产品，尤其是关系型数据库。当数据量超过千万或数亿时，数据检索的效率非常明显。

　　个人比较喜欢Elasticsearch在一般查询应用场景。由于索引的左侧原则，关系数据库必须按照严格的顺序执行。如果查询字段很少，可以通过创建少量索引来提高查询性能。如果查询字段很多，而且字段乱序，那么索引就失去了意义；相反，Elasticsearch 默认为所有字段创建索引，所有字段查询不需要保证顺序，所以我们在大量业务应用系统中使用 Elasticsearch 来替换关系数据库。一般查询，从那时起，对关系数据库的查询就被排斥了。除了最简单的查询，所有条件复杂的查询都是 Elasticsearch。

　　3）大数据领域

　　Elasticserach 已经成为大数据平台提供的外部查询的重要组成部分。大数据平台对原创数据进行迭代计算，然后将结果输出到数据库中提供查询，尤其是大批量的详细数据。

　　这里有几个问题。一个问题是如何在很短的时间内将大量的详细数据输出到数据库中。传统上，很多数据平台都选择关系型数据库来提供查询，比如MySQL。吃了不少苦头，瞬时写入性能极差，根本达不到要求。另一个问题是外部查询，如何像应用系统一样提供性能优良的查询，不限制查询条件，不限制字段顺序，支持高并发，支持海量数据的快速检索，只有Elasticsearch才能做到相对均衡的Search。

　　从正式发布版本的新特性来看，Elasticseacrch旨在提供大数据分析领域基于列表存储的数据聚合。它支持大量的聚合函数，并且具有良好的性能。作者有幸之前*敏*感*词*使用过。我有很多感触。

　　为了深入数据分析领域，Elasticsearch 还提供了数据汇总和数据转换功能，将检索和分析提升到一个新的水平。在数据汇总领域，Apache Druid 很有竞争力。我之前做过一些比较。简单对比确实不如Druid，但是由于Elasticsearch增加了Transfrom功能，并且创建了一个单独的Transfrom节点角色，我比较看好Elasticseach，跳出了Rollup基于时间序列的局限。

　　

　　4）日志检索

　　著名的ELK三件套是关于Elasticsearch、Logstash、Kibana，一个专门为日志采集、存储和查询设计的产品组合。很多第一次接触 Elasticsearch 的朋友都认为 Elasticsearch 是专门做日志的。其实，这些都是误会。他们只是说它在这个领域非常擅长，在这个领域有很多成就，并且享有很高的声誉。

　　日志本身的特性没有普遍标准化，人为随意性大，日志内容也随意。对全文搜索能力的要求就更高了。传统的技术手段本身就很难做到全文搜索。而Elasticsearch本身就是靠全文检索起步的，再加上它的分布式架构，非常适合海量日志快速检索的场景。今天，如果你发现 IT 从业者使用传统的技术手段进行日志检索，他们应该打屁股。

　　现在已经从ELK三件套发展到了Elastic Stack，并且加入了很多非常实用的产品，大大提升了日志检索领域。

　　5）monitoring 字段

　　指标监控，Elasticsearch进入这个领域比较晚，但是已经赶上了好时机。 Elasticsearch由于其倒排索引核心算法也支持时序数据场景，性能相当不错。它在功能上完全压制了时间顺序。数据库。

　　Elasticsearch 致力于监控，这得益于其提供的丰富完整的 Elastic Stack 产品生态系统。在很多情况下，监控需要是三维的。除了指标，还需要采集各种日志的分析。如果使用其他纯指标监控产品，比如Promethues，在满足日志分析的需要时就不得不使用Elasticsearch。对于技术栈来说，已经扩展了，相应的控制能力会降低，个人精力有限，不可能同时掌握多种数据产品。选择更通用的产品才符合现实。

　　

　　6）机器学习

　　机器学习近年来非常流行。已经集成了许多数据产品。 Elasticsearch 也必须拥有它并且做得更好。它将真正使机器学习成为一种产品，简化使用，并看到你所看到的；和其他数据产品一样，只是集成了算法包，用户还需要开发很多应用支持。

　　Elasticsearch 机器学习提供了两种方法，一种是异常检测类型，属于无监督学习，使用聚类模型，通常用于安全分析、异常访问检测等领域；另一种是数据框分析，属于分类和回归，属于监督学习，可用于商业模型领域，如电子商务行业，价格模型分析。

　　Elasticsearch 本身就是一个数据平台，集成了一些机器学习算法和 Kibana 可视化操作，让数据采集、模型训练、模型预测应用一键完成。

　　Elasticserach提供的机器学习套件，我个人认为应该应用在数据质量领域，帮助大数据平台自动检测数据质量，从而降低人力供给效率。

　　

　　要求水平

　　Elasticsearch 的整个技术栈非常复杂，涉及到很多理论和技术点，完全掌握是不现实的。作为一名IT从业者，首先要定位自己的角色，根据角色的需要去学习和掌握必要的。知识点。以下是作者对某技术产品的划分模型：

　　1、 概念

　　Elasticsearch 涉及的概念很多，但核心概念很少。对于新手来说，掌握概念的目的是建立自己的知识思维模型，对后面学到的知识点做一个很好的总结。分配;对于其他数据产品的老手来说，掌握概念的目的是与其他数据产品部门进行对比，深入了解各自的优缺点，如果在以后的工作中遇到新的业务场景，可以快速做出选择。

　　IT从业者普遍有一种感觉，IT技术发展太快，各种技术框架产品层出不穷，学习掌握太难跟上节奏了。其实个人觉得变化不大，基础理论的核心概念也没有发生本质的发展变化。无非是工程技术实践发生了很大的变化，但这些都是深入实践所需要的，不需要概念。

　　作为技术总监，你可以要求前端工程师工作 1 到 2 年。这是因为每个人都有不同的概念意识需求。

　　

　　2、development

　　开发工程师的职责是将需求转化为可以在地上运行的代码。 Elasticsearch的应用开发工作概括起来就是增删改查，掌握必要的Elasticsearch REST API，熟练使用就够了。笔者之前在某*敏*感*词*工作，负责Elasticsearch相关工作。 Elasticsearch 公司有很多需求，尤其是查询。 Elasticsearch 中最强大的查询是 DSL。这个查询语法需要经常练习，否则很容易忘记。当有人提问时，会指派一名工程师负责各种回答。他在编写DSL方面非常熟练，并且帮助了很多新工程师使用Elasticsearch，屏蔽了很多细节。如果有一些困难的问题，我会解决它们。另一方面，作为负责人，我偶尔会请他帮忙写DSL。

　　Elasticsearch 提供了 SQL 查询功能，但是比较有限。复杂的查询聚合必须返回到 DSL。

　　

　　3、architecture

　　Elasticsearch 集群整体架构比较复杂。首先要深入了解Elasticseach背后的原理，包括集群原理、索引原理、数据写入流程、数据查询流程等；其次，真实案例机会多，挑战多。一一解决问题，增加自己的经验。

　　对于开发工程师来说，掌握这些并不是为了开发满足日常需求，但是对于Elasticsearch技术的负责人来说，是非常有必要的。面对各种应用需求，他们必须能够从架构思维上平衡，比如日志场景集群需求、大数据分析场景需求、应用系统复杂查询场景需求等，从实际出发设计集群架构和资源分配情况。

　　4、运维

　　Elasticsearch本质上是一个数据库，也需要专门的DBA运维，但是它更面向应用，所以运维职责没有传统DBA那么严格。对于集群层面，必须掌握集群建设、集群扩容、集群升级、集群安全、集群监控告警等；对于数据级运维，必须掌握数据备份与恢复、数据生命周期管理以及一些日常问题诊断。

　　5、源代码

　　Elasticsearch 本身是开源的。阅读源代码是一个很好的学习工具。很多独特的功能在官方的操作文档中都没有写到。它们需要从源代码中提取，例如集群节点之间的连接数，但对于大多数 Elasticsearch 从业者来说，是没有必要的。据了解，国内各大厂商需要深度的源代码定制和改造，更注重应用改造的便利性，而非结构改造。原来Elastic公司有几百人的产品开发团队，而国内大部分公司人都很少，所以在产出上根本不是一个水平。

　　如果将 Elasticsearch 比作军用武器，最重要的是士兵能否熟练使用它。至于改造，应该是武器制造商的责任。一个士兵可以使用多种武器和装备，并使用最佳的天赋组合。打赢一场战争，与其深究原理和造轮子，更容易把车放在马前。

　　6、算法

　　算法应该被视为数据产品的本质区别。关系数据库索引算法主要基于B-Tree，Elasticserach索引算法主要是倒排索引。算法的性质决定了它们的应用边界和擅长的应用领域。

　　通常在掌握新的数据产品时，个人的做法是查看其关键算法。早期，我做过一个与地理位置搜索相关的项目。我根据某个坐标搜索了周围的坐标信息。一开始，我使用三角函数动态计算方法。数据量有点大，扫描一张数据表需要很长时间；稍后我会遇到它。 Geohash算法，根据算法对坐标进行编码并存储在数据库中。基于前缀匹配查询，性能是几个数量级的高效。我感叹算法的伟大。后来发现有专门的数据库产品，集成了Geohash算法，使用起来更方便。

　　Elasticsearch 集成了很多算法，每种算法的实现都有其应用场景。

　　如何拥抱 Elasticsearch1、官方文件

　　Elasticsearch 早期出版了参考手册《The Elastic Authoritative Guide》。非常好的入门手册，涵盖了从概念到实战。缺点是版本针对2.0，太老了，去掉了核心概念。 , 其余不适用，目前最新版本已经7.7，跨度太大了，

　　Elasticsearch 在跨度较大的版本之间升级比较麻烦。索引数据几乎不兼容，升级后需要重建数据。

　　Elasticsearch目前最好的参考资料是官方文档，最全，同时发布，可以同时参考多个版本。

　　Elasticsearch 的官方参考文档也是最乱的。他们拥有所有信息。看完系统，感觉他们还在山上。它有点类似于字典。看了字典，还是写不好作文；而且信息还是英文的。目前国内大部分手续已被封锁。

　　但是如果你想学习Elasticsearch，至少要多看几遍官方文档，方便快速搜索定位。

　　

　　2、系统学

<p>Elasticsearch 很早就出名了，国内有很多视频课程，大部分都是零散的或者纸上谈兵，缺乏实战经验。 Elasticsearch 有一些专门的书籍，推荐购买阅读，国内推荐比较深入的《Elasticsearch 源码分析与优化实践》，国外推荐的《Elasticsearch 实践》，阅读书籍也有助于培养系统思维。