分布式NoSQL列存储数据库Hbase Java API（四）

2021-04-09 15:35:57 浏览数 (1)

文章目录

  • 分布式NoSQL列存储数据库Hbase（四）
    • 知识点01：课程回顾
    • 知识点02：课程目标
    • 知识点03：存储设计：存储架构
    • 知识点04：存储设计：Table、Region、RegionServer的关系
    • 知识点05：存储设计：Region的划分规则
    • 知识点06：存储设计：Region内部存储结构
    • 知识点07：存储设计：HDFS中的存储结构
    • 知识点08：热点问题：现象及原因
    • 知识点09：分布式设计：预分区
    • 知识点10：Hbase表设计：Rowkey设计

分布式NoSQL列存储数据库Hbase（四）

知识点01：课程回顾

知识点02：课程目标

  1. Hbase存储设计
    • 整个Hbase中的存储结构？
      • Hbase、Zookeeper、HDFS
    • Table与RegionServer的关系？
    • Table怎么实现分布式？划分Region的规则是什么呢？写入数据分配的规则？【重要】
    • Region内部的存储？【重要】
    • Hbase数据与HDFS的关系？
  2. Hbase最严重的问题：热点
    • 现象、原因
    • 解决方案【重要】
      • 预分区：一张表有多个Region分区
      • 表的设计：Rowkey的设计

知识点03：存储设计：存储架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yYfd67AX-1616633798599)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317190105892.png)]

  • 问题：Hbase整体如何实现数据的存储？
  • 分析
    • Client：负责连接服务端
      • 提供开发接口，将用户的命令或者代码提交给服务端执行
      • 将服务端执行的结果返回给用户
    • Zookeeper：存储Hbase部分元数据
      • 所有Hbase客户端，都需要连接Zookeeper获取元数据
    • Hbase：分布式内存
      • HMaster：管理类功能
      • HRegionServer：负责数据的存储，对外提供客户端读写
        • 分布式内存
    • HDFS：分布式磁盘
      • DataNode：负责将Hbase内存中的数据写入磁盘

知识点04：存储设计：Table、Region、RegionServer的关系

  • 问题：客户端操作的是表，数据最终存在RegionServer中，表和RegionServer的关系是什么？
  • 分析
    • Table：是一个逻辑对象，物理上不存在，供用户实现逻辑操作，存储在元数据的一个概念
      • 类似于HDFS中文件
    • RegionServer：是一个物理对象，Hbase中的一个进程，管理一台机器的存储
      • 类似于HDFS中DataNode
    • Region：Hbase中数据存储的最小单元
      • 类似于HDFS中Block
      • 就是分区的概念，每张表都可以划分为多个Region，实现分布式存储
        • 默认一张表只有一个分区
      • 每个Region由一台RegionServer所管理，Region存储在RegionServer
        • 一台RegionServer可以管理多个Region
  • 观察监控 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JyhZT7gp-1616633798601)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091350259.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u8AXyrI7-1616633798603)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091417912.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WvMurhSI-1616633798606)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091609104.png)]

知识点05：存储设计：Region的划分规则

知识点06：存储设计：Region内部存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PMqZdtFr-1616633798610)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317191716413.png)]

  • 问题：数据在Region的内部是如何存储的？
  • 分析
    • Table【逻辑】/ RegionServer【物理】
      • Region：分区层，根据rowkey判断属于哪个分区，就写入哪个Region
        • Store：存储层，对每个分区内部数据存储的划分，根据列族划分，一个列族就对应一个Store
          • 每个列族对应一个Store，不同列族的数据存储在不同的Store中
          • 如果一张表，有2个列族，这张表的region中就会有两个Store
          • 优点：划分不同的数据存储
          • 假设有100列，如果没有列族，100列存储在一起，想查询其中1列，最多会比较100次
          • 假设有100列，如果有两个列族，50列存储在一起，想查询某个列族中的某1列，最多比较51次
          • 先比较我要查询哪个Store，比较1次
    • Store中的存储
      • 一个MemStore：Region中的内存区域，会为每个Store分配一部分
        • 数据先读写MemStore
      • 0个或者多个StoreFile文件：Store中的数据文件，如果Memstore存储达到阈值，就会将内存数据写入HDFS
        • StoreFile：逻辑上属于Store的
          • 物理上存储在HDFS上：本质上存储的是HFILE：有序的二进制文件
  • 总结
    • RegionServer：Region存储在Regionserver中
      • Region：一张表有多个Region，根据Rowkey判断写入哪个region
        • 一个表中有多个列族，每个列族对应一个Store，一个region中有多个store
        • Store：根据列族判断写入哪个Store
          • memstore：内存区域
          • storefile：HDFS上的文件

知识点07：存储设计：HDFS中的存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fLHCvTK8-1616633798610)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317191754182.png)]

知识点08：热点问题：现象及原因

  • 现象：在某个时间段内，大量的读写请求全部集中在某个Region中，导致这台RegionServer的负载比较高，其他的Region和RegionServer比较空闲
  • 问题：这台RegionServer故障的概率就会增加，整体性能降低，效率比较差
  • 原因：本质上的原因，数据分配不均衡
    • 情况一：如果这张表只有一个分区
      • region0：-oo ~ oo
      • 所有数据都是读写这一个分区
      • 肯定会出现热点
    • 情况二：如果这张表有多个分区，如果你的Rowkey写入时是连续的
      • region0：-oo ~ 30
      • region1：30 ~ 70
      • region2：70 ~ oo
      • 写入的rowkey
        • 00000001
        • 00000002
        • 00000003
        • ……
        • 29999999：都在往Region0中写入
        • 30000000：开始写入region1
        • ……
        • 全部写region1
        • ……
      • 原因：region的设计是按照范围有序的，Rowkey也是有序的，连续的rowkey写入同一个region
  • 解决
    • 创建表的时候给定多个分区
    • Rowkey写入时不能是连续的

知识点09：分布式设计：预分区

知识点10：Hbase表设计：Rowkey设计

9】

代码语言：javascript复制
    0_1616124723000_user001_order001
    4_1616124723000_user002_order002
    9_1616124723000_user003_order003
    0_1616124723001_user001_order004
    0_1616124723002_user001_order005
    1_1616124723000_user001_order001
    ```

    - 缺点：每次查询时，挨个试，读的性能降低
  • 长度原则：Rowkey的长度不建议过长
    • 原则：能满足业务需求的情况下越短越好
    • 问题：如果rowkey越长，索引占用的空间越大，比较rowkey就越慢，性能就越差
      • rowkey在底层是冗余存储的
    • 建议：不超过100个字节
      • 如果超过100个字节，建议进行编码
        • 100位 =》 MD5 => 32位 、16位
  • 总结
    • 业务原则：保证前缀是最常用的查询字段
    • 唯一原则：每条rowkey表示一条数据
    • 组合原则：常用的查询条件作为Rowkey
    • 散列原则：rowkey构建不连续
    • 长度原则：满足业务需求越短越好
hbase TDSQLMySQL版 存储 分布式 大数据

0 人点赞