HBASE的寻址机制和存储机制

2024-08-29 05:08
文章标签 存储 机制 hbase 寻址

本文主要是介绍HBASE的寻址机制和存储机制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

HBASE的寻址机制和存储机制

      • hbase的寻址机制
      • hbase的存储机制
        • hbase的存储机制:0.96及之前版本
        • hbase的寻址过程:0.96及之前版本
        • hbase的存储机制:0.96之后版本
        • hbase的寻址过程:0.96之后版本
        • 写机制
        • 读机制

hbase的寻址机制

  • hbase 的一个表最终拆分成 一个个region,每一个region可能会存储在不同的regionserver上,会有独立编号。
  • 无论是 读|写 操作,首先要快速定位到 写|读 是在哪一个region中进行,然后到对应的存储的regionserver上找对应的region,直接读取数据。

快速定位哪一个region存在哪一个regionServer上的过程,就叫寻址,要想知道寻址机制,需要先了解hbase的存储机制。

hbase的存储机制

hbase的存储机制:0.96及之前版本
  • 原始表:存储原始数据的
  • .meta表: 原始表 按照rowkey 创建索引,是原始表的索引目录
  • -root-表:.meta表的索引表,是终极索引,无论多大,都只有一个region,不可分割
  • -root- 表的存储位置:zookeeper中,zk中存储的是hbase的寻址路径的开始。
hbase的寻址过程:0.96及之前版本
1)客户端先去访问zk,获取-root-表的存储regionserver位置,以及region编号。
2)访问 -root- 表的region,获取 .meta表对应的regionserver的region编号。
3)访问.meta表,需要查询的rk所在的region,获取原始数据的regionserver的region编号。
4)开始真正的访问对应的regionserver的region 表数据。 3个来回之后,才找到真正要访问的的regionServer和region表。
hbase的存储机制:0.96之后版本
  • 原始表:存储原始数据
  • .meta 表:存储原始数据的索引,. meta 无论多大,只存储在一个region上,不可分割,这个region也只会存储在一个regionserver上。
  • .meta表的寻址路径,也就是.meta表的位置,最终存储在zookeeper上。
hbase的寻址过程:0.96之后版本
1)客户端先去访问zk,获取.meta 表的存储regionserver位置以及region编号。
2)访问.meta 表的region,获取原始数据表对应的regionserver的region编号。
3)开始真正的访问对应的regionserver的region 表数据。(开始读取数据)0.96版本之后,对寻址做了优化,提升查询效率。

现在假设我们要从 user_info 里面寻找一条 RowKey 是 rk0001 的数据。那么我们应该遵循以下步骤:

  1. 从.META.表里面查询哪个 Region 包含这条数据。
  2. 获取管理这个 Region 的 RegionServer 地址。
  3. 连接这个 RegionServer,查找对应region,扫描region,查到这条数据。
    系统如何找到某个 RowKey (或者某个 RowKey range)所在的 region。
    bigtable 使用三层类似 B+树的结构来保存 region 位置。
    第一层是 zookeeper 里面保存的数据,它持有 root region 的位置。
    第二层 root region 是.META.表的第一个 region 其中保存了.META.表其它 region 的位置。通过root region,我们就可以访问.META.表的数据。
    第三层是.META.,它是一个特殊的表,保存了 hbase 中所有数据表的 region 位置信息。

说明:
1、root region 永远不会被 split,保证了最多需要三次跳转,就能定位到任意 region。 2、.META.表每行保存一个 region 的位置信息,rowkey 采用表名+表的最后一行编码而成。3、为了加快访问,.META.表的全部 region 都保存在内存中。4、client 会将查询过的位置信息保存缓存起来,缓存不会主动失效,因此如果 client 上的缓存全部失效,则需要进行最多 6 次网络来回,才能定位到正确的 region(其中三次用来发现缓存失效,另外三次用来获取位置信息)。

写机制

写数据包括 put 和 delete

  • 1、客户端根据 rowkey 经过3次往返(寻址机制)找到对应的 region 所在的 regionserver。
  • 2、client 向 regionserver 提交写请求。
  • 3、regionserver 找到目标 region。
  • 4、region 检查数据是否与 schema(表结构:表名-列族) 一致,如果一致,允许写入;如果不一致,直接返回,报错。
  • 5、如果客户端没有指定版本,则获取当前系统时间作为数据版本。如果给定时间版本,以客户端给定的为准。
  • 6、将更新写入 WAL log。
  • 7、将更新写入对应的store中的 Memstore。
  • 8、判断 Memstore 的是否需要 flush 为 Storefile 文件。
    当memstore 的文件大小达到阈值128M的时候,开始执行flush,形成多个storefile文件。
  • 9、当一个store中的storefile个数达到一定的阈值的时候就会触发compact 合并。
    • minor compact
      storefile个数达到一定阈值进行的合并叫:minor compact 小合并
      触发条件在 hbase-default.xml文件中已经配置了。
		<property><name>hbase.hstore.compactionThreshold</name><value>3</value><description>If more than this number of HStoreFiles in any one HStore(one HStoreFile is written per flush of memstore) then a compactionis run to rewrite all HStoreFiles files as one.  Larger numbersput off compaction but when it runs, it takes longer to complete.</description></property>当一个store中的stotrefile文件个数达到3个时候,触发这个 minor compact 操作。将多个(3个)storefile 合并为 1个storefile文件。

minor compact 没有任何逻辑操作的,只有物理操作。简单地将多个storefile的文件进行累加合并,只是在文件个数上减少了。数据不会执行真正的删除,将需要删除的数据打了标记。这个数据对客户端不可见。

    • major compact
      当达到一定的阈值的时候,进行major compact。
        <property><name>hbase.hregion.majorcompaction</name><value>604800000</value><description>The time (in miliseconds) between 'major' compactions of allHStoreFiles in a region.  Default: Set to 7 days.  Major compactions tend tohappen exactly when you need them least so enable them such that they run atoff-peak for your deploy; or, since this setting is on a periodicity that isunlikely to match your loading, run the compactions via an externalinvocation out of a cron job or some such.</description></property>默认7天触发一次。将7天的多个hfile,合并为一个hfile。执行逻辑操作。

major compact 进行数据的真正删除,将所有的需要删除的数据进行真正的合并并删除。真正需要删除的数据有:

     1)执行delete操作的数据。2)版本超过给定需要保存的版本的数据,过期版本数据。eg:数据最多保存2个版本,实际存了3个版本,那么第一个存入的数据就过期了。3)TTL (Time To Live)过期的数据。
  • 10、判断一个store中的所有文件的总大小是否达到region切分的标准。
  • 11、达到region切分的标准,就会region切分,hmaster 进行新的region的重新分配。

总结: 写数据流程:
Client 写入 -> 存入 MemStore,一直到 MemStore 满 -> Flush 成一个 StoreFile,直至增长到一定阈值 -> 触发 Compact 合并操作 -> 多个 StoreFile 合并成一个 StoreFile,同时进行版本合并和数据删除 -> 当 StoreFiles Compact 后,逐步形成越来越大的 StoreFile -> 单个 StoreFile大小超过一定阈值后,触发 Split 操作,把当前 Region Split 成 2 个 Region,Region 会下线,新 Split 出的 2 个孩子 Region 会被 HMaster 分配到相应的 HRegionServer 上,使得原先 1 个Region 的压力得以分流到 2 个 Region 上由此过程可知,HBase 只是增加数据,并不真正写入磁盘。增加数据、删除操作,是在 Compact 阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证 I/O 高性能

读机制

读数据包括 get | scan

  • 1)客户端根据 rowkey 经过3次往返(寻址机制)找到对应的 region 所在的 regionserver。
  • 2)客户端开始向对应的regionserver的region发送读数据的请求。
  • 3)客户端会先在region的对应的store的memstore(blockcache)中进行读取。
  • 4)如果memstore 中有数据,直接返回。
  • 5)如果没有数据,到hfile 文件中进行读取(磁盘读取)。

这篇关于HBASE的寻址机制和存储机制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1116931

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

【Tools】大模型中的自注意力机制

摇来摇去摇碎点点的金黄 伸手牵来一片梦的霞光 南方的小巷推开多情的门窗 年轻和我们歌唱 摇来摇去摇着温柔的阳光 轻轻托起一件梦的衣裳 古老的都市每天都改变模样                      🎵 方芳《摇太阳》 自注意力机制(Self-Attention)是一种在Transformer等大模型中经常使用的注意力机制。该机制通过对输入序列中的每个元素计算与其他元素之间的相似性,

如何通俗理解注意力机制?

1、注意力机制(Attention Mechanism)是机器学习和深度学习中一种模拟人类注意力的方法,用于提高模型在处理大量信息时的效率和效果。通俗地理解,它就像是在一堆信息中找到最重要的部分,把注意力集中在这些关键点上,从而更好地完成任务。以下是几个简单的比喻来帮助理解注意力机制: 2、寻找重点:想象一下,你在阅读一篇文章的时候,有些段落特别重要,你会特别注意这些段落,反复阅读,而对其他部分

速了解MySQL 数据库不同存储引擎

快速了解MySQL 数据库不同存储引擎 MySQL 提供了多种存储引擎,每种存储引擎都有其特定的特性和适用场景。了解这些存储引擎的特性,有助于在设计数据库时做出合理的选择。以下是 MySQL 中几种常用存储引擎的详细介绍。 1. InnoDB 特点: 事务支持:InnoDB 是一个支持 ACID(原子性、一致性、隔离性、持久性)事务的存储引擎。行级锁:使用行级锁来提高并发性,减少锁竞争

【Tools】大模型中的注意力机制

摇来摇去摇碎点点的金黄 伸手牵来一片梦的霞光 南方的小巷推开多情的门窗 年轻和我们歌唱 摇来摇去摇着温柔的阳光 轻轻托起一件梦的衣裳 古老的都市每天都改变模样                      🎵 方芳《摇太阳》 在大模型中,注意力机制是一种重要的技术,它被广泛应用于自然语言处理领域,特别是在机器翻译和语言模型中。 注意力机制的基本思想是通过计算输入序列中各个位置的权重,以确

FreeRTOS内部机制学习03(事件组内部机制)

文章目录 事件组使用的场景事件组的核心以及Set事件API做的事情事件组的特殊之处事件组为什么不关闭中断xEventGroupSetBitsFromISR内部是怎么做的? 事件组使用的场景 学校组织秋游,组长在等待: 张三:我到了 李四:我到了 王五:我到了 组长说:好,大家都到齐了,出发! 秋游回来第二天就要提交一篇心得报告,组长在焦急等待:张三、李四、王五谁先写好就交谁的