摘要：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-202101test_data-202102

2.查问减速问题

在应用ES对数据库进行减速的场景，咱们心愿的是ES查问能力尽可能快。在ES查问不满足要求的时候咱们须要对查问进行调优。

罕用的办法有:

点击关注，第一工夫理解华为云陈腐技术~