MySQL、HBase、ES的特点和区别

MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。

HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql。

ElasticSearch：ES是一款分布式的全文检索框架，底层基于Lucene实现，虽然ES也提供存储，检索功能，但我一直不认为ES是一款数据库，但是随着ES功能越来越强大，与数据库的界限也越来越模糊。天然分布式，p2p架构，不支持事务，采用倒排索引提供全文检索。

Hbase

基本概念

HBase是一个分布式、可扩展、高性能的列式存储系统，基于Google的Bigtable设计。它是Hadoop生态系统的一部分，可以与HDFS、MapReduce、ZooKeeper等组件集成。HBase的主要特点是提供低延迟的随机读写访问，支持大规模数据的存储和管理。
在这里插入图片描述

HBase核心概念：

HFile：HBase的底层存储结构，是一个自平衡的B+树。HFile可以存储多个表的数据，并支持随机读写访问。HFile的索引功能是基于B+树的索引实现的，可以提高查询性能。
MemStore：HBase的内存存储结构，是HFile的基础。MemStore是一个有序的键值对缓存，每次写入数据时，数据首先写入MemStore，然后定期刷新到HFile。MemStore的搜索功能是基于内存中的数据实现的，可以提高查询性能。
Bloom过滤器：HBase使用Bloom过滤器来减少不必要的磁盘访问。Bloom过滤器是一种概率数据结构，可以用来判断一个元素是否在一个集合中。Bloom过滤器可以提高查询性能，减少磁盘I/O。
索引文件：HBase为每个表创建一个索引文件，用于存储表中的所有列名。索引文件可以帮助查询引擎快速定位需要查询的列，提高查询性能。
搜索引擎：HBase提供了一个基本的搜索引擎，可以用来实现基本的模糊查询和范围查询。搜索引擎使用了一些基本的搜索算法，如词法分析、词汇分析、排序等。

HRegion是HBase中的基本存储单元，负责存储一部分行键(Row Key)对应的数据。HRegion内部由多个HStore组成，每个HStore存储一部分列族(Column Family)的数据。MemStore中存储的是用户写入的数据，一旦MemStore存储达到阈值时，里面存储的数据就会被刷新到新生成的StoreFile中(底层是HFile)，该文件是以HFile的格式存储到HDFS上，具体如图4所示。

HRegion支持自动分区：
HBase中的一个表，刚创建时，只有一个HRegion，随着数据量递增，达到阈值时，等分成两个HRegion，分布在不同的HRegionServer结点上。阈值由属性hbase.hregion.max.filesize指定，默认10G

在这里插入图片描述
HBase是一个分布式系统，这点跟MySQL不同，它的数据是分散不同的server上，每个table由一个或多个region组成，region分散在集群中的server上，一个server可以负责多个region。

这里有一点需要特别注意：table中各个region的存放数据的rowkey（主键）范围是不会重叠的，可以认为region上数据基于rowkey全局有序，每个region负责它自己的那一部分的数据。

索引原理

Hbase写流程：
在这里插入图片描述
WAL是保存在HDFS上的持久化文件。数据到达 Region 时先写入WAL，然后被加载到MemStore中。这样就算Region宕机了，操作没来得及执行持久化，也可以再重启的时候从WAL加载操作并执行。跟Redis的AOF类似。

Client 先访问 zookeeper，访问 /hbase/meta-region-server 获取 hbase:meta 表位于哪个 Region Server。
访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 Region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
与目标 Region Server 进行通讯。
将数据顺序写入（追加）到 WAL。
将数据写入对应的 MemStore，数据会在 MemStore 进行排序。
向客户端发送 ack，此处可看到数据不是必须落盘的。
等达到 MemStore 的刷写时机后，将数据刷写到 HFile
在web页面查看的时候会随机的给每一个Region生成一个随机编号。

Hbase读流程：
在这里插入图片描述

Client 先访问 ZooKeeper，获取 hbase:meta 表位于哪个 Region Server。
访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
与目标 Region Server 进行通讯。
分别在 Block Cache(读缓存)，MemStore 和 Store File(HFile)中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本(time stamp)或者不同的类型(Put/Delete)。
将从文件HFile中查询到的数据块(Block，HFile 数据存储单元，默认大小为 64KB)缓存到 Block Cache。
将合并后的最终结果，然后返回时间最新的数据返回给客户端。

性能调优

1，HBase预分区：

HBase表在刚刚被创建时，只有1个分区（region），当一个region过大（达到hbase.hregion.max.filesize属性中定义的阈值，默认10GB）时，表将会进行split，分裂为2个分区。表在进行split的时候，会耗费大量的资源，频繁的分区对HBase的性能有巨大的影响。

HBase提供了预分区功能，即用户可以在创建表的时候对表按照一定的规则分区。减少由于region split带来的资源消耗。从而提高HBase的性能。

2，定期进行Major Compaction：

HBase中的数据是以StoreFile的形式存储的，随着数据的不断写入，StoreFile的数量会逐渐增加，影响查询效率。

优化方案
定期执行Major Compaction操作，将多个小文件合并成一个大文件，减少StoreFile的数量。

ElasticSearch

基本概念

ElasticSearch 是一个分布式的搜索引擎，所以一般由多台物理机组成。每个物理机器上可以有多个节点，使用不同的端口和节点名称。节点按主要功能可以分为三种：主节点(Master Node)，协调节点(Coordianting Node)和数据节点(Data Node)：

在这里插入图片描述

主节点：处理创建，删除索引等请求，维护集群状态信息。可以设置一个节点不承担主节点角色
协调节点：负责处理请求。默认情况下，每个节点都可以是协调节点。
数据节点：用来保存数据。可以设置一个节点不承担数据节点角色

在这里插入图片描述

Index (索引)
Index(索引) 是具有稍微类似特征文档的集合，同在一个索引中的文档共同建立倒排索引。类似于 MySQL 中的 database 概念，但 ES 中的 Index 更加灵活，用起来也更加方便。提交给同一个索引中的文档，最好拥有相同的结构。这样对于 ES 来说，不管是存储还是查询，都更容易优化。
分片 & 副本（Shards & Replicas）
索引可以存储大量的数据，可能会超过单个节点的硬件限制，而且会导致单个节点效率问题。ES 提供了将单个 Index 拆分到多个 Shard 上的能力，可以支持水平扩展，分布式和并行跨 Shard 操作（可能在多个节点），从而提高了性能和吞吐量。
为了避免故障导致节点及分片出现问题，ES 可以为分片设置副本（Replicas），副本通常在不同的节点上，从而保证高可用性。
类型（Type）
Document 的类型，类似于关系型数据库中的表的概念。该概念在6.X 时还可以使用，但在 Type 的概念已在7.X 开始废弃，官方认为这是个错误的设计。
Document (文档)
文档是 ES 索引的基本单位，每个索引都是由数量众多的文档组成，Document 相当于传统数据库中的行，ES 中数据以 JSON 的形式来表示。
字段（Fields）
每个 Document 都类似一个 JSON 结构，它包含了许多字段，每个字段都有其对应的值，多个字段组成了一个 Document，可以类比关系型数据库数据表中的字段。
映射（mapping）
相当于数据库中的 schema，用来约束字段的数据类型，每一种数据类型都有对应的使用场景。mapping 中定义了一个文档所包含的所有 field 信息，每个文档都有映射。mapping 不是必须创建，因为 ES 中实现了动态映射。

在这里插入图片描述

{
  "_index": "user",
  "_type": "_doc",
  "_id": "qbuOs4AB1VH6WaY_OsFW",
  "_version": 1,
  "_score": 1,
  "_source": {
    "name": "张三",
    "address": "广东省深圳市",
    "remark": "他是一个程序员",
    "age": 28,
    "salary": 8800,
    "birthDate": "1991-10-05",
    "createTime": "2019-07-22T13:22:00.000Z"
  }
}

上图为 ES 一条文档数据，而一个文档不只有基础数据，它还包含了元数据(metadata)——关于文档的信息，也就是用下划线开头的字段，它是官方提供的字段：

_index ：文档所属索引名称，即文档存储的地方。
_type ：文档所属类型名（此处已默认为_doc）。
_id ：文档的唯一标识。在写入的时候，可以指定该 Doc 的 ID 值，如果不指定，则系统自动生成一个唯一的 UUID 值。
_score ：顾名思义，得分，也可称之为相关性，在查询是 ES 会根据一些规则计算得分，并根据得分进行倒排。除此之外，ES 支持通过 Function score query 在查询时自定义 score 的计算规则。
_source ：文档的原始 JSON 数据。字段Field
在动态映射的作用下，name会映射成text类型，age会映射成long类型，birthDate会被映射为date类型

索引原理

我们知道ES的搜索是非常快的，并且比MySQL快很多，所以来看下两者的索引原理：

MySQL的索引原理：B+Tree索引
ElasticSearch的索引原理：倒排索引

倒排索引：也叫反向索引，首先对文档数据按照id进行索引存储，然后对文档中的数据分词，记录对词条进行索引，并记录词条在文档中出现的位置。这样查找时只要找到了词条，就找到了对应的文档。概括来讲是先找到词条，然后看看哪些文档包含这些词条。通俗地来讲，正向索引是通过key找value，倒排索引则是通过value找key。跟MySQL中的索引回表查询有点类似。

下面倒排索引简单实例

假设我们有如下几篇文档:

Doc1：乔布斯去了中国。
Doc2：苹果今年仍能占据大多数触摸屏产能。
Doc3：苹果公司首席执行官史蒂夫·乔布斯宣布，iPad2将于3月11日在美国上市。
Doc4：乔布斯推动了世界，iPhone、iPad、iPad2，一款一款接连不断。
Doc5：乔布斯吃了一个苹果。

这五个文档中的数字代表文档的ID，比如 Doc中的1。通过这5个文档建立简单的倒排索引:

单词ID(WordID) 单词(Word) 倒排列表(DocID)

1	乔布斯	1，3，4，5
2	苹果	2，3，5
3	iPad2	3，4
4	宣布	3
5	了	1，4，5
…	…	…

首先要用分词系统将文档自动切分成单词序列，这样就让文档转换为由单词序列构成的数据流，并对每个不同的单词赋予唯一的单词编号(WordID)，并且每个单词都有对应的含有该单词的文档列表即倒排列表。如上表所示，第一列为单词ID，第二列为单词ID对应的单词，第三列为单词对应的倒排列表。如第一个单词ID“1”对应的单词为“乔布斯”，单词“乔布斯”的倒排列表为{1,3,4,5}，即文档1、文档3、文档4、文档5都包含有单词“乔布斯”。所以当我们搜索的关键字中含有乔布斯的关键字时，此时就能找到文档Doc1，Doc3，Doc4，Doc5。

这上面的列表是最简单的倒排索引，下面介绍一种更加复杂，包含信息更多的倒排索引。

单词ID(WordID)	单词(Word)	倒排列表(DocID;TF;<Pos>)
1	乔布斯	(1;1;<1>),(3;1;<6>),(4;1;<1>),(5;1;<1>)
2	苹果	(2;1;<1>),(3;1;<1>),(5;1;<5>)
3	iPad2	(3;1;<8>),(4;1;<7>)
4	宣布	(3;1;<7>)
5	了	(1;1;<3>),(4;1;<3>)(5;1;<3>)
…	…	…

TF(term frequency): 单词在文档中出现的次数。
Pos: 单词在文档中出现的位置。

这个表格展示了更加复杂的倒排索引，前两列不变，第三列倒排索引包含的信息为(文档ID，单词频次，<单词位置>)，比如单词“乔布斯”对应的倒排索引里的第一项(1;1;<1>)意思是，文档1包含了“乔布斯”，并且在这个文档中只出现了1次，位置在第一个。

性能调优

分片的设定：对于生产环境中分片的设定，需要提前做好容量规划，主分片数是在索引创建的时候预先设定，事后无法修改

分片数设置过小
- 后续无法增加节点实现水平扩展
- 单个分片的数据量太大，导致数据重新分配耗时
分片数设置过大，7.0开始，默认主分片设置成1，解决了over-sharding的问题
- 影响搜索结果的相关性打分，影响统计结果的准确性
- 单个节点上过多的分片，会导致资源浪费，同时也会影响性能
  用图形表示出来可能是这样子的：

参考：
https://blog.csdn.net/weixin_42081445/article/details/144748629
https://www.cnblogs.com/aspirant/p/11004991.html
https://blog.csdn.net/sadfasdfsafadsa/article/details/141716347
https://blog.csdn.net/universsky2015/article/details/135789000