第五章非关系型数据库.ppt

《第五章非关系型数据库.ppt》由会员分享，可在线阅读，更多相关《第五章非关系型数据库.ppt（107页珍藏版）》请在三一文库上搜索。

1、1,Cloud Computing,Autumn, 2011,Chapter 5 NoSQL Database Xu Jungang,1,2,2019/7/13,Cloud Computing, GUCAS,2,提纲,1. 关系数据库的瓶颈 2. 云计算对数据库技术的要求 3. NoSQL数据库 4. BigTable 5. HBase,3,3,关系数据库的产生,1970年IBM研究员Edgar Frank Codd发表了业界第一篇关于关系数据库理论的论文A Relational Model of Data for Large Shared Data Banks，首次提出了关系模型的概念。 后

2、来Codd又陆续发表多篇文章，奠定了关系数据库的基础。关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于理解和使用。,4,关系型数据库的概念,关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。 SQL是一种基于关系数据库的语言，这种语言执行对关系数据库中数据的检索和操作。 关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。,4,5,关系操作,关系模块中常用的操作包括：,5,6,关系型数据库的优点,操作方便：通过应用程序和后台连接，方便了用户对数据的操作，特别是没有

3、编程基础的人。 易于维护 ：丰富的完整性，包括实体完整性、参照完整性和用户定义完整性，大大降低了数据冗余和数据不一致的概率 。 便于访问数据：提供了诸如视图，存储过程，触发器，索引等对象。 更安全，更快捷 ：权限分配和管理，使其较以往的数据库在安全性上要高的多，,6,7,关系型数据库的瓶颈,（1）关系数据库所采用的二维表格数据模型不能有效地处理多维数据，不能有效处理互联网应用中半结构化和非结构化的海量数据，如Web页面、电子邮件、音频、视频等,7,8,关系型数据库的瓶颈,（2）高并发读写的性能低 关系数据库达到一定规模时，非常容易发生死锁等并发问题，导致其读写性能下降非常严重。 Web2.0网

4、站数据库并发负载非常高，往往要达到每秒上万次读写请求。 关系型数据库勉强可以应付上万次SQL查询，但硬盘I/O往往无法承担上万次的SQL写数据请求。,8,9,关系型数据库的瓶颈,查询效率低,各种等待,10,关系型数据库的瓶颈,（3）支撑容量有限 类似人人网，新浪微博，Facebook，Twitter，Friendfeed（已被Facebook收购）这样的网站，每天用户产生海量的用户动态信息。 （a）以Facebook为例，一个月就要存储1350亿条（未得到确认）用户动态，对于关系数据库来说，在一张1350亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。 （b）再例如大型Web网站

5、或IM的用户登录系统，例如腾讯，MSN，动辄数以亿计的帐号，关系数据库也很难应付。,11,关系型数据库的瓶颈,（4）数据库的可扩展性和可用性低 当一个应用系统的用户量和访问量与日俱增的时候，传统的关系型数据库却没有办法像Web Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。 对于很多需要提供不间断服务的系统来说，对数据库系统进行升级和扩展往往需要停机维护和数据迁移,12,关系型数据库的瓶颈,13,关系型数据库的瓶颈,（5）建设和运维成本高 企业级关系数据库的价格很高，并且随着系统的规模增大而不断上升。 高昂的建设和运维成本无法满足云计算应用对数据库的需求。,14,20

6、19/7/13,Cloud Computing, GUCAS,14,提纲,1. 关系数据库的瓶颈 2. 云计算对数据库技术的要求 3. NoSQL数据库 4. BigTable 5. HBase,15,大量Web 2.0网站,16,大量Web 2.0网站,17,Types of Cloud Service Provider 云服务提供商类型,SaaS Software as a Service 软件即服务,PaaS Platform as a Service 平台即服务,IaaS Infrastructure as a Service 基础设施即服务,18,AaaS Architecture

7、as a Service BaaS Business as a Service CaaS Computing as a Service DaaS Data as a Service DBaaS Database as a Service EaaS Ethernet as a Service FaaS Frameworks as a Service GaaS Globalization or Governance as a Service HaaS Hardware as a Service IMaaS Information as a Service IaaS Infrastructure o

8、r Integration as a Service IDaaS Identity as a Service LaaS Lending as a Service MaaS Mashups as a Service OaaS Organization or Operations as a Service SaaS Software or Storage as a Service PaaS Platform as a Service TaaS Technology or Testing as a Service VaaS Voice as a Service,Everything as a Ser

9、vice任何事物都是一种服务,引用自： https:/ 客户导向,19,云计算对数据库技术的需求,海量数据处理：需要能够处理PB级的数据。 大规模集群管理：分布式应用可以更加简单地部署、应用和管理。 低延迟读写速度：快速的响应速度能够极大地提高用户的满意度。 较低的建设及运营成本：云计算应用的基本要求是希望在硬件成本、软件成本以及人力成本方面都有大幅度的降低。,20,2019/7/13,Cloud Computing, GUCAS,20,提纲,1. 关系数据库的瓶颈 2. 云计算对数据库技术的要求 3. NoSQL数据库 4. BigTable 5. HBase,21,What is NoSQ

10、L?,In computing, NoSQL (sometimes expanded to “not only SQL“) is a broad class of database management systems that differ from classic relational database management systems (RDBMSes) in some significant ways. These data stores may not require fixed table schemas, usually avoid join operations, and

11、typically scale horizontallyWikipedia NoSQL是一种与关系型数据库管理系统截然不同的数据库管理系统，它的数据存储格式可以是松散的、通常不支持Join操作并且易于横向扩展。也可以称之为非关系型数据库。,22,关系型数据库,NoSQL,An Example of NoSQL,23,SQL PK NoSQL,SQL NoSQL - 重量级 轻量级 贵 便宜 商业 开源 成熟 时尚、风险 企业通用 特定领域、互联网,24,Availability 可用性,Partition Tolerance 分区容错性,Consistency 一致性,RDBMS,NoSQL,

12、数据一致更新，所有 数据变动都是同步的,尽管有一些信息丢失 ，系统依旧继续运转,某个节点的宕机不会影 响其他节点继续完成操 作,CAP理论,25,CAP理论,Consistency(一致性): 数据一致更新，所有数据变动都是同步的 Availability(可用性):某个节点的宕机不会影响其他节点继续完成操作 Partition tolerance(分区容错性):尽管有一些信息丢失，系统依旧继续运转可靠性,定理：一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。,忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。,26,关系数据

13、库的ACID特性,Atomicity（原子性）：一个事务中所有操作都必须全部完成，要么全部不完成。 Consistency（一致性）： 在事务开始或结束时，数据库应该在一致状态。 Isolation（隔离性）： 事务将假定只有它自己在操作数据库，彼此不知晓。 Durability（持久性）：一旦事务完成，就不能返回。 跨数据库事务：两阶段提交协议（Two-phase commit，2PC）,结论：关系型数据库通过把更新操作写到事务型日志里实现了较高的可靠性，但带来的是写性能的下降,27,BASE模式,BASE模型是反ACID模型，完全不同于ACID模型，牺牲高一致性，获得可用性或可靠性： Ba

14、sically Available（基本可用）：支持分区失败。 Soft state（软状态）：状态可以有一段时间不同步。 Eventually consistent（最终一致）：最终数据是一致的就可以了，而不是时时高一致。,BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲,28,Web 1.0时代,Web 2.0时代,29,Why NoSQL?,对于Web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。例如： 1. 数据库事务一致性需求: 很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求

15、也不高。因此数据库事务管理成了数据库高负载之外另一个沉重的负担。 2. 数据库的写实时性和读实时性需求: 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多Web应用来说，并不要求这么高的实时性，比方说某人发一条消息之后，过几秒乃至十几秒之后，他的订阅者才看到这条动态信息是完全可以接受的。,30,关系数据库适合这样的场景？,对于Web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。例如： 3. 对复杂的SQL查询，特别是多表关联查询的需求: （1）任何大数据量的Web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。 （

16、2）特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。 因此，关系数据库在这些越来越多的应用场景下显得就不那么合适了。,31,NoSQL的优势和劣势,优势 扩展简单 读写快速 成本低廉,劣势 不提供对SQL支持 产品不够成熟 很难实现数据的完整性。 缺乏强有力的技术支持。 开源数据库从出现到用户接受需要一个漫长的过程。,32,NoSQL分类（按功能）,Column-oriented：列式存储，通常不支持join操作，与传统关系型数据库的行式存储相比他的存储是列式的，这样会让很多统计聚合操

17、作更简单方便。 Key/Value：有点类似常见的HashTable，一个Key对应一个Value，但是它能提供非常快的查询速度、大的数据存放量和高并发操作，非常适合通过主键对数据进行查询和修改等操作。 Document-oriented：Document和Key/value是非常相似的，也是一个Key对应一个Value，但是这个Value主要以JSON（JavaScript Object Notations）或者XML等格式的文档来进行存储。这种存储方式可以很容易地被面向对象的语言所使用。,33,Column-oriented Vertica BigTable Hypertable HBas

18、e Cassandra,NoSQL分类（按功能）,34,Key-Value Redis Scalaris MemcacheDB Berkeley DB Dynamo Voldemort Tokyo Cabinet KAI,NoSQL分类（按功能）,35,Document-oriented MongoDB Terrastore CouchDB SimpleDB Riak,NoSQL分类（按功能）,36,按CAP的组合分类,满足C和A的系统，通常在可扩展性上不太强大： Traditional RDBMSs like Postgres, MySQL, etc (relational) Vertica

19、 (column-oriented) Aster Data (relational) Greenplum (relational),37,按CAP的组合分类,满足C和P的系统，通常性能不是特别高: BigTable (column-oriented/tabular) Hypertable (column-oriented/tabular) HBase (column-oriented/tabular) MongoDB (document-oriented) Terrastore (document-oriented) Redis (key-value) Scalaris (key-value)

20、 MemcacheDB (key-value) Berkeley DB (key-value),38,按CAP的组合分类,满足A和P的系统，通常可能对一致性要求低一些: Dynamo (key-value) Voldemort (key-value) Tokyo Cabinet (key-value) KAI (key-value) Cassandra (column-oriented/tabular) CouchDB (document-oriented) SimpleDB (document-oriented) Riak (document-oriented),39,Row Store a

21、nd Column Store,In row store data are stored in the disk tuple by tuple. Where in column store data are stored in the disk column by column,40,Row Store and Column Store,So column stores are suitable for read-mostly, read-intensive, large data repositories,41,列式数据库是革命性的,传统行式数据库,c5,c4,c3,c2,c1,c9,c8,

22、c7,c6,r1,r2,r3,r4,r5,列式数据库,c5,c4,c3,c2,c1,c9,c8,c7,c6,r1,r2,r3,r4,r5,数据按列存储 每一列单独存放 数据即是索引 只访问查询涉及的列 大量降低系统IO 每一列由一个线索来处理 查询的并发处理 数据类型一致，数据特征相似 方便压缩,数据是按行存储的 没有索引的查询使用大量I/O 建立索引和物化视图需要花费大量时间和资源 面对查询的需求，数据库必须被大量膨胀才能满足性能要求,42,Key/Value数据模型,域（Domain）+数据项（Item） 域类似于“表”，但无结构；作用是容纳所有的数据项 在同一个域中存储的数据项可以存在很

23、大的差异,42,43,Key/Value PK Relational Database,44,SQL PK API,关系数据库的数据创建、更新、删除和获取都使用SQL完成，SQL查询可以从单个表或是通过多个表的Join操作来获取数据，SQL查询包括聚集、复杂的数据过滤等功能，传统关系数据库还包括将一些数据处理逻辑嵌入到数据存储中的实现。例如存储过程、触发器等。 Key/Value数据的创建、更新、删除和获取都是用API方法调用。,44,45,Key/Value应用,Amazon Dynamo，Yahoo！PNUTS等均是使用Key/Value数据结构 同时也有一些Key/Value的变体，如G

24、oogle Bigtable，Facebook Cassandra，HyperTable等,45,46,Key/value的优缺点,优点 便于扩展，适用于云计算环境 与应用程序代码的兼容性更好 缺点 数据完整性约束移至应用程序 目前的很多Key/Value数据存储系统之间不兼容,47,Document oriented database,A document-oriented database is a computer program designed for storing, retrieving, and managing document-oriented, or semi struc

25、tured data, information. Document-oriented databases are one of the main categories of so-called NoSQL databases and the popularity of the term “document-oriented database“ (or “document store“) has grown with the use of the term NoSQL itself. Documents encodings include XML, YAML, JSON and BSON, as

26、 well as binary forms like PDF and Microsoft Office documents (MS Word, Excel, and so on).,48,Document oriented database,Documents are addressed in the database via a unique key that represents that document. this key is a simple string. In some cases, this string is a URI or path Retrieval Support

27、simple key-document (or key-value) lookup offer an API or query language that will allow you to retrieve documents based on their contents,49,An JSON Sample Doc, _id : ObjectId(“4c4ba5c0672c685e5e8aabf3“), author : “roger“, date : “Sat Jul 24 2010 19:47:11 GMT-0700 (PDT)“, text : ”MongoSF“, tags : ”

28、San Francisco“, ”MongoDB“ ,50,50,提纲,1. 关系数据库的瓶颈 2. 云计算对数据库技术的要求 3. NoSQL数据库 4. BigTable 5. HBase,2019/7/13,Cloud Computing, GUCAS,51,BigTable设计动机,从商业上考虑，Google不会把自己最宝贵的数据资源放在别家的数据库上，尤其是Oracle。 对商业数据库来说数据规模太大，即使能实现，花费也将会很高。 存储的数据种类多种多样，海量的服务请求，市面上的商用数据库无法满足Google存储和处理数据的需求 为了与GFS和MapReduce相配套，Google从

29、2004年初开始研发“大表”BigTable,以实现结构化数据的分布式存储,51,52,BigTable设计目标,面对以上几个方面的需求和考虑，Google便开始着眼于一种能够处理大规模数据的数据库系统，这就是BigTable。 Google设计实现的BigTable需要完成一下几个基本要求： 广泛的适用性: 满足Google不同产品 高可扩展性：根据需要随时扩容 高可用性：要保证几乎所有情况下系统都不能宕机,52,53,BigTable的提出,Google发表论文BigTable:A Distributed Storage System for Structured Data BigTabl

30、e是一种为了管理结构化数据而设计的分 布式存储系统，这些数据可以扩展到非常大的规模，例如在数千台商用服务器上的达到PB(Petabytes)规模的数据。,54,BigTable数据模型,BigTable本质上是一个稀疏的、分布式的、持久化存储的多维度排序Map(由key, value组成）。 每个BigTable Cell（单元格）的组成： 行（Row） 列（Column） 时间戳（Time Stamp） 通过它们进行三维定位，Cell的内容本身是一个字符串。,54,55, 分布式多维稀疏图. (行, 列, 时间戳) Cell内容 BigTable管理的数据的存储结构为：-string. Bi

31、gTable的基本元素是：行（row），列（column），子表（tablet）和时间戳（timestamp）。 对Google大多数应用良好匹配.,56,其中： Tablet是一段行的集合体 :BigTable中的数据项按照行关键字的字典序排列，每行动态地划分到tablet中，每个节点管理大约100个tablet。 时间戳是一个64位的整数，表示数据的不同版本。 列族是若干列的集合，BigTable中的存取权限控制在列族的粒度进行。,BigTable逻辑结构：,57,BigTable记录表&分解,10/19,58,11/19,BigTable记录表&分解,59,BigTable数据模型,行

32、BigTable的行可以是任意字符串（目前支持最多64K，多数情况下10-100字节）。 BigTable和传统的关系型数据库有很大不同，它不支持一般意义上的事务，但能保证在一个行关键字下的每一个读写操作都是原子操作（不管读写这一行里有多少个不同的列），即保证对于行的读写操作具有原子性（Atomic）。 表中数据都是根据行关键字进行排序的，排序使用的是字典顺序。,59,60,BigTable：数据模型,列 BigTable并不是简单 地存储所有的列关键字，而是将其组织成所谓的列族（Column Family） 列族是访问控制的基本单位，每个族中的数据都属于同一个类型，并且同族的数据会被压缩在一

33、起保存。 引入了列族的概念之后，列关键字就采用下述的语法规则来定义： (族名：限定词)（family：qualifier） 列族必须先创建，然后在其中的列关键字下存放数据；列族创建后，族中任何一个列关键字均可以使用。族名必须有意义，限定词则可以任意选定,60,61,BigTable：数据模型,时间戳 BigTable表中每一个表项都可以包含同一数据的多个版本，由时间戳来索引。 BigTable的时间戳是64位整型，可以由BigTable来赋值，表示准确的毫秒的“实时”，或者由用户应用程序来赋值。 需要避免冲突的应用程序必须自己产生具有唯一性的时间戳。不同版本的表项内容按时间戳倒序排列，即最近的

34、排序在前面。 为了简化对不同版本的数据管理，BigTable目前提供了两种设置：一种是保留最近的N个不同版本；另一种是保留限定时间内的所有不同版本，比如可以保存最近10天的所有不同版本数据。是旧的版本将会由BigTable的垃圾回收机制自动处理。,61,62,BigTable数据模型实例,假设我们想要存储海量的网页及相关信息表Webtable URL作行关键字，网页属性作为列名 行及行关键字、列、列族及列关键字、时间戳,63,通过反转URL中主机名的方式，可以把同一个域名下的网页聚集起来组织成连续的行。 具体来说，我们可以把 把相同的域（如)中的网页存储在连续的区域可以让基于主机和域名的分析更

35、加有效。,BigTable数据模型实例,64,BigTable系统架构,2019/7/13,Cloud Computing, GUCAS,64,65,BigTable组件,BigTable包括三个主要的组件：,2019/7/13,Cloud Computing, GUCAS,65,1,链接到客户程序中的库,2,1个Master服务器,3,多个Tablet服务器,66,Master Server,Master服务器主要负责以下工作： 为Tablet服务器分配Tablets 检测新加入的或者过期失效的Tablet服务器 对Tablet服务器进行负载均衡 对保存在GFS上的文件进行垃圾收集 除此之外

36、，它还处理对模式的相关修改操作，例如建立表和列族。,2019/7/13,Cloud Computing, GUCAS,66,67,Chubby的任务,Chubby,存储访问控制列表,确保在任何时间只有一个活动的master,存储Bigtable的模式信息,Tablet服务器失效时进行善后,存储Bigtable数据的 自引导指令的位置,查找Tablet服务器,68,主服务器启动的步骤,从Chubby中获取一个独占锁，确保同一时间只有一个主服务器 扫描服务器目录，发现目前活跃的tablet服务器 与所有的活跃tablet服务器取得联系以便了解所有tablet的分配情况 通过扫描元数据表（Metad

37、ata Table），发现未分配的tablet并将其分配到合适的tablet服务器。如果元数据表未分配，则首先需要将Root Tablet加入未分配的tablet中。由于Root Tablet保存了其他所有元数据tablet的信息，确保了扫描能够发现所有未分配的tablet,69,Tablet地址,tablet地址的查询时经常碰到的操作。在Bigtable系统的内部采用的是一种类似B+树的三层查询体系,70,Tablet的分配,2019/7/13,Cloud Computing, GUCAS,70,步骤1,步骤3,步骤2,Master服务器从Chubby获取一个唯一的Master锁，用来阻止创

38、建其它的Master服务器实例,步骤4,Master服务器扫描Chubby服务器文件锁存储目录，获取当前正在运行的tablet服务器列表,Master服务器和所有正在运行的Tablet服务器通信，获取每个Tablet服务器上的Tablet的分配信息,Master服务器扫描METADATA表获取所有的Tablet的集合。在扫描的过程中，当发现有没有被分配的Tablet,71,子表服务器（Tablet Server）,每个Tablet服务器都管理一个Tablet的集合（通常每个服务器有大约数十个至上千个Tablet）。 每个Tablet服务器负责处理它所加载的Tablet的读写操作，以及在Tabl

39、ets过大时，对其进行分割。 和很多Single-Master类型的分布式存储系统类似，客户端读取的数据都不经过Master服务器：客户程序直接和 Tablet服务器通信进行读写操作。,2019/7/13,Cloud Computing, GUCAS,71,72,子表服务器（Tablet Server）,由于BigTable的客户程序不必通过Master服务器来获取Tablet的位置信息，因此，大多数客户程序甚 至完全不需要和Master服务器通信。在实际应用中，Master服务器的负载是很轻的。 一个BigTable集群存储了很多表，每个表包含了一个Tablet的集合，而每个Tablet包含

40、了某个范围内的行的所有相关数据。 初始状态下，一个表只有一个Tablet。随着表中数据的增长，它被自动分割成多个Tablet，缺省情况下，每个Tablet的尺寸大约是100MB到 200MB。,2019/7/13,Cloud Computing, GUCAS,72,73,SSTable及子表基本结构,SSTable是Google为Bigtable设计的内部数据存储格式。 所有的SSTable文件都是存储在GFS上的，用户可以通过键来查询相应的值,74,SSTable结构,SStable中的数据被划分成一个个的块（Block），每个块的大小是可以设置的，一般设置为64KB 在SSTable的结尾

41、有一个索引（Index），这个索引保存了SSTable中块的位置信息，,SSTable结构,75,Tablet的组成,每个Tablet都是由多个SSTable以及日志（Log）文件构成的 BigTable中的日志文件是一种共享日志，也就是说系统并不是对tablet服务器上每个tablet都单独地建立一个日志文件，每个tablet服务器上仅保存一个日志文件。某个tablet日志只是这个共享日志的一个片段。,76,Tablet的实际组成,77,Typical Cluster,78,2019/7/13,Cloud Computing, GUCAS,78,提纲,1. 关系数据库的瓶颈 2. 云计算对数

42、据库技术的要求 3. NoSQL数据库 4. BigTable 5. HBase,79,Hbase:BigTable的开源实现,2019/7/13,Cloud Computing, GUCAS,79,Hbase数据库是基于Hadoop的项目，是对Google的BigTable的开源实现。 它与BigTable相似，但也存在很多不同之处。,80,实例：Facebook的HBase每月存储1350亿条信息,Cassandra,NO,NO,YES,81,HBase简介,2019/7/13,Cloud Computing, GUCAS,81,HBase is the Hadoop database.

43、Use it when you need random, realtime read/write access to your Big Data. This projects goal is the hosting of very large tables - billions of rows X millions of columns a top clusters of commodity hardware. HBase is an open-source, distributed, versioned, column-oriented store modeled after Google

44、Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, HBase provides Bigtable-like capabilities on top of Hadoop. HBase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时HBase还会对数据进行透明的切分，这样就使得存储本身具

45、有了水平伸缩性。,82,HBase系统架构,83,HBase数据模型,83,Hbase是一个类似Bigtable的分布式数据库，大部分特性和Bigtable一样，是一个稀疏的，长期存储的存在硬盘上，多维度的，排序的映射表。 这张表的索引是行关键字，列关键字和时间戳。 每个值是一个不解释的字符数组，数据都是字符串，没类型。,84,HBase数据模型,2019/7/13,Cloud Computing, GUCAS,84,用户在表格中存储数据，每一行都有一个可排序的主键和任意多的列。 由于是稀疏存储的，所以同一张表里面的每一行数据都可以有截然不同的列。 列名字的格式是“:“，都是由字符串组成，每一

46、张表有一个family集合，这个集合是固定不变的，相当于表的结构，只能通过改变表结构来改变。但是label值相对于每一行来说都是可以改变的。,85,HBase数据模型,85,http:/ 客户端可以选择获取距离某个时间最近的版本，或者一次获取所有版本。,2019/7/13,Cloud Computing, GUCAS,87,88,HBase逻辑模型,HBase是一个类似Bigtable的分布式数据库，大部分特性和Bigtable一样，是一个稀疏的，长期存储的，多维度的，排序的映射表。 每行包含一个可排序的行关键字，一个可选的时间戳以及一些可能有数据的列。 HBase中的每一张表，就是所谓的Bi

47、gTable。BigTable会存储一系列的行记录，行记录有三个基本类型的定义：行关键字（Row Key）,时间戳（Time Stamp）,列（Column）。,2019/7/13,Cloud Computing, GUCAS,88,89,HBase逻辑模型,2019/7/13,Cloud Computing, GUCAS,89,90,HBase物理模型,HBase是按照列存储的稀疏行/列矩阵。物理模型实际上就是把概念模型中的一个行进行分割，并按照列族存储。,2019/7/13,Cloud Computing, GUCAS,90,91,HBase服务器的体系结构,HBase的服务器体系结构也是遵从简单的服务器架构，由Hregion服务器群和HBase Master主服务器构成。,2019/7/13,Cloud Computing, GUCAS,91,92,HBase子表服务器,对用户来说，每个表是一堆数据的集合，靠主键来区分。 物理上，一张表是被拆分成多块，每一块就称呼为一个Hregion。 用表名+开始/结束主键，来区分一个Hregion，一个Hregion会保存一个表里面某段连续的数据，从开始主键到结束主键，一张完整