(H2与HBase)面向行or面向列的存储模型?
1. H2怎么存储pet表的记录?H2是一个Java SQL Database Engine,使用面向行(row-oriented)的存储模型(如果觉得拗口,就叫基于行(row-based)的存储模型吧)。
表元数据与表的记录分开,可以通过与INFORMATION_SCHEMA相关的系统表来查找元数据,
还可以通过JDBC的java.sql.DatabaseMetaData提供的相关API来查找。
H2内部的存储引擎使用页(Page)来组织数据,页的大小默认是2K,可通过参数PAGE_SIZE调整,
有8种不同的页:
DATA_LEAF
DATA_NODE
DATA_OVERFLOW
BTREE_LEAF
BTREE_NODE
FREE_LIST
STREAM_TRUNK
STREAM_DATA
本文只是说明H2怎么按行的方式来组织数据,所以只重点讲DATA_LEAF、DATA_NODE这两种页。
1. 1 DATA_LEAF页格式type 1 checksum 2 (程序代码中一般是先用0值占位,等写完一页后对此页的数据计算校验和再回填) parentPageId 4 (就是父DATA_NODE节点的ID) tableId 可变int (该页所属的表的ID) columnCount 可变int (该页所属的表有多少列) entryCount 2 (该页有多少条记录) entryCount个 key 可变long (如果表存在主键,并且是BYTE、SHORT、INT、LONG类型,这个key就是主键的值,否则为每行生成一个唯一的数值) offset 2 (该行在此页中的相对位置) entryCount个 columnValues 每一行记录从对应的offset位置开始存放,不同类型的字段会使用1个Byte来标识自己的格式 ======================================================
DATA_LEAF页并不存放表名、列名、列类型这些元数据
对于pet表中的三行记录放到一个DATA_LEAF页中会是这样(为了方便阅读未细化每一个字节,实际更复杂一些):
====================================================== type 17 (Page.TYPE_DATA_LEAF | Page.FLAG_LAST(当前只有一个页)) checksum 0x75CE (校验和计算比较复杂,也受当前pageId、pageType、pageSize影响) parentPageId 0 (就是父DATA_NODE节点的ID,0说明是root节点) tableId 14 (该页所属的表的ID) columnCount 5 (该页所属的表有多少列) entryCount 3 (该页有多少条记录) 1001, 2024, 1002, 2003, 1003, 1980 (其中1001、1002、1003是key,2024、2003、1980是offset) ( /* key:1001 */ 1001, Fluffy, Harold, cat, f) ( /* key:1002 */ 1002, Claws, Gwen, cat, m) ( /* key:1003 */ 1003, Buffy, Harold, dog, f) ======================================================
1. 2 DATA_NODE页格式
当某个DATA_LEAF页(page0)的大小超过pageSize时,会把它切掉一部分,得到一个新的DATA_LEAF页(page1),
page0从切割点开始往右的keys和记录被转到page1中,切割点左边的继续留在page0,
同时生成一个新的DATA_NODE页作为page0、page1的父节点。
DATA_NODE页格式
type 1 checksum 2 (程序代码中一般是先用0值占位,等写完一页后对些页的数据计算校验和再回填) parentPageId 4 (就是父DATA_NODE节点的ID) tableId 可变int (该页所属的表的ID) rowCountStored 4 entryCount 2 entryCount个 childPageId 4 key 可变long ======================================================
2. HBase怎么存储pet表的记录?
HBase使用面向列(column-oriented)的存储模型,不需要定义表的结构(schema-free),
可以随时动态添加新的列,理论上对于列的个数没有限制,
如果列很多,可以把相关的一组列归属到一个列族中(Column Family),充分发挥数据的聚合特性。
通过RowKey能把同一个或多个列族中的列关联起来,
HBase的RowKey和列族的组合有点类似于传统关系数据库中有外键引用关系的两个关联表,
但是只是型像神不想,HBase中两个不同列族是平等的,没有主从关系,只是通过RowKey把两者关联起来。
HBase的Data Block对应H2的DATA_LEAF,
HBase的Leaf Index Block对应H2的DATA_NODE,
2. 1 Data Block格式Data Block的格式有点复杂,如果不打算看代码可以不用关心的
每个block有一个33字节的头
===========================
前8个字节是表示block类型的MAGIC,对应org.apache.hadoop.hbase.io.hfile.BlockType的那些枚举常量名,
接着4个字节表示onDiskBytesWithHeader.length - HEADER_SIZE
接着4个字节表示uncompressedSizeWithoutHeader
接着8个字节表示prevOffset (前一个块的offset,比如,对于第一个块,那么它看到的prevOffset是-1,对于第二个块,是0)
接着1个字节表示checksumType code(默认是1: org.apache.hadoop.hbase.util.ChecksumType.CRC32)
接着4个字节表示bytesPerChecksum(默认16k,不能小于block头长度(头长度是33个字节))
最后4个字节表示onDiskDataSizeWithHeader
当不使用压缩时onDiskBytesWithHeader不包含checksums,
此时checksums放在onDiskChecksum中,
当使用压缩时checksums放在onDiskBytesWithHeader
checksums就是把onDiskBytesWithHeader中的所有字节以bytesPerChecksum个字节为单位求校验和,这个校验和用int(4字节)表示。
注意,在求校验和时,onDiskBytesWithHeader中还没有checksums
默认每个Data Block的大小是64K(头(33字节)不包含在内)(可以通过HColumnDescriptor.setBlocksize设置),
64K只是一个阀值,实际的块大小要比它大(取决于最后存入的KeyValue的大小),
比如上次存入的KeyValue导致块大小变成63K了,但是还没到64K,那么接着存入下一个KeyValue,如果此KeyValue有5K,
那么这个块的大小就变成了63+5=68K了。
=================================================================================
从这开始是重点:
Data Block的核心是一串KeyValue,
KeyValue的格式如下:
名称 字节数 说明 -------------------------------------------------------------------- keyLength 4 表示Key所占的总字节数 valueLength 4 表示Value所占的总字节数 rowKeyLength 2 表示rowKey所占的字节数 rowKey rowKeyLength rowKey columnFamilyLength 1 表示列族名称所占的字节数 columnFamily columnFamilyLength 列族名称 columnName columnNameLength 列名 timestamp 8 时间戳 type 1 Key类型,比如是新增(Put),还是删除(Delete) value valueLength 列值 -------------------------------------------------------------------- 表2.1
关于KeyValue更完整更详细的内容请看这里:
HBase HFile与Prefix Compression内部实现全解--KeyValue格式 2. 2 Data Block如何存下面这些记录?把id作为rowkey,其他列不动,另外HBase至少需要一个列族,假设列族名是"mycf",这三行记录会产生4*3=12个KeyValue,
存到Data Block会是这样,先按rowkey升序,rowkey相同的按列名升序排,
最后的布局类似这样(为了简化去掉了一些细节):
rowKey 列族名称 列名 时间戳, 列值 ==================================================== 1001 mycf name timestamp, Fluffy 1001 mycf owner timestamp, Harold 1001 mycf sex timestamp, f 1001 mycf species timestamp, cat 1002 mycf name timestamp, Claws 1002 mycf owner timestamp, Gwen 1002 mycf sex timestamp, m 1002 mycf species timestamp, cat 1003 mycf name timestamp, Buffy 1003 mycf owner timestamp, Harold 1003 mycf sex timestamp, f 1003 mycf species timestamp, dog ====================================================
==================================================== ( /* key:1001 */ 1001, Fluffy, Harold, cat, f) ( /* key:1002 */ 1002, Claws, Gwen, cat, m) ( /* key:1003 */ 1003, Buffy, Harold, dog, f) ======================================================
HBase的格式存在大量的冗余(比如rowKey、列族名称、列名、时间戳)之所以要这样做是为了水平扩展、文件合并切分更容易,
因为HBase把列名、列族名称这些元数据和列值合在一起了,所以在分区时只须简单按rowkey切分,
就能把所有数据都转移到另一台机器上,不需要像H2那样要考虑INFORMATION_SCHEMA中的元数据与表记录是否同步的问题。
HBase基于LSM-Tree来存放KeyValue,H2基于类B+Tree的结构,
LSM-Tree只允许一次性添加,不需要考虑结点的删除修改,
数据会先写到内存(MemStore),然后内存满了就flush到硬盘变成一棵小LSM-Tree,
多棵LSM-Tree会定期合并成一棵更大的LSM-Tree,大到一定程度再切分自动扩散到其他机器。
B+Tree对于行、列的添加、删除需要对结点进行调整,数据更新会出现overflow。
另外,观察上面两组数据,H2的方案只是把元数据抽出来放到别处了,然后通过表id把DATA_LEAF和元数据关联,
HBase 0.94可以使用前缀压缩的办法,把重复的东西提取出来,
如果把上面的两组数据分别串成一行,其实差别不大,只是HBase多了很多冗余信息而已,
把冗余信息清除一部份我看不出row-oriented和column-oriented有什么本质区别,至少HBase与H2是有点相似的。
反而差异最大的是:
1) LSM-Tree与B+Tree
2) 是否是schema-free的
(以下内容不重要)
2. 3 leaf索引块的格式:数据块总个数N(int类型,4字节)
N个"数据块在此索引块中的相对位置"(从0开始,根据每个Entry的大小累加,每个相对位置是int类型,4字节)
N个Entry的总字节数(int类型,4字节)
N个Entry {
数据块在文件中的相对位置(long类型,8字节)
数据块的总长度(包括头) (int类型,4字节)
数据块第一个KeyValue中的Key字节数组
}
2. 4 root索引块的格式:N个leaf索引块Entry {
leaf索引块在文件中的相对位置(long类型,8字节)
leaf索引块的总长度(包括头) (int类型,4字节)
leaf索引块第一个Entry的Key字节数组
}
2. 5 IntermediateLevel索引块与leaf索引块类似,只不过它的Entry在第一层IntermediateLevel是leaf索引块Entry,
第二层以后是 IntermediateLevel块的entry。
查找key的顺序
root索引块 == IntermediateLevel索引块 == leaf索引块 == 数据块
阿里云HBase发布冷存储特性,助你不改代码,1/3成本轻松搞定冷数据处理 9月27日,阿里云HBase发布了冷存储特性。用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间,并通过建表语句指定将冷数据存放在冷存储介质上面,从而降低存储成本。冷存储的存储成本仅为高效云盘的1/3,适用于数据归档、访问频率较低的历史数据等各种场景。
【干货合集】NoSQL技术体系深度解读系列(三):HBase,海量数据存储、超高并发量场景下的NoSQL利器 在2018年开年NoSQL数据库直播大讲堂峰会即将召开之际,云栖社区特收集整理了一批优秀的技术博客,希望能够对大家探究、学习NoSQL体系中的HBase技术的原理及实践经验有所帮助。
HBase存储剖析与数据迁移 1.概述 HBase的存储结构和关系型数据库不一样,HBase面向半结构化数据进行存储。所以,对于结构化的SQL语言查询,HBase自身并没有接口支持。在大数据应用中,虽然也有SQL查询引擎可以查询HBase,比如Phoenix、Drill这类。
第十二届 BigData NoSQL Meetup — 基于hbase的New sql落地实践 立即下载
相关文章
- Hive集成HBase详解
- 【华为云技术分享】HBase与AI/用户画像/推荐系统的结合:CloudTable标签索引特性介绍
- 高可用Hadoop平台-HBase集群搭建
- HBase数据模型剖析
- 转两次hbase丢失数据的故障及原因分析--hbase split过程
- 大叔问题定位分享(50)hbase有一个region一直处于rit状态(非超时)
- 大叔经验分享(3)hbase client 如何选择
- hbase源码系列(十五)终结篇&Scan续集-->如何查询出来下一个KeyValue
- 大数据集群启停shell脚本:hadoop(hdfs、yarn)、hbase集群启停
- HBase存储相关概念
- hdfs yarn hbase pid文件被删除解决办法:修改hadoop-daemon.sh yarn-daemon.sh hbase-daemon.sh中PID_DIR存储路径
- linux安装phoenix 5.1.0(对应hbase 2.2.6)
- 启动HBase抛出org.apache.hadoop.hbase.ClockOutOfSyncException异常:hmaster正常,节点hregionserver启动失败
- HBase 架构详解及数据读写流程
- 【图文详解】深入理解 Hbase 架构 Deep Into HBase Architecture
- 【图文详解】一文全面彻底搞懂HBase、LevelDB、RocksDB等NoSQL背后的存储原理:LSM-tree日志结构合并树...
- Hbase配置中出现的问题总结
- Hbase启动hbase shell运行命令报Class path contains multiple SLF4J bindings.错误
- 什么场景Hbase
- 揭秘FaceBook Puma演变及发展——FaceBook公司的实时数据分析平台是建立在Hadoop 和Hive的基础之上,这个根能立稳吗?hive又是sql的Map reduce任务拆分,底层还是依赖hbase和hdfs存储
- NoSQL四种——kv存储(memcache,Riak),列存储(Cassandra,Hbase),文档类(mongoDB,CouchDB),图数据库(neo4j)
- HBase底层存储原理——我靠,和cassandra本质上没有区别啊!都是kv 列存储,只是一个是p2p另一个是集中式而已!
- hbase_学习_HBase环境搭建(单机)
- HBase选择Store file做compaction的算法
- Hbase常见异常hbase:meta,,1.1588230740 is NOT online; state={1588230740 state=OPEN, ts=162