[转载] 详细讲解Hadoop中的简单数据库HBase
转载自http://www.csdn.net/article/2010-11-28/282614
数据模型
HBase数据库使用了和Bigtable非常相似的数据模型。用户在表格里存储许多数据行。每个数据行都包括一个可排序的关键字,和任意数目的列。表格是稀疏的,所以同一个表格里的行可能有非常不同的列,只要用户喜欢这样做。
列名是“<族名>:<标签>”形式,其中<族名>和<标签>可以是任意字符串。一个表格的<族名>集合(又叫“列族”集合)是固定的,除非你使用管理员权限来改变表格的列族。不过你可以在任何时候添加新的<标签>。HBase在磁盘上按照列族储存数据,所以一个列族里的所有项应该有相同的读/写方式。
写操作是行锁定的,你不能一次锁定多行。所有对行的写操作默认是原子的。
所有数据库更新操作都有时间戳。HBase对每个数据单元,只存储指定个数的最新版本。客户端可以查询“从某个时刻起的最新数据”,或者一次得到所有的数据版本。
概念模型
从概念上,一个表格是一些行的集合,每行包含一个行关键字(和一个可选的时间戳),和一些可能有数据的列(稀疏)。下面的例子很好的说明了问题:
物理模型
在概念上表格是一个稀疏的行/列矩阵,但是在物理上,它们按照列存储。这是我们的一个重要设计考虑。
上面“概念上的”表格在物理上的存储方式如下所示:
请大家注意,在上面的图中,没有存储空的单元格。所以查询时间戳为t8的“content:”将返回null,同样查询时间戳为t9,“anchor:”值为“my.look.ca”的项也返回null。
不过,如果没有指明时间戳,那么应该返回指定列的最新数据值,并且最新的值在表格里也时最先找到的,因为它们是按照时间排序的。所以,查询“contents:”而不指明时间戳,将返回t6时刻的数据;查询“anchor:”的“my.look.ca”而不指明时间戳,将返回t8时刻的数据。
例子
为了展示数据在磁盘上是怎么存储的,考虑下面的例子:
程序先写了行“[0-9]”,列“anchor:foo”;然后写了行“[0-9]”,列“anchor:bar”;最后又写了行“[0-9]”,列“anchor:foo”。当把memcache刷到磁盘并紧缩存储后,对应的文件可能如下形式:
注意,列“anchor:foo”存储了2次(但是时间戳不同),而且新时间戳排在前面(于是最新的总是最先找到)。
HRegion (Tablet)服务器
对用户来说,一个表格是是一些数据元组的集合,并按照行关键字排序。物理上,表格分为多个HRegion(也就是子表,tablet)。一个子表用它所属的表格名字和“首/尾”关键字对来标识。一个首/尾关键字为和的子表包含[,)范围内的行。整个表格由子表的集合构成,每个子表存储在适当的地方。
物理上所有数据存储在Hadoop的DFS上,由一些子表服务器来提供数据服务,通常一台计算机只运行一个子表服务器程序。一个子表某一时刻只由一个子表服务器管理。
当客户端要进行更新操作的时候,先连接有关的子表服务器,然后向子表提交变更。提交的数据添加到子表的HMemcache和子表服务器的HLog。HMemcache在内存中存储最近的更新,并作为cache服务。HLog是磁盘上的日志文件,记录所有的更新操作。客户端的commit()调用直到更新写入到HLog中后才返回。
提供服务时,子表先查HMemcache。如果没有,再查磁盘上的HStore。子表里的每个列族都对应一个HStore,而一个HStore又包括多个磁盘上的HStoreFile文件。每个HStoreFile都有类似B树的结构,允许快速的查找。
我们定期调用HRegion.flushcache(),把HMemcache的内容写到磁盘上HStore的文件里,这样给每个HStore都增加了一个新的HStoreFile。然后清空HMemcache,再在HLog里加入一个特殊的标记,表示对HMemcache进行了flush。
启动时,每个子表检查最后的flushcache()调用之后是否还有写操作在HLog里未应用。如果没有,那么子表里的所有数据就是磁盘上HStore文件里的数据;如果有,那么子表把HLog里的更新重新应用一遍,写到HMemcache里,然后调用flushcache()。最后子表会删除HLog并开始数据服务。
所以,调用flushcache()越少,工作量就越少,而HMemcache就要占用越多的内存空间,启动时HLog也需要越多的时间来恢复数据。如果调用flushcache()越频繁,HMemcache占用内存越少,HLog恢复数据时也越快,不过flushcache()的消耗费也需要考虑。
flushcache()调用会给每个HStore增加一个HStoreFile。从一个HStore里读取数据可能要访问它的所有HStoreFile。这是很耗时的,所以我们需要定时把多个HStoreFile合并成为一个HStoreFile,通过调用HStore.compact()来实现。
Google的Bigtable论文对主要紧缩和次要紧缩描述有些模糊,我们只注意到2件事:
1.一次flushcache()把所有的更新从内存写到磁盘里。通过flushcache(),我们把启动时的日志重建时间缩短到0。每次flushcache()都给每个HStore增加一个HStoreFile文件。
2.一次compact()把所有的HStoreFile变成一个。
和Bigtable不同的是,Hadoop的HBase可以把更新“提交”和“写入日志”的时间周期缩短为0(即“提交”就一定写到了日志里)。这并不难实现,只要它确实需要。
我们可以调用HRegion.closeAndMerge()把2个子表合并成一个。当前版本里2个子表都要处于“下线”状态来进行合并。
当一个子表大到超过了某个指定值,子表服务器就需要调用HRegion.closeAndSplit(),把它分割成2个新的子表。新子表上报给master,由master决定哪个子表服务器接管哪个子表。分割过程非常快,主要原因是新的子表只维护了到旧子表的HStoreFile的引用,一个引用HStoreFile的前半部分,另一个引用后半部分。当引用建立好了,旧子表标记为“下线”并继续存留,直到新子表的紧缩操作把对旧子表的引用全部清除掉时,旧子表才被删除。
总结:
1.客户端访问表格里的数据。
2.表格分成许多子表。
3.子表由子表服务器维护,客户端连接子表服务器来访问某子表关键字范围内的行数据。
4.子表又包括:
A.HMemcache,存储最近更新的内存缓冲
B.HLog,存储最近更新的日志
C.HStore,一群高效的磁盘文件。每个列族一个HStore。
HBase的Master服务器
每个子表服务器都维持与唯一主服务器的联系。主服务器告诉每个子表服务器应该装载哪些子表并进行服务。
主服务器维护子表服务器在任何时刻的活跃标记。如果主服务器和子表服务器间的连接超时了,那么:
A. 子表服务器“杀死”自己,并以一个空白状态重启。
B. 主服务器假定子表服务器已经“死”了,并把它的子表分配给其他子表服务器。
注意到这和Google的Bigtable不同,他们的子表服务器即使和主服务器的连接断掉了,还可以继续服务。我们必须把子表服务器和主服务器“绑”在一起,因为我们没有Bigtable那样的额外锁管理系统。在Bigtable里,主服务器负责分配子表,锁管理器(Chubby)保证子表服务器原子的访问子表。HBase只使用了一个核心来管理所有子表服务器:主服务器。
Bigtable这样做并没有什么问题。它们都依赖于一个核心的网络结构(HMaster或Chubby),只要核心还在运行,整个系统就能运行。也许Chubby还有些特殊的优点,不过这超过了HBase现在的目标范围。
当子表服务器向一个新的主服务器“报到”时,主服务器让每个子表服务器装载0个或几个子表。当子表服务器死掉了,主服务器把这些子表标记为“未分配”,然后尝试给别的子表服务器。
每个子表都用它所属的表格名字和关键字范围来标识。既然关键字范围是连续的,而且最开始和最后的关键字都是NULL,这样关键字范围只用首关键字来标识就够了。
不过情况并没这么简单。因为有merge()和split(),我们可能(暂时)会有2个完全不同的子表是同一个名字。如果系统在这个不幸的时刻挂掉了,2个子表可能同时存在于磁盘上,那么判定哪个子表“正确”的仲裁者就是元数据信息。为了区分同一个子表的不同版本,我们还给子表名字加上了唯一的region Id。
这样,我们的子表标识符最终的形式就是:表名+首关键字+region Id。下面是一个例子,表名字是hbaserepository,首关键字是w-nk5YNZ8TBb2uWFIRJo7V==,region Id是6890601455914043877,于是它的唯一标识符就是:
hbaserepository, w-nk5YNZ8TBb2uWFIRJo7V==,6890601455914043877
元数据表
我们也可以使用这种标识符作为不同子表的行标签。于是,子表的元数据就存储在另一个子表里。我们称这个映射子表标识符到物理子表服务器位置的表格为元数据表。
元数据表可能增长,并且可以分裂成多个子表。为了定位元数据表的各个部分,我们把所有元数据子表的元数据保存在根子表(ROOT table)里。根子表总是一个子表。
在启动时,主服务器立即扫描根子表(因为只有一个根子表,所以它的名字是硬编码的)。这样可能需要等待根子表分配到某个子表服务器上。
一旦根子表可用了,主服务器扫描它得到所有的元数据子表位置,然后主服务器扫描元数据表。同样,主服务器可能要等待所有的元数据子表都被分配到子表服务器上。
最后,当主服务器扫描完了元数据子表,它就知道了所有子表的位置,然后把这些子表分配到子表服务器上去。
主服务器在内存里维护当前可用的子表服务器集合。没有必要在磁盘上保存这些信息,因为主服务器挂掉了,整个系统也就挂掉了。
Bigtable与此不同,它在Google的分布式锁服务器Chubby里储存“子表”到“子表服务器”的映射信息。但我们把这些信息存储到元数据表里,因为Hadoop里没有等价Chubby的东西。
这样,元数据和根子表的每行“info:”列族包含3个成员:
1.Info:regioninfo包含一个序列化的HRegionInfo对象。
2.Info:server包含一个序列化的HServerAddress.toString()输出字符串。这个字符串可以用于HServerAddress的构造函数。
3.Info:startcode是一个序列化的long整数,由子表服务器启动的时候生成。子表服务器把这个整数发送给主服务器,主服务器判断元数据和根子表里的信息是否过时了。
所以,客户端只要知道了根子表的位置,就不用连接主服务器了。主服务器的负载相对很小:它处理超时的子表服务器,启动时扫描根子表和元数据子表,和提供根子表的位置(还有各个子表服务器间的负载均衡)。
HBase的客户端则相当复杂,并且经常需要结合根子表和元数据子表来满足用户扫描某个表格的需求。如果某个子表服务器挂了,或者本来应该在它上面的子表不见了,客户端只能等待和重试。在启动的时候,或最近有子表服务器挂掉的时候,子表到子表服务器的映射信息很可能不正确。
结论:
1.子表服务器提供对子表的访问,一个子表只由一个子表服务器管理。
2.子表服务器需要向主服务器“报到”。
3.如果主服务器挂了,整个系统就挂了。
4.只有主服务器知道当前的子表服务器集合。
5.子表到子表服务器的映射存储在2种特殊的子表里,它们和其他子表一样被分配到子表服务器上。
6.根子表是特殊的,主服务器总是知道它的位置。
7.整合这些东西是客户端的任务。
[转载] 详细讲解Hadoop中的简单数据库HBase的更多相关文章
- 详细讲解nodejs中使用socket的私聊的方式
详细讲解nodejs中使用socket的私聊的方式 在上一次我使用nodejs+express+socketio+mysql搭建聊天室,这基本上就是从socket.io的官网上的一份教程式复制学习,然 ...
- 第五节:详细讲解Java中的接口与继承
前言 大家好,给大家带来详细讲解Java中的接口与继承的概述,希望你们喜欢 什么是接口(interface) 接口中的方法都是抽象方法,public权限,全是抽象函数,不能生成对象 interface ...
- 第四节:详细讲解Java中的类和面向对象思想
前言 大家好,给大家带来详细讲解Java中的类和面向对象思想的概述,希望你们喜欢 类和面向对象 在Java中怎样理解对象,创建对象和引用:什么是引用,对于基础学习的同学,要深入了解引用.示例:Stri ...
- 第九节:详细讲解Java中的泛型,多线程,网络编程
前言 大家好,给大家带来详细讲解Java中的泛型,多线程,网络编程的概述,希望你们喜欢 泛型 泛型格式:ArrayList list= new ArrayList(); ArrayList list= ...
- 第八节:详细讲解Java中的异常处理情况与I/O流的介绍以及类集合框架
前言 大家好,给大家带来详细讲解Java中的异常处理情况与I/O流的介绍以及类集合框架的概述,希望你们喜欢 JAVA 异常 try...catch...finally结构的使用方法 class Tes ...
- 第七节:详细讲解Java中的日期,java.util.date
前言 大家好,给大家带来详细讲解Java中的日期,java.util.date的概述,希望你们喜欢 类Date Java.lang.Object->java.util.Date public c ...
- 第六节:详细讲解Java中的装箱与拆箱及其字符串
前言 大家好,给大家带来详细讲解Java中的装箱与拆箱及其字符串的概述,希望你们喜欢 装箱与拆箱 封装类有:Byte , short , Integer , Character , long , Fl ...
- 详细讲解Hadoop源码阅读工程(以hadoop-2.6.0-src.tar.gz和hadoop-2.6.0-cdh5.4.5-src.tar.gz为代表)
首先,说的是,本人到现在为止,已经玩过. 对于,这样的软件,博友,可以去看我博客的相关博文.在此,不一一赘述! Eclipse *版本 Eclipse *下载 Jd ...
- 转载: 查看HADOOP中一个文件有多少块组成及所在机器ip
看文件信息 hadoop fsck /user/filename 更详细的 hadoop fsck /user/filename -files -blocks -locations -racks ...
随机推荐
- python中ConfigParse模块的用法
ConfigParser 是Python自带的模块, 用来读写配置文件, 用法及其简单. 配置文件的格式是: [...]包含的叫section section 下有option=value这样的键值 ...
- opencv-python:win7下,搭建python2.7.5环境,配置opencv3.1.0准备开工-OpenCV步步精深
我的个人博客:点这里 搭建python2.7.5环境 下载python2.7.5 64位:https://www.python.org/ftp/python/2.7.5/python-2.7.5.am ...
- DevOps之内容分发网络CDN
唠叨话 关于德语噢屁事的知识点,仅提供专业性的精华汇总,具体知识点细节,参考教程网址,如需帮助,请留言. <内容分发网络CDN(Content Delivery Network)> 关于虚 ...
- EF框架搭建小总结--ModelFirst模型优先
前言:去年刚工作的时候,也是刚刚正式接触.net,当时了解了EF以及三种开发模式,Database First.Model First .Code First.公司用的开发模式是Database Fi ...
- 干货|人人都是翻译项目的Master
在平时的工作中,我们都会经常查阅一些英文文档来解决平时遇到的问题和拓宽视野.看到好的文章或者书籍有没有想要和小伙伴分享的冲动,那么我们一起来翻译吧- 翻译主张 "信 达 雅" .& ...
- vim下单行长文本的时候卡顿解决办法
在vim编辑文件时,若单行过长,可能会导致vim卡顿,严重影响使用体验 估计是syntax匹配效率过滥导致.. 偶尔发现了一个临时的解决办法就是关掉syntax然后再打开,即在命令模式下 :synta ...
- linux 生成随机密码和wordlist常用方法
注:文章内容来自网络收集 关于下面这10个方法,估计很多人也知道了,这里也是为了自己以后用收集一下,不过顺便吐槽下,google第一页,只要是“linux 随机密码”这几个类似的关键字,蹦出来的全特么 ...
- 217. Contains Duplicate (leetcode)
Given an array of integers, find if the array contains any duplicates. Your function should return t ...
- Hibernate 一对一双向映射 注解方式
有外键的一方: @OneToOne(fetch = FetchType.LAZY) @JoinColumn(name = "courseid") public Tcourse ge ...
- LeetCode 243. Shortest Word Distance (最短单词距离)$
Given a list of words and two words word1 and word2, return the shortest distance between these two ...