Elasticsearch和Hbase对比分析

迈不过友情╰ 2022-11-30 12:42 562阅读 0赞

参考文章：

[Elasticsearch和Hbase对比分析][Elasticsearch_Hbase]

[MongoDB、Redis、elasticSearch、hbase的对比][MongoDB_Redis_elasticSearch_hbase]

# 为什么写这篇文章 #

可能有些童鞋已经发现：1.阿里云上的Hbase服务，基于Hbase深度定制和扩展，能比较好的支持时序场景和全文检索场景，其增强版Lindorm，已经作为单独的云服务售卖，单独演进。2.腾讯云上，基于ES构建了CTSDB时序数据库单独售卖，同时也推出了增强版的ES云服务。可以看出，在这两个服务所在团队中，一边选择基于ES来支持时序和全文检索场景，一边则选择基于Hbase来支持时序和全文检索场景。基于ES来支持时序和全文检索场景是比较好理解的，因为它本身的功能就支持这些，但是Hbase如何比较好支持全文检索场景呢？实际上，阿里云的Hbase服务借助了Solr这个搜索引擎来构建这块的能力，因为Solr和ES一样，都是基于Lucene构建的搜索服务。那为什么阿里不和腾讯一样，直接基于ES来构建这块的能力呢？Hbase和ES又究竟有哪些共同点，有哪些差异点呢？  
  总的来说，在数据量不是非常大的时候，使用ES更加简单，单纯使用ES就能解决各种查询场景的需求，但是当数据量非常大的时候，现有的社区版本ES则存在不少问题，这个时候往往需要进行一些内核级别的改进（否则就需要更多的业务层干预，并且成本消耗会比较高），类似阿里云和腾讯云上提供的ES服务，实际上都对ES内核做过改进。使用Hbase，则需要依赖更多的组件，这样有好处也有坏处。同时如果要支持全文检索场景，还需要引入Solr或者ES等服务，就如阿里云上的Hbase服务则通过引入Solr来解决全文检索的需求。二者的对比大致如下：

1.  ES和Hbase的写入都是基于LSM树结构，写入性能应该是相当的，不过ES在写入时需要做更多的事情（比如分词构建倒排索引，构建DocValues，进行字段类型的校验，且主副本都需构建索引等），所以ES消耗的CPU是比较高的，但如果只是满足Hbase相关的查询场景，有些东西也是可以通过配置省去的。
2.  在查询场景中，ES能同时支持全文检索和时序检索场景，可以支持丰富的查询需求，并且都是ES本身具备的能力。相对来说，Hbase的scan查询就要弱不少，不过开源生态中有OpenTSDB，SparkSQL，Phoenix，Hive等组件，可以用来丰富Hbase的查询能力（其中OpenTSDB和Phoenix是基于Hbase来构建的，SparkSQL和Hive是基于Hdfs来构建的）。但是，在全文检索这块还是缺失的，所以阿里云上的Hbase通过借助Solr来弥补这块的能力。
3.  在数据的负载均衡这块，ES相对比较简单，很多时候都需要业务方进行索引的滚动、分裂等操作来实现集群的负载均衡。而Hbase提供的StochasticLoadBalancer策略（会综合考虑Region负载、读写请求数、移动代价等因素），更加符合实际的需求。
4.  对于集群的稳定性，ES是计算和存储合一的设计，Hbase则是计算和存储分离的设计，Hbase负责计算部分，存储则交给其依赖的Hdfs来保障。相对来说，计算和存储分离的设计，在海量数据的场景中，稳定性和成本控制是更有优势的。现在很多大公司在使用ES的时候，都采用类似Hbase的做法，将计算和存储分离开，底层存储则利用公司内部提供的分布式文件系统。
5.  对于内存管理这块，ES以前的版本内存管理成本是很高的，1TB左右的数据存储，大约会消耗2G左右的堆内存，这样一台机器存储的数据量就很有限，直到2020年的7.3版本中，才开始将一些数据放到堆外，但是目前采用的LRU内存淘汰策略还是比较简单的，腾讯云的增强版ES在off-heap堆外内存的管理这块进行了优化，提供了更加精细化的管理。Hbase在内存管理这块，相对是比较成熟的，它提供了几种缓存管理策略供用户选择，在实际实现中，一般将BucketCache和LRUBlockCache搭配使用，称为CombinedBlock-Cache。

接下来将从某些小点展开看下二者的一些相同点及差异点：

## 一些重要概念 ##

ES的一些重要概念：

1.  Index: 对用户暴露的搜索单元，由一系列Shard组成，客户端的读写请求都是针对索引进行。
2.  Shard: 对应Lucene的索引，是ES后台真实的执行单元，开始针对索引的写入和查询，最后都会拆分成Shard维度，然后分配到数据节点上执行相关任务，由一系列Segment组成。
3.  Segment: 是ES里面一个完整索引的集合，由一系列Document和索引文件组成。
4.  Document: 对应一条条数据。
5.  Translog: 事务日志，类似于Mysql的Binlog，主要用于数据恢复。

Hbase的一些重要概念：

1.  Table: 由多行数据组成。
2.  Region: 由很多个Store组成，有多少个列簇，就有多少个Store。
3.  Store: 由Memstore和StoreFile组成，一个列簇对应一个Store，包含在内存中的Memstore以及持久化到hdfs里的多个HFile，StoreFile的底层就是HFile，它是HFile的一个轻量级封装
4.  row, column, cell: 一个row由rowKey和多个column及其对应值组成，一张表的所有row都按rowkey的字典序由小到大排序，column由columnFamily和Qualifier组成，cell是row, column, timestamp, type, value等组成。
5.  HLog: 类似于ES的Translog，主要也是用于数据的恢复。

## 部署架构 ##

单纯从单机部署的角度看，其实ES和Hbase是差不多的，都是一个安装包稍微配置下就可以启动使用了。因为Hbase单机版部署时，会同时启动Hmaster和HRegionServer，会内置zookeeper，同时通过使用Linux本地文件系统来解决文件的存储。ES默认就是Master节点、协调节点、以及数据节点同时处于一个节点上的。不过单机版的对比没有太多意义，毕竟不可能在生产环境使用。  
接下来重点看下ES和Hbase在生产环境中使用的部署架构。  
![ES部署架构][ES]![HBASE部署架构][HBASE]

上面第一幅图是ES的部署架构，第二幅图是Hbase的部署架构。  
  由于ES对于集群元数据的分布式管理，是自己实现的一套逻辑，没有依赖zookeeper，所以少了zookeeper部署依赖。另外对于数据的分布式存储，也没有依赖HDFS，ES是基于Lucene自己实现的分布式存储，所以少了HDFS的部署依赖，所以ES的整个部署显得简单很多。由于ES在默认情况下，是集各种角色于一身的，如果不单独指定角色，则它同时作为maser，协调节点，数据节点，ingest节点等。在数据量不是很大的时候，采用这种部署方式是最简单的。不过随着数据量的增大，读写请求越来越多，考虑到集群的稳定性，这个时候，最好将master角色独立出来，因为master节点相当于集群的大脑，其稳定性尤为重要。并且master节点主要做集群管控相关工作，不承担数据的读写，它的负载并不高，所以一般采用的硬件配置也不需要太高。另外，在有些场景中，如果有必要，也可以将ES的协调节点独立出来。对于ES节点的角色配置，相对来说也是比较简单的，只需要在配置文件里指定下角色类型即可。  
  对于Hbase的部署：

1.  它依赖zookeeper来实现Master的高可用，管理系统核心元数据信息，参与RegionServer的宕机恢复，实现分布式锁等功能。
2.  它依赖Hdfs来存储实际的数据，包括用户数据文件、HLog日志文件数据都会存储在hdfs上。hdfs主要由NameNode和DataNode组成，NameNode是整个hdfs的管控中心，它的可靠性非常重要。为了实现高可靠的部署，上图部署了3个JournalNode，他们和NameNode时刻保持通信，能保障两个NameNode的数据一致性。另外每个NameNode上都部署了ZKFC，它们会检测NameNode是否出现异常，然后向zookeeper报告。
3.  HMaster主要负责Hbase的各种管理工作，如用户的各种管理请求、RegionServer中Region的负载均衡、RegionServer的宕机恢复等、清理过期的日志以及文件等。HMaster采用standby模式，可以比较轻松的实现高可靠部署。
4.  HRegionServer主要用来响应用户的IO请求，是Hbase中最核心的模块，除了数据的存储，数据读取和数据写入时，其他和数据相关的操作都是HRegionServer完成的。

## 数据写入 ##

对比写入之前，先了解下LSM树：为了规避磁盘随机写入问题，LSM树将一棵大树拆分成N棵小树，这些小树首先会写入内存中，随着小树越来越多，这些小树就会批量更新到磁盘中去，同时小树也会定期merge成大树，提高查询效率。ES和Hbase都采用了LSM树方式进行数据写入，所以他们写入性能都是比较高的，下面具体看下两者的写入流程。  
Hbase写入流程：

1.  Hbase Client对写入请求进行预处理，并根据hbase:meta元数据定位到需要写入的RegionServer，然后将请求发送过去。
2.  RegionServer对数据进行解析后，首先会写入HLog（HLog的主要作用是当有节点出现宕机等异常情况时，可以根据它进行数据恢复），然后再写入对应Region的Memstore中。
3.  当Region中的Memstore超过一定的阈值后，会执行Flush操作，将内存中的数据写入文件，形成HFile。在HFile中，主要由很多的block组成，为了提高后面的查询效率，会构建出DataBlock，IndexBlock和Bloom Block，MetaBlock等，并且这些Block的元数据信息会形成单独的文件，在RegionServer打开HFile时会加载到内存作为查询入口，其中BloomBlock里采用的布隆过滤器在查询时可以大幅提高查询效率。

ES写入流程：

1.  协调节点处理用户写入请求，然后根据元数据信息确定需要写入的分片，之后将请求发送至数据节点。
2.  数据节点会根据mapping相关的字段属性，对数据进行相关的Lucene索引构建，如倒排索引、DocValues、FiledData等。此时数据是写在Memory buffer中，写完索引文件之后，才会写translog。这里的顺序和Hbase不一样，主要原因大概是写入Lucene时，Lucene会对数据进行一些检查，可能导致Lucene写入失败，如果先写translog，就要处理写入translog成功，但写入Lucene一直失败的问题。
3.  在Memory buffer中的数据每隔一段时间，就会refresh到OS的文件缓存中，然后到达一定的阈值或者index buffer超过设定值时，会执行Flush操作，将文件缓存中的数据持久化到磁盘中，当然如果一直没有达到阈值，操作系统本身在一定的时间间隔里也会将OS文件缓存中的数据持久化到磁盘。

## 数据查询 ##

和数据写入相比，ES和Hbase的数据查询都要复杂不少。另外，和Hbase相比，ES支持的查询场景更加丰富。对于ES包含get和search两种类型。与之相对应的，Hbase包含get和scan。因为get比较简单，这里主要对比search和scan。  
Hbase和ES查询的复杂性，主要是因为它们一次查询都可能涉及多个Hbase的Region（或ES的shard），多块缓存，或者多个数据文件。另外ES和Hbase中的更新和删除操作都没有真正地更新或删除原始数据，更新都是通过多版本号来实现，删除都是通过加’deleted’标签的方式实现。这就使得查询时，需要感知这些，才能保证查询的准确性。另外，在ES中，由于查询场景的多样性，需要考虑的查询场景是非常多的。  
  Hbase查询主要专注于rowkey的范围查询，它的各种设计都围绕着这种场景展开，在这种场景下，它的查询是很快的。主要原因有：1.它会将一次大的请求切分成很多小的请求。2.它能根据keyRange过滤、timeRange过滤、布隆过滤器等快速过滤不符合条件的HFile。3.基于HFile的索引树以及BlockCache机制可以快速找到HFile中对应的key。  
  ES的查询，最主要的优势在于它基于倒排索引构建的全文检索能力，这块是Hbase所不具备的能力。当然，ES除了倒排索引，也有基于DocValues的正排索引，DocValues采用列式存储，可以比较快速地实现聚合和排序查询场景。通过ES提供的DSL和Aggregations，以及SQL查询引擎，用户可以方便的实现各式各样的查询需求。但是ES的索引成本是比较高的，主要是前面提到的，ES为了提高搜索性能，会将一些索引数据加载到堆内存。这块消耗最大的是ES里面的倒排索引对应的FST索引文件，它对内存的消耗比较高，也就是文章最开始提到的内存管理差异点，这里不再赘述。

## 负载均衡 ##

在大数据写入场景中，由于读写请求的不均衡，各个节点之间就可能出现热点问题，就可能出现节点负载很不均衡的情况，从而进一步影响了整个集群的稳定性。所以控制好整个集群的负载均衡是很重要的一件事。在负载均衡这块，我觉得Hbase是要比ES成熟不少的。  
  首先讲下ES，它只保证集群中各个节点的分片数量是相对均衡的，但不保证节点真正的负载是相对均衡的。因为可能各个分片之间的数据读写请求差异很大，单纯从分片数量维度做到均衡是远远不够的。所以，在真实使用的过程中，往往需要业务方自己去实现索引的合并，迁移，分裂等功能，从而实现真正的负载均衡，ES只是提供了一些基础的API供用户调用（如：rollover, shrink等）。  
  Hbase则提供了两种均衡策略，1.SimpleLoadBalancer策略，类似于ES的均衡策略，只是保证各个RegionServer的Region个数基本相等，但没有考虑真正的负载。2.StochasticLoadBalancer策略，它会加权计算各种负载情况（包括：Region个数，Region负载，读写请求数，stroeFile大小，Memstore大小，数据本地化率，移动代价等）,这也是Hbase默认的负载均衡策略。  
  也就是说，Hbase会结合真实的负载情况，自动实现Region的迁移、合并、分裂等操作，可以减少使用方的干预。而ES则不具备这种能力，这也是当前使用ES比较麻烦的一个点。

## 数据合并策略 ##

对于采用LSM树进行数据写入的数据库来说，由于会存在很多小文件，而在对大量小文件进行数据读取的时候，效率比较低。所以，一般都需要对小文件进行合并操作。在ES中，这种操作叫Segments merge。在Hbase中，这种操作叫HFile compaction。另外，在Hbase中，还对compaction进一步细分为minor compaction和major compaction，其中major compaction就是将一个Region下的HFile合并为一个大HFile，这是一个非常昂贵的操作，会在短时间产生大量的IO和网络消耗，一般生产环境对这个操作会非常谨慎。

【触发时机】  
  在ES中，触发merge动作的时机主要有：1.数据最开始写入memory buffer中，然后间隔一段时间后（间隔时间为refresh-interval，可修改），会执行refresh操作，此时会写入OS的文件缓存中，这个过程会触发一次merge。2.在文件缓存中的segments，当达到indexing buffer的阈值或者达到flush\_threshhold，这些segments会执行Flush操作，也就是Lucene的commit操作，会写入磁盘，这个过程也会触发一次merge。3.手动调ES的接口执行merge操作。  
  在Hbase中，大致和ES是一样的，不过在细节上还是有不少差异。主要有：1.Memstore Flush: 数据最开始写入Memstore中，当满足一定的条件后（如：达到Memstore/RegionServer/Region/HLog级别的限制阈值，或者超过一定的时间周期），会执行Flush。2.后台线程周期性检查，如store中总文件数是否大于阈值，是否满足major compaction条件等。3.手动触发。

【合并策略】  
  由于文件的合并在短时间会消耗大量的IO和网络带宽，所以是一个比较昂贵的操作，选择什么样的合并策略，是一件很重要的事情。ES的合并策略比较单一且用户没有其他选择，只能对这个策略里的一些参数进行调整（如：每层允许的segments数量）。相对于ES，Hbase提供了更多的合并策略，用户可以根据自己的业务特点选择合适的合并策略（如：Exploring Compaction Policy, Stripe Compaction等）。

## 宕机恢复 ##

当集群越来越大之后，比如几百个节点的集群，出现一两个节点宕机，应该是时长有之的情况，那么在节点出现宕机时，能否快速恢复，并且不会造成数据丢失，不会造成读写异常，就显得很重要了。  
  在ES中，主要存在Master，协调节点，数据节点三种角色。对于master，如果是独立部署，一般会有3个节点，可允许1个节点挂掉。如果是非独立部署，则允许一半以上的master节点挂掉，不会影响master工作。由于master本身负载不高，采用独立部署模式，一般不会出问题。对于协调节点，因为它本身不存储数据，主要做读写请求转发以及搜索时的数据聚合，协调节点宕机后，master节点会感知到这个变化，后面的读写请求就会转发到其他节点上。宕机的节点恢复后，又会自动加入到集群中，所以协调节点的宕机影响也是很小的。重点是数据节点的宕机，此时影响相对来说就要大不少。当有数据节点宕机后，master会感知到这个变化并通知给其他节点，对于挂掉节点上的主分片，其副本分片马上会升级为主分片（所以主副分片的数据一致性保障是很重要的），之后会另外找其他节点生成一份副本。对于挂掉节点上的副本分片，就只需要另外找一个节点再生成一份副本就行（这里什么时候生成丢失的副本，和选择的策略有关，默认在很短的时间内就会触发，在这种情况下，如果节点过一会就恢复了，就会涉及大量数据移动，所以生成环境中，一般会等待比较长的时间，然后在等待的时间内发出告警，让维护者及时启动宕机节点，如果宕机节点还是无法恢复，才会生成对应副本，这样可以减少很多无用的资源消耗）。  
  在Hbase中，涉及的组件很多，但由于zookeeper和hdfs都是其依赖的组件，并且他们的可靠性保障以及宕机恢复机制也是比较成熟的，这里暂不讨论。不过Hdfs中的NameNode节点要特别注意下，因为它相当于整个hdfs集群的大脑，一旦它出问题，整个Hbase的读写操作就无法进行下去了。所以生产环境中，NameNode一定不要有单点问题，并且最好不要和DataNode节点混合部署在一台机器上，在hadoop2.0之后，为了解决NameNode的单点问题，已经支持NameNode HA高可靠部署方式了，前面在部署架构中也有说明。  
  对于Hbase中的Master，它主要负责集群的负载均衡和读写调度，并没有参与用户的读写请求，所以整体负载并不高，并且可以比较简单的实现Master HA高可靠部署，所以Master的宕机恢复是很容易的。最后，就只剩下RegionServer了，实际上RegionServer也不承担数据存储，不过数据写入前，会先写MemStore，并且这部分的数据是写在内存里的。所以，RegionServer宕机后，就涉及到这部分数据的恢复。这里就要用到HLog来进行恢复了，所以在生产环境中，不要轻易禁掉HLog，虽然不写HLog可以提高写入性能，但是一旦出现RegionServer宕机，就会造成数据丢失。  
  当RegionServer出现宕机时：首先，zookeeper会感知到这个变化，同时把这个变化告诉master。然后，会切分未持久化数据的HLog日志。之后，Master会重新分配宕机RegionServer上的Region。最后，会回放HLog日志补救数据，完成数据恢复。因为整个恢复过程涉及的HLog数据量并不会很大，所以整个恢复过程相对来说还是可控的。

--------------------

### MongoDB ###

**优点**：

(1) 最大的特点是表结构灵活可变，字段类型可以随时修改。

(2) 插入数据时，不必考虑表结构的限制。

(3) 不需要定义表结构这个特点给表结构的修改带来了极大的方便。

**缺点**  
　　给多表查询、复杂事务等高级操作带来了阻碍

**适用场景**  
　　(1) MongoDB很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景。

(2) 例如，有一个游戏应用，需要存储每个用户的信息，用户分为法师、战士等具有不同属性的角色，技能装备，MongoDB只需要一张便就行了

### Redis ###

**优点**

(1) key-value存储所带来的简单和高性能了

(2) 纯内存查询，查询速度远远高于MongoDB这类常规数据库的读写性能

(3) 支持持久化，list、set、String、zset、hashmap多种数据结构

(4) 是key-value数据库中功能最全面、最简单易用的一款数据库

**缺点**

(1) 给复杂查询带来了很多局限

(2) 查询都需要依赖key，所以大大限制了多列查询，区段查询等复杂的查询

(3) 因为是基于内存查询的，所以限制了可存储的数据量，限制了Redis在数据规模很大的应用场景中

**应用场景**

(1) 由于Redis牺牲了常规数据库中的数据表、复杂查询等功能，换来了很大的性能的提升

(2) 适合对读写性能极高，且数据表结构简单，查询条件简单的应用场景

### ElasticSearch ###

**优点**

(1) 其实就是一个搜索引擎，底层是lucene，支持全文搜索

(2) 能够满足国内大多数人的全文搜索的需求，百度、Google就是使用es做的全文搜索

(3) es可以为你自动建立索引，实现高性能的复杂聚合查询

(4) 在复杂的查询也能够达到不错的性能，让开发者不用为如何建立索引而头痛了

**缺点**  
　　最明显的就是字段类型无法修改、写入性能较低、高性能资源消耗

**应用场景**  
　　es的全文搜索使他称为构建搜索引擎的利器，除此之外，es适合复杂的聚合查询，这一特点还使得es非常适合做数据分析使用

### hbase ###

**优点**

(1) 继承了hadoop项目的优点，适合对海量数据的支持

(2) 极强的横向扩展能力

(3) 使用廉价的PC机就能够搭建起海量数据处理的大数据集群

**缺点**  
　　对数据的读取带来了局限，只有同一列族的数据才能够放在一起，而且所有的查询都必须依赖于key，这就使得很多复杂的查询难以实现

**应用场景**  
　　(1) 由于列式存储的能力带来了海量数据的容纳能力，因此非常适合数据量极大、查询条件简单、列与列之间联系不大的场景

(2) eg：搜索引擎使用的网页数据库

(3) hbase是一款很重的产品，依赖很多hadoop组件，如果数据规模规模不大，没必要使用hbase，MongoDB就完全可以满足需求

### MongoDB、Redis、elasticSearch、hbase的适用场景： ###

(1) 如果你对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis；  
(2) 如果你的数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选MongoDB；  
(3) 如果你需要构造一个搜索引擎或者你想搞一个看着高大上的数据可视化平台，并且你的数据有一定的分析价值或者你的老板是土豪，选ElasticSearch；  
(4) 如果你需要存储海量数据，连你自己都不知道你的数据规模将来会增长多么大，那么选HBase。

[Elasticsearch_Hbase]: https://my.oschina.net/u/4402671/blog/4513768
[MongoDB_Redis_elasticSearch_hbase]: https://blog.csdn.net/u012260238/article/details/107897871
[ES]: https://img-blog.csdnimg.cn/20200809225959577.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0MDc4MjI2,size_16,color_FFFFFF,t_70
[HBASE]: /images/20221123/ed5bc1f524304237a5bf00bb168cd403.png