Hbase简介:
hadoop-database,hadoop领域中的数据库.是一个高可靠,高性能,面向列的,可伸缩(非常容易的加一些计算节点)的分布式的存储管理系统.
在廉价的pc server上搭建起大规模结构化存储集群,和hadoop非常相似,Hbase是利用Hadoop的hdfs作为其文件存储系统,利用hadoop MapReduce 来处理Hbase的海量数据,利用zookeeper作为协调工具.
可伸缩:
原来的时候关系型数据库装在一台主机上,后来随着数据量的增加,数据库存储的数据越来越多,可能单机存不下了,这时候咱们期望使用另外一台服务器来进行扩展,目前的mysql,oracle最容易做的就是在另一台服务器上再重新部署一个数据库,然后让另外一个数据库存储一部分数据,这个数据库存储一部分数据,两个数据库存储的可能是不同的数据,这种解决方案就是通常所说的分库.这种解决方案的缺点:数据分到另个数据库中,用户在进行操作的时候,必须清楚的知道数据到底是在哪一个数据库中,需要去改客户端的应用,现在的mysql和oracle也有一部分分布式的特征,主从式的数据库搭建方式.但是,并不能实际的扩展的那么好,因为关系型数据库在刚刚产生的时候,只在单机上做,现在随着应用的发展,单机上满足不了.所以需要在原来的基础上进行分布式的部署,发展不是那么快,并且部署起来也不是那么麻烦.可伸缩,对于mysql和oracle而言还是具有优势的.
面向列:
关系型数据库中,数据的存储都是按行进行存储的,关系型数据库的建立是基于关系代数建立的,关系代数最基本的单位就是关系,非常的自然,按行存储的缺点:如果我们的应用在小规模数据下,一个表有几百万甚至上千万是没什么事的,这种情况下无论怎么折腾都没问题的,如果我们的这个表很大,一个是记录条数多,一个是列字段数比较多,对于前端响应的数据表,数据库字段设计的不是很多,并且记录条数也不是很多,原因就是加快前端的响应速度.有很多的这样的小表,但是没有一个统一的全局的认知,我们在做一些金融分析系统,或者是商业智能的时候,数据仓库的时候,会把很多的这种表合成一个大表,鉴于关系型数据库的特点,我们在建表的时候,通常都是建的都是一些宽表(字段数多),建宽表的目的就是为了避免表连接,因为表连接这个操作效率挺低的,宁可查单张表,不做表连接,所以我们在做数据分析的时候直接查单表就可以了,省去了表连接了,企业中一个解决方案.
宽表和hbase:假如宽表有一百多个字段,但是每次查询(作分析)的时候,我们只是取里面一部分的字段,我们的这种关系型数据库,在存储的时候按行存,也是按行取,我们在设计这种关系型表的时候,要告诉数据库要指明这个表有多少个字段,每个字段分别是什么类型,每个类型分别是多大多小,意思是,我们在建表的时候,一下子就把这一行所占的空间给指明了,因为我们要确定有多少列,每个字段分别是什么类型,多大,所以就把这一行的空间给确定了,那么在这个时候我们在进行快速访问的时候,会根据我们的地址一下子往前跳一个距离读写的顺序是与数据的大小是没有关系的,是线性的时间复杂度,对于查询速度而言是最好的.
行式存储的特点:耗内存,磁盘IO读写效率比较低,对于稀疏数据,对于磁盘空间的利用率比较低.
列式存储简单的讲是数据是按列进行存的.常用的一些列,我们单独放到一个文件中,不经常的,我们单独放到一个文件中存储.
在进行数据存储的时候,有一个主键,对应两边的记录.
列式存储主要是用来处理海量数据的,数据最少要过几十G或者是上百G,才能产生性能优势,列式数据库在小估摸数据处理的时候,比关系型数据库要慢.
Hbase处理完之后的数据直接返回客户端,而不是直接返回mysql这样的数据库,因为我们使用Hbase处理的时候一般都是olt这种事务性的操作.
应用场景:擅长处理海量数据.还适合处理表字段很多的这个情况.
Hbase数据模型:
逻辑数据模型:
关系型数据库中我们看到的表,是由列和行组成,看到的这种结构就是一种逻辑视图,是呈现给用户的,实际上在进行底层数据存储的时候按行存储的,一行一行存的,但是用户看到的就是一个二维表.
物理数据模型:
相当于表中一行行的记录.
Hbase中有一个行健row key:决定了分布在两个文件中的这些记录,哪些是属于同一条记录,
数据在进行存储的时候有列簇(column 列的集合),也就是和说一个存储文件是一个列簇,在列簇中存放的具体记录是通过row key连接到一起的.
在表示Hbase这种结构的时候,列簇和列的写法是非常重要的, : 前面是列簇,后面是列,一个列簇和row key 对应的记录有好几个,每一条记录都带有一个时间戳,读的时候根据时间戳区分,时间戳(time stamp) 一般都是当做版本来用.
数据在进行存储的时候,有行健(row key),列(column),和时间戳(time stamp)三个元素才能具体确定一条记录的值.
数据库一张表是由很多行组成的,行在进行物理存储的时候,都是按行健row key排过序的,在进行存储的时候,是一些二进制的字节数组,按行健进行排序然后进行存储的,关系型数据库存储的顺序是按插入顺序为准的.
如果只是根据行健进行查询,好处并不是很大.在hbase中,排序能够方便范围查询,还有利于组织Hbase的体系结构.
根据行健取出一条记录,每一条记录由很多的列簇组成,列簇后面有一列两列三列四列.
Hbase数据存储:
Hbase适合于存储海量数据,数据处理也比较快,因为数据存储是按列存储的.一些列会放到一个文件中进行存储,当你的记录超级多,几十个G的时候,那么我们一列上的这个文件也是会非常大的,只要文件很大了,在进行数据读写的时候,效率必然会低,和存储结构没有关系.
Table在行的方向上,分割为多个Region,一个region由(startKey,endKey)组成,每一个Region分散在不同的RegionServer中.
表有很多的行健,行健又是经过物理排序的,就是根据行健的开始和结束的位置,来表示一个region,也就是我们一个表被横向的切分成了很多的区域.我们的数据即便是按照列簇进行存储的时候,依然被划分到不同的region,当我们把数据按照这样进行划分之后进行访问的时候,就可以只打开一个小文件了,不需要打开一个大文件了,执行速度会稍微快一点.
把行分隔为多个region在关系型数据库中解决的方式叫做分表,分表的方法叫做横向分表,把一个表拆分成很多小表,一个小表存放一部分的数据.因为我们是按照字段进行划分的,每一个小表的的字段是不变的,这种切分方式叫做横向的分表.横向切表的好处,会提高单表的访问速度,并且还会提高并发,region的划分和横向分表很相像.
我们的数据只要分散到RegionServer中,数据就会被分散到了不同的服务器上了,数据只要可以分散存储,就可以实现海量存储,数据是分散查询的,所以我们在查询的时候,就可以在我们的服务器上分别进行查询,这样就实现了一个分布式计算.
Hbase最大的优点:
切分成Region,分散到不同的RegionServer中,Hbase能够实现海量数据查询也是源于此.
Hbase高效的原因:
(分布式)查询时在不同的RegionServer上进行的,这种查询方式就叫做并行计算.
体系结构:
主从式结构,主节点叫做Master,运行时表现为HMaster,还有一个从节点叫RegionServer,RegionServer主要存放Region,Master就是一个管理节点, Master就是用来管理.
Hbase也是分为客户端主节点,从节点这样的结构.
zookeeper:
实现了HMaster的一个动态切换,因为HMaster主要进行一些绝密性的工作,因为我们的HMaste一旦宕机,就会产生一些绝密性的问题,可以使用zookeeper来实现多个HMaster存在,但是只有一个HMaster在运行的这样一个状态.还可以存贮所有region的寻址入口.
客户端访问的时候通过HBaseAPI,会经过HBase集群,有一个主节点HMaster,和很多的从节点RegionServer节点,RegionServer中有很多的Region,每一个Region里面存放着很多的列,
大体上是从我们的客户端访问我们的主节点,通过主节点来访问我们的从节点,在Hbase中,主节点叫Master,从节点叫RegionServer.
HBase中有两张特殊的系统Table,-ROOT-,.MATA.
我们的Hbase是存储海量数据,有几百上亿条数据,这些数据是分散存储在多个Region中,Region又存放在RegionServer中,所以数据是特别的分散,我们在查找的时候就非常慢.
-MATA-:
索引表,存放用户所有的region信息,元数据..MATA.可以有多个region
-ROOT-:
相当于-MATA-的索引表,记录了.MATA.表的Region信息,-ROOT-只有一个Region.
用户在进行查询的时候,先找-ROOT-,通过-ROOT-再找.META.,通过-META-找到对应的region所在的regionserver,然后从regionserver中定位到这个region,读这个文件,或者向这个文件中写数据.
