共计 3165 个字符，预计需要花费 8 分钟才能阅读完成。
摘要：ES 曾经成为了全能型的数据产品，在很多畛域越来越受欢迎，本文旨在从数据库畛域剖析 ES 的应用。
本文分享自华为云社区《Elasticsearch 数据库减速实际》，原文作者：css_blog。
一、计划阐明
Elasticsearch 次要性能是什么，不同的场景有不同的定位，在日志场景咱们能够用 ELK 生态搭建日志剖析零碎，在搜寻畛域 ES 是以后最热门的搜索引擎。在大数据畛域，ES 能够对标 Hbase 提供海量日志的数据仓库；在数据库畛域 ES 能够作为查问剖析型的剖析型数据库应用。ES 曾经成为了全能型的数据产品，在很多畛域越来越受欢迎，本文旨在从数据库畛域剖析 ES 的应用。
ES 不是关系型数据库，数据更新采纳乐观锁，通过版本号管制，不反对事务处理，这也是 ES 区别于传统数据库（Mysql）的中央；然而 ES 反对准确查问减速，多条件任意组合查问，多种聚合查问，查问速度很快，能够代替数据库简单条件查问的场景需要，甚至能够代替数据库做二级索引。
在数据库减速场景通常的做法是客户产生的商品订单数据会写入 Mysql 类关系型数据库，数据库写入保障事务性，然而随着商品订单的数据越来越多，同时客户查问的条件多变，无奈所有字段都建设索引，数据库的查问能力远远不能满足查问诉求。咱们思考用 ES 全量同步数据库数据，在 ES 中做多条件聚合查问，查问的后果能够在 Mysql 中做关联搜寻，在查问商品订单详情展现，Mysql 数据和 ES 数据能够不要求实时统一，能够通 canal 生产 Mysql binlog 日志信息，同步到 ES，实现一次写入，保证数据一致性。以下数据库都以 Mysql 为例进行阐明。
二、索引原理剖析
ES 为什么查问能力远远超过 Mysql 关系型数据库，次要是他们的实现原理和底层存储的数据结构差别决定的，以下比拟两种产品的实现原理。
Elasticsearch 会对所有输出的文本进行解决，建设索引放入内存中，从而进步搜寻效率。在这一点上 ES 要优于 MySQL 的 B + 树的构造，MySQL 须要将索引放入磁盘，每次读取须要先从磁盘读取索引而后寻找对应的数据节点，然而 ES 可能间接在内存中就找到指标文档对应的大抵地位，最大化提高效率。并且在进行组合查问的时候 MySQL 的劣势更加显著，它不反对简单的组合查问比方聚合操作，即便要组合查问也要当时建好索引，然而 ES 就能够实现这种简单的操作，默认每个字段都是有索引的，在查问的时候能够各种相互组合。
（1）数据库索引 B + 树
数据库中索引都是以树来组织的，罕用的有 B tree，B-tree，B+tree，以下介绍 B +tree 的组织构造。
首先咱们先设想下为什么须要建设索引，假如咱们有一张表 book，存储了咱们放弃的书籍信息，名称，作者，公布工夫等，咱们有 10000 条记录，如果咱们须要找一本为《database》的书，那咱们的 SQL 为：
select name，author form book where name =‘database’;咱们须要扫描整个表，全量比拟才能够，如果咱们对 name 建设索引，书名曾经依照程序排序，查问时只须要找到对应地位就能够疾速获取后果。
索引的实质是通过一直地放大想要获取数据的范畴来筛选出最终想要的后果，同时把随机的事件变成程序的事件，也就是说，有了这种索引机制，咱们能够总是用同一种查找形式来锁定数据。
数据库采纳 B +tree 建设索引:
B+tree 数据只存储在叶子节点中。这样在 B 树的根底上每个节点存储的要害字数更多，树的层级更少所以查问数据更快，所有指关键字指针都存在叶子节点，所以每次查找的次数都雷同所以查问速度更稳固。
（2）Elasticsearch 索引原理
ES 建设索引采纳倒排索引的形式存储。
对输出的所有数据都建设索引，并且把所有和文档对应起来，在咱们查找数据的时候咱们间接查找词典（Term），在找到 Term 对应的文档 ID，进而找到数据。这和 Mysql 应用 B +tree 树建设索引的形式相似，然而如果词典 Term 很大，对 Term 的搜寻就会很慢，ES 进一步倡议了词典索引（FST），晋升词典的搜寻能力。
Term Index 以树的模式保留在内存中，使用了 FST+ 压缩公共前缀办法极大的节俭了内存，通过 Term Index 查问到 Term Dictionary 所在的 block 再去磁盘上找 term 缩小了 IO 次数。
Term Dictionary 排序后通过二分法将检索的工夫复杂度从原来 N 升高为 logN。
三、查问比照剖析
以下对于数据库搜寻罕用的场景比照 ES 和数据库：
- 全文检索
ES 反对全文检索，能够对数据分词，每个词通过 FSP 建设词典索引，而 Mysql 关系数据库则不反对，设想下如果搜寻的不是整个字段而是字段中的几个关键词，应用 Mysql 搜寻必须全表扫描。
- 准确搜寻
如果 Mysql 对该字段建设过索引，应用 ES 搜寻和 Mysql 搜寻性能差别不大，可能 Mysql 更快点，然而 ES 是分布式系统，能够反对 PB 级别的数据搜寻，对大表搜寻 ES 劣势更显著。
- 多条件查问
咱们晓得 Mysql 须要对字段建设索引能力减速搜寻过程，而 ES 默认是全索引的，对于多条件查问，触发 Mysql 建设联结索引，否则多个字段搜寻，Mysql 先抉择一个字段搜寻，后果在应用第二个字段过滤失去最终后果。
ES 则采纳多个字段后果集交并操作，应用 bitmap 或者 skiplist 放慢搜寻速度，相比 Mysql 劣势显著。
- 聚合搜寻
Mysql 聚合搜寻如果没有建设索引须要全表扫描排序，如果建设索引在 B +tree 上进行范畴查问。
ES 为了放慢聚合搜寻速度，通过 Doc value 来解决聚合搜寻问题。DocValue 就是列式存储。
存储后果如下：
Docvalue 数据依照文档 ID 排序，DocValue 将随机读取变成了程序读取，
在 es 中，因为分片的存在，数据被拆分成多份，放在不同机器上。然而给用户体验却如同只有一个库一样。对于聚合查问，其解决是分两阶段实现的：
- Shard 本地的 Lucene Index 并行计算出部分的聚合后果。
- 收到所有的 Shard 的部分聚合后果，聚合出最终的聚合后果。
这种两阶段聚合的架构使得每个 shard 不必把原数据返回，而只用返回数据量小得多的聚合后果。这样极大的缩小了网络带宽的耗费。
- 多正本减速
咱们晓得 ES 有 shard 和 replica 的概念，正本一方面能够保证数据的可靠性，另一方面多正本能够放慢搜寻速度进步搜寻并发能力。
四、数据库到 Elasticsearch 同步计划
联合用户理论的应用形式和数据量的大小，Mysql 数据到 ES 能够有多种不同的形式抉择。
- Canal=>Elasticsearch
应用 Canal 间接生产 Mysql binlog 日志写入 ES，这种形式如果 Mysql 写入量大，会面临 Canal 写入阻塞问题。
- Canal =>Kafka=>Elasticsearch
Canal 数据写入到 Kafka，应用另外的 app 生产 Kafka 数据同步到 ES
五、问题汇总
1. 索引 shard 问题
在 Mysql 数据同步到 ES 中面临索引的建设的问题，在数据写入 ES 之前咱们须要提前布局数据的 shards 和 replicas 的个数，replicas 能够动静批改，然而 shards 数创立实现后不能批改。
随着 Mysql 数据量的减少，如果 shard 太少，就会导致每个 shard 的数据量太大的问题。
如果一个索引 600G，只有 3 个 shard，每个 shard 就 200G，会极大的损耗查问能力，也不利于数据迁徙。
咱们能够依照月来滚动创立索引，通过索引别名把所有索引关联起来应用。
test_data-202101
test_data-2021022. 查问减速问题
在应用 ES 对数据库进行减速的场景，咱们心愿的是 ES 查问能力尽可能快。在 ES 查问不满足要求的时候咱们须要对查问进行调优。
罕用的办法有:
点击关注，第一工夫理解华为云陈腐技术~
