Hbase分布式列存储数据库

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: HBase 本质上是一个数据模型,可以提供快速随机访问海量结构化数据。利用 Hadoop 的文件系统(HDFS)提供的容错能力。它是 Hadoop 的生态系统,使用 HBase 在 HDFS 读取消费/随机访问数据,是 Hadoop 文件系统的一部分。HBase 是一个面向列的数据库,在表中它由行排序。表模式定义只能列族,也就是键值对。一个表有多个列族以及每一个列族可以有任意数量的列。后续列的值连续地存储在磁盘上。表中的每个单元格值都具有时间戳。总之,在一个 HBase:表是行的集合、行是列族的集合、列族是列的集合、列是键值对的集合。

Hbase--分布式列存储NOSQL数据库



HBase 本质上是一个数据模型,可以提供快速随机访问海量结构化数据。利用 Hadoop 的文件系统(HDFS)提供的容错能力。它是 Hadoop 的生态系统,使用 HBase 在 HDFS 读取消费/随机访问数据,是 Hadoop 文件系统的一部分。

HBase 是一个面向列的数据库,在表中它由行排序。表模式定义只能列族,也就是键值对。一个表有多个列族以及每一个列族可以有任意数量的列。后续列的值连续地存储在磁盘上。表中的每个单元格值都具有时间戳。总之,在一个 HBase:表是行的集合、行是列族的集合、列族是列的集合、列是键值对的集合。


1、Hbase数据存储在hdfs,少量存内存


2、hbase适合海量稀疏数据存储


3、与传统关系型数据库对比:

行存储:传统关系型数据mysql、oracle

优点:保证数据完整性,写入检查

缺点:读的过程会产生冗余信息

列存储:Nosql数据库

优点:读的过程不会产生冗余

缺点:写入效率差,不保证完整性


4、Hbase优点:

(1)存储海量数据

(2)快速随机访问

(3)进行大量的改写操作

Hbase的优点及应用场景:

半结构化或非结构化数据:

对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase,因为HBase支持动态添加列。

记录很稀疏:

RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储,这样既节省了空间又提高了读性能。

多版本号数据:

依据Row key和Column key定位到的Value能够有随意数量的版本号值,因此对于须要存储变动历史记录的数据,用HBase是很方便的。比方某个用户的Address变更,用户的Address变更记录也许也是具有研究意义的。

仅要求最终一致性:

对于数据存储事务的要求不像金融行业和财务系统这么高,只要保证最终一致性就行。(比如HBase+elasticsearch时,可能出现数据不一致)

高可用和海量数据以及很大的瞬间写入量:

WAL解决高可用,支持PB级数据,put性能高

适用于插入比查询操作更频繁的情况。比如,对于历史记录表和日志文件。(HBase的写操作更加高效)

业务场景简单:

不需要太多的关系型数据库特性,列入交叉列,交叉表,事务,连接等。

Hbase的缺点:

单一RowKey固有的局限性决定了它不可能有效地支持多条件查询[2]

不适合于大范围扫描查询

不直接支持 SQL 的语句查询


5、Hbase结构

rowkey -> Column Family -> Column Qualifer列族具体列

image.png


rowkey   行键


table的主键,table中的记录按照rowkey 的字典序进行排序

Column Family  列族


hbase表中的每个列,都归属与某个列族。列族是表的schema的一部分(而列不是),必须在使用表之前定义。

Timestamp  时间戳


每次数据操作对应的时间戳,可以看作是数据的version number版本号

Column 列


列族下面的具体列属于某一个ColumnFamily,类似于我们mysql当中创建的具体的列

cell单元格


由{row key, column( =<family> + <label>), version} 唯一确定的单元

cell中的数据是没有类型的,全部是以字节数组进行存储


6、Hbase逻辑模型:三维有序

Rowkey -> Column Family -> Column Qualifier -> Timestamp

rowkey行(正序, 从小到大)、column列(正序从小到大)、timestamp时间(倒叙从大到小)

image.png


7、物理模型

image.png

HRegionServer里面有很多的HRegion,HRegion里面有很多的HStore组成,HStore是Hbase核心的存储单元

HStore对应着Table中的Column Family,无论CF内部有多少数据,都会创建一个HStore.

image.png


•Hbase一张表由一个或多个Hregion组成,一个ReginServer可以存储一或多个Region,一个Region只能由一个机器存储。

• 记录之间按照Row Key的字典序排列

• Region按大小分割的,每个表一开始只有一个region,随着数据不断插 入表,region不断增大,当增大到一个阀值的时候,Hregion就会等分会 两个新的Hregion。当table中的行不断增多,就会有越来越多的 Hregion。

regionserver代表节点,regionserver存储多个region(不一定来自同一个table)

Hregionserver代表进程,负责响应用户的IO请求,与HDFS进行交互

最小单元就表示不同的 Hregion可以分布在不同的 HRegion server上。但一个Hregion是不会拆分到多个server上的

image.png

HRegion(物理概念)是Hbase分布式存储和负载均衡的最小单元,但不是存储最小单元

region(逻辑概念)(分裂、合并)

太多:给zk增加负担,造成读写性能下降

太少:降低读写并发能力,导致压力不够分散

对region过大的要切分,切成更小粒度的region分散到其他regionserver上去,来环节压力,负载均衡

不允许系统自动切分,空闲时候再做手动切分

合并:手动完成

分裂,Hbase的Region,默认10G,超过该值,进行分裂

Hbase的锁粒度:行锁定


8、Hbase架构(client,HMaster,HRegionServer,Zookeeper)

image.png


HMaster:负载均衡,管理Hregion,管理Table元数据,权限控制

HRegionServer:管理本地的Hregion,读写HDFS,管理维护Table中数据

本地化:尽可能保证Hregion的数据,和Datanode放到一起,但如果发生了HRegion移动的情况,本地就不能保证,如果想继续保持本地化,需要等待合并

HRegion包含多HStore,HStore是hbase核心的存储单元,对应着Table的ColumnFamily,无论CF内部有多少数据,都会创建一个Hstore。

9、Zookeeper:提供心跳机制,在master和zk之间,以及regionserver和zk之间

10、寻址:client缓存,通过zk获取hregion地址

11、读数据:内存(block cache、memstore)+ hdfs

block cache:读缓存,为了提高读取效率,regionserver粒度

memstore:写缓存,每一个CF(或Hstore)都有自己的们store,region粒度

关系:Blockcache->memcache->StoreFile(Hfile)

12、Hlog--日志(数据)机制,避免数据丢失

一个regionserver上的所有region共享hlog,一次数据提交。

WAL:先写log,再写memstore

Hbsae表格设计:

设计原则总结:

1.rowkey:最大长度64kb,长度越短越好,尽量不要超过16个字节,因为rowkey太长,内存有效利用率会降低,系统不能缓存太多数据

2.分散:建议rowkey设置散列字段

3.唯一性:rowkey独一无二

一、rowkey设计

(1)在region里按照字母(byte)排序

尽可能保证不同的数据要均匀写到不同region上去

(2)散列原则:手机号、IP地址、时间戳反转、高位加hash

rowkey=ip,ip倒叙存储

192.168.0.1 - 192.168.10.1000分散到region上去,降低单点风险

倒叙:192.168.10.100-》001.01.861.291

(3)唯一性原则:rowkey必须唯一

加密:hash(md5、crc32)

二、CF设计:

CF的要求(尽量少,CF数量1~2个,尽量1个):

(1)当某个cf的数据flush的时候,其他cf也会关联被触发flush。所以如果cf比较多,一旦出现连锁反应,会导致系统产生大量大IO

(2)Region分类、合并都是region级别

HBase 2.0 新特性

主要的改进有以下四点:

1.region 每次状态变化,会先记录到 ProcedureWAL中,然后记录在 Meta 表;

2.region 状态信息只存放两个地方:meta 表、HMaster 的内存,不再存放Zookeeper;

3.只有 HMaster 才可以更新 meta 表中的信息;

4.HMaster与RS直接进行状态信息同步,去除Zookeeper


相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
|
4月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
346 0
|
24天前
|
关系型数据库 分布式数据库 数据库
PostgreSQL+Citus分布式数据库
PostgreSQL+Citus分布式数据库
57 15
|
2月前
|
SQL 关系型数据库 分布式数据库
Citus 简介,将 Postgres 转换为分布式数据库
【10月更文挑战第4天】Citus 简介,将 Postgres 转换为分布式数据库
91 4
|
2月前
|
SQL NoSQL MongoDB
一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程
一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程
47 0
|
4月前
|
C# UED 定位技术
WPF控件大全:初学者必读,掌握控件使用技巧,让你的应用程序更上一层楼!
【8月更文挑战第31天】在WPF应用程序开发中,控件是实现用户界面交互的关键元素。WPF提供了丰富的控件库,包括基础控件(如`Button`、`TextBox`)、布局控件(如`StackPanel`、`Grid`)、数据绑定控件(如`ListBox`、`DataGrid`)等。本文将介绍这些控件的基本分类及使用技巧,并通过示例代码展示如何在项目中应用。合理选择控件并利用布局控件和数据绑定功能,可以提升用户体验和程序性能。
74 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
4月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
118 2
基于Redis的高可用分布式锁——RedLock
|
4月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
22天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
53 16