关系型数据库Elasticsearch的几种常见问题及解决办法

　　关系型数据库Elasticsearch的几种常见问题及解决办法

　　ES 意识

　　什么是1、ES

　　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的本质缺陷，而是产品设计定位。

　　

　　

　　图解：Elastic擅长的应用场景

　　2、ES 是做什么的

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

　　1）全文搜索

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

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

　　

　　

　　插图：Elasticsearch 官方搜索文档

　　2）应用查询

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

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

　　3）大数据领域

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

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

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

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

　　

　　

　　图示：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 年。这是因为每个人都有不同的概念意识需求。

　　

　　

　　说明：Elasticsearch 核心概念

　　2、development

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

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

　　

　　

　　说明：DSL 语法更复杂

　　3、architecture

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

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

　　4、运维

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

　　5、源代码

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

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

　　6、算法

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

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

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

　　如何拥抱 ES1、官方文件

　　Elasticsearch 早期出版了参考手册《Elastic Authoritative Guide》。这是一本非常好的入门手册。它涵盖了从概念到实战。缺点是版本针对2.0，太老了，去掉了核心概念。 , 其余不适用，目前最新版本已经7.7，跨度太大，Elasticsearch在跨度大的版本之间升级稍微麻烦一点，索引数据几乎不兼容，需要数据升级后重建。 .

　　Elasticsearch目前最好的参考资料是官方文档，资料最全，版本同步发布，多个版本可以同时参考。官方的 Elasticsearch 参考文档也是最乱的。他们拥有所有信息。看完系统，感觉他们还在山上。它有点类似于字典。看了字典，作文还是写不好；而且信息还是英文，所以被屏蔽了。进入国内大部分手续。

　　但是如果你想学习Elasticsearch，至少要多看几遍官方文档，这样才能快速查询定位。

　　

　　

　　图解：官方文档截图说明

　　2、系统学

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

　　Elasticsearch 技术栈有很多特性。系统学习需要很长时间才能保持良好的心态、毅力和大量的参考资料。

　　3、背后的原理

　　Elasticsearch 是站在巨人肩膀上的产品。它借鉴了很多设计思想，集成了很多算法。官方参考文档没有深入讨论技术原理，直接点到最后。如果你想了解更多，你必须另辟蹊径。

　　Elastic 的官方博客有很多高质量的文章，很多人因为英文而忽略。关键的实现原理很多，图文并茂。另外，国内部分云厂商提供Elasticsearch云。产品需要深度定制开发，会有一些深入的原理系列文章，可以阅读参考加深理解。已经具备良好编程思维的也可以直接去下载官方源码，设置断点调试阅读。

　　4、项目实战

　　项目实战是一种非常有效的学习方式。考过驾照的朋友都深有体会。一上车教练就会直接让你练车。你可以通过很多练习来掌握它。 Elasticsearch 在很多领域都做得很好。总结一下，“非强事务ACID场景都适用”，所以可以做的事情很多。

　　日志字段的要求会让你非常关注写入的数据量，不断调整优化策略，提高吞吐量，降低资源消耗；业务系统的要求会让你特别关心数据的一致性和及时性。从其他数据库同步到ES，注意数据同步的速度，注意数据的准确性，不断调整自己的技术方案和策略；大数据领域的需求会让你特别注意查询和聚合，海量数据需要快速检索，也需要快速聚合结果。

　　项目的实际过程是一个挖坑填坑的过程。实战场景更多，需要解决的问题也更多，自然会掌握得很好。