英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料
关系数据库转化为HBase：一个案例分析
Chongxin Li
计算机科学与技术学院
浙江大学，杭州，中国
摘要：随着分布式系统和云计算的发展，越来越多的应用将迁移到云端以利用它的计算能力和可扩展性，其中首要任务就是数据迁移。在本文中，我们提出一种新颖的途径将数据从关系型数据库转换到HBase，HBase是一个类似Big Table的开源分布式数据库。我们的方法分为两个阶段。第一阶段中，关系模式根据HBase的数据模型转换为HBase的结构模式。在此阶段，我们提出了三个准则用于进一步开发HBase应用。第二阶段中，把两个模式之间的关系表示为一组嵌套的模式映射，这将用于创建一系列查询或其他程序，进而把源关系型数据库自动转换成目标代理。
关键字：HBase；数据转换；模式映射
- 引言
云计算因其灵活性和可扩展性，已经成为数据存储和处理的趋势。通过使用PaaS（平台作为一种服务），企业尤其是小型企业，只要按需求使用而付款而不是自行维护基础平台。此外，应用可以按需求伸缩规模，不需要付出额外代价。这些优势使云计算对于吞吐量变化很大的应用是一个好的选择。但是，大多数云平台考虑到可扩展性，并不支持关系型的数据。为了满足可靠性和伸缩需求，一些存储技术已被开发并代替关系型数据库来存储结构化和半结构化的数据，比如Google App Engine (GAE)的BigTable[3] 和Amazon Web Service (AWS)的SimpleDB[10]。于是，原来使用关系型数据库的应用必须把数据迁移到云基础数据库，这样他们才能在这些平台上运行。
数据转换和集成是一个老研究主题了，由于各种格式的数据之间的交换需求增加，使得近年来它又获得越来越多的关注。最初它被用于处理关系模式[6, 9]，后来又延伸到处理嵌套XML数据[1, 4]。进一步的研究主要关注语义一致性[2]的优化。同时，原型系统是在数据自动转换的研究上发展起来的。例如Clio [7, 9]，是部分集成到IBM的DB2，可以在任意关系和XML模式的组合之间生成映射。然而，据我所知，目前很少有关于从关系型数据库转换到非关系型云基础数据库的相关研究工作，这也是本文的主旨。
在本文中，我们提出了一个新的解决方案将数据从关系型数据库转换到基于云的数据库，并给出了一个案例分析。相对于传统的范式化数据库，几乎所有基于云的数据库都是非范式化的：数据可能是分组或冗余的以加快读取速度。虽然数据库支持最终一致性，但是这可能导致在一个操作中短时间内会出现数据不一致的情况。因此，基于云的数据库多数都是适合频繁读并且能够容忍短暂数据不一致的OLAP系统，比如web应用。另一方面，注重ACID的OLPT系统就不应该迁移到云端，比如银行系统。我们从一个基于云的数据库—HBase着手研究，它是Big Table的开源实现。根据HBase的数据模型和特点，我们提出了一个探索性的转换方案。尽管我们的工作只适用于HBase，Big Table和其它类似基于云的数据库（Hypertable，Cassandra），但本文也可以被视为这一研究方向的一步和未来相关工作中的一个提示。
我们工作的主要贡献归纳如下：
- 我们认识到了关系型数据库和基于云的数据库之间的数据转换问题。
- 我们提出了一个探索性解决方案来处理关系型数据库与HBase（一个基于云的数据库）之间的转换。
本论文剩余部分组织如下：第二部分简略地研究了HBase的数据模型。第三部分中，我们以一个案例分析为背景并提出我们的转换方案。最后，第四部分我们对未来工作的方向作出分析来总结论文。
- 准备工作
Big Table是一种稀疏的、分布式的，多维度的排序Map。作为Big Table的开源实现，HBase使用的数据模型与Big Table非常相似。作为BigTable的开源实现，Hbase用的数据模型与BigTable非常相似。一个数据行有一个可排序的rowkey和一些任意的列，并且被归组成为列族。每个数据单元被时间戳标号，可以包含多版本的同一个数据。如果没有指明，拥有最近时间戳的数据会被默认读写。这样，剩余部分论文，我们将不会明确考虑时间戳。传统关系型数据库是表的形式，作为区别，我们用一个排列好的映射表达Hbase表（fig.1（a））。
于是，表的一个数据单元，可以看做键-值对，键就是rowkey，列和时间戳的组合；值就是字节组成的无解释的序列（Fig.1(b)）。
列族是BigTable引入的概念，也在Hbase中有重要作用。相同列族的数据存放在文件系统中，不同列族就可能被分配到不同机器上。列族必须在存储数据前创建。并且，列族的数量通常比较少（最多几百个），列族在操作时很少改变。相反，一个表可能有未绑定数量的列，并且列可以动态加入列族。这使得列的键值可以适当加入用户数据。这样，表的不同行一定有相同的列族，但是可能有完全不同的列。Hbase数据模型和所有以上性质应该在你设计Hbase表或者之后转换的时候考虑到。
- 关系数据库向HBase的转换
- 概述
为了更好的了解关系型数据库的转换，我们从一个例子展开问题。
例子：观察上面的FIg.2结构。它展示了一个博客系统的三张表：User(name,password,email)Blog(id,user_name,title,date,text)Comment(id,blog_id,date,author,text)和许多其他博客系统一样，每个用户可以在系统发博客，并且其他人即使不是用户也可以加以评论。外键用破折号表示。那么的工作就是无损地把关系型数据库转换成Hbase数据库。
我们把转换过程分解为两个阶段。第一阶段，基于数据模型和Hbase性质，引入启发性的方法把关系数据库的源结构转化成Hbase结构。然后，第二阶段，在原结构和目标结构间生成映射关系。既然值是由列族分组的，我们扩展了嵌套映射技术，在XML结构映射中显示出了很好的结果。这样，源数据可以在第二阶段基于结构的映射下转变为目标表示法。整个过程在Fig.3中表示。这两个阶段在下两章会详细说明。值得指出的是，尽管我们用一个案例展示我们的方法，我们的过程一样对其它关系型数据库适用。
- 结构转换
正如第一部分介绍的，同一列族的数据分组在文件系统中一起存放。直觉上，引出Hbase结构设计的第一准则。
准则1：相关的分组在一个列族中
以博客系统为例。一般博客页面以博客主题和上传时间为起始，然后主要部分是博客内容。所以所有信息倾向于一起读写。同理，如果你查看用户个人信息，该用户的档案资料会被一起从数据库中读出。因此，这类信息可以被认为是相关的。虽然关系结构在旧规范准则下设计，这依然给了数据关联的一些启发。这样，一个Hbase结构可以直接从关系结构中获得；每个关系数据库中的原始表对应一个Hbase表，旧主键被设成rowkey,并且只有一个列族被创建。元素表的列被分组到特定列族中，确保这些相关数据配一起存储。而且，我们可能看见同一用户的博客在一页上，只列出标题，发布时间和小片段。如果你想读博客，你必须点击标题，那么博客内容从数据库中获得。从这点看，准则指出的“相关数据”更多的是获取方式和应用的写方式，而不是简单字面理解。那么在这一环境下，博客内容和其他信息元不是一起访问，可以被分为两个列族。初始Hbase结构如Fig.4(a)。
但是，初始结构远不如Hbase结构的最佳设计。在关系型数据库中，有三种关系：一对一，一对多（多对一），和多对多。外键用来保持这种关系，并且引用父、子对象。但在Hbase中，我们只能用rowkey来获取数据。这样，不知道对象的rowkey就不能访问到他们，比如在Fig.4(a)，我们可以简单由user_name列获得博客作者，但获得所有指定用户写过的博客就不容易了，因为作者到他博客的引用，为了可伸缩性，Hbase里面也没有支持可以连接的操作。这引出了Hbase结构设计的第二准则。
准则2：关系的没一边，如果要访问另一边，就加入另一边的外键引用
我们为三种关系考虑这一准则:
1)一对一关系
因为这样关系在关系型数据库中已经有了，实际上我们没有必要担心这种关系，外键可以放在任意一边关系。这种外键列可以在Hbase中视作普通列，可以基于准则1和其他列一起分组。
2）一对多关系
在关系型数据库中，因为范式1，多值访问在RDBMS中是不允许的，外键只能放在一对多的“多”的一边。但在HBase中，多值可以在列族中一起归为一组。为了应用“多”边的对象，在“一”边的应该新建一个列族。以Fig.4（b）为例，User表的blogs列族包含一个用户发布的所有博客。那么获取一个用户的博客可以分两步。一，用rowkey--username获得blogID；二，用ID继续抓取所有这些博客。获取一个博客的所有评论也是一样。
3）多对多关系
多对多关系有些不同，因为这种关系由第三个表维护，两个外键维护着两边表。但是，因为关系两边都是“多”边，我们可以像一对多一样做。为得到另一边的rowkey，我们新建了两个列族。同时，第三个维持关系的表可以删除，因为它的信息已经由两边的关系表达了。
尽管我们还是称这些引用为外键，它们与关系型数据库的外键是不同的。关系型数据库中，数据库本身会保证数据状态的一致性，用户数据不会打破外键约束。比如，博客不会插入一个不存在的用户名。但在Hbase中，是应用本身来维持这种约束。当一个博客从系统删除，首先删除blog表中记录，然后从user表中删除blogs列族的博客信息。除非使用延迟删除，可以保证到下次读的时候再把user表中的博客删除。任意两种方法，都总是有不一致性存在的状态。这是获得可伸缩性的一种代价。
另一方面，如果在一个应用中一边没有访问另一边，我们没有必要为这些对象加外键，比如，如果博客系统没有列出用户所有博客的要求，我们可以省略blogs列族包含的外键。
总结来说，和外键相关的操作可以分为两步。关系型数据库为了符合范式和减少复制，总是把数据分成很多表。这就是为什么我们有外键的原因之一。但是，云中数据库不在是规范的数据库。这些拆分的数据可以合并以减少外键，而且把两步操作合为一步。这就是我们转换的第三准则。
准则3：合并附属数据表以减少外键
通常，给一个关系型数据库应用，有些表中的数据库非常重要可以独立使用；有些数据是附属的并且基于其他表的外键。如果一个表可以在应用中独立使用，我们称为主要表。另外，如果一个表只有一个外键并且数据是其他对象的引用，叫做附属表。有相同的外键的附属表可以基于外键，合并到主要表中的一行。让我们再研究博客系统。为了把表合并，我们区分主要表和附属表。博客评论必须和内容一起显示。如果一篇博客删除，这些评论也删除。因此，blog表是主要表，comment表示附属表。下一步考虑comment表合并到blog表。第一想法是blog表中新建comments_full列族。为了方便理解，我们用评论时间作为列键其他像作者和文章组合到列值中去。这一方法确点事列值必须分散来显示评论。为简便我们分隔值域，每一个都新建列族。设计如Fig.4(c).虽然可能根本上分隔评论的各个值，但评论结构更好更容易访问。权衡是值得的。
我们给出了一些基本的关系型数据库到Hbase的转换准则。然而，转换应该根据就特殊应用业务决定。而且，访问模式和写模式需要仔细推敲，从而使Hbase的结构设计适应最频繁最重要的使用。
- 结构映射
在以上部分给出源结构和目标结构，结构映射表达了两个结构之间的关系。为了关系型的和XML结构，结构映射都被强化研究过。虽然HBase中的数据是以表来组织的，我们认为HBase结构更像是XML结构，都是嵌套的。因此基于嵌套的映射方法在这一章会被使用。
为了做到转化，我们必须懂得这两个结构如何彼此对应的。有无数的建议来表达内部结构的对应，其中元素对使用最广。直观上，一个元素对应是一对拥有相等值的原数据和目标数据。通常，一个技术化的结构匹配用来抽象对应。但是，因为目标结构是结构转化生成的，对应数据可以在过程中获得。对应关系在Fig.5中显示。
下一步考虑结构映射的生成。表是一种描述所有结构基本概念和关系的方法。源结构和目标结构都有一系列表。每张表包括相关概念，就是说，依据外键约束这些概念都必须一起存在。对于关系型数据库结构，表用以前同样方式计算，用约束通过追过法加强。博客系统的源表的如图Fig.6(a)。
但是HBase目标结构就有点不同了。因为列被动态加到列族中，列以两个不同类型对待。第一类型，列键被看成表的元数据。这个关系型数据库中的用户数据只能放到一个列单元中是一个道理。Fig.5中a，b，c的对应是这种类型，比如用户表中数据info：email=“tommy@gmail.com”，email列得到修正。但是对于另一种类型，列键和值用来保存用户数据，比如blogs：“hbasedatamodel”=“24”，“hbasedatamodel”和“24”都是用户数据。新的列键和值被插入到这一族中，只要新的用户发表了新博客。这样，当生产映射时，这种类型列必须嵌套，比如Fig.5中的{d,e},{f,g},{h,i}。目标表结构如图Fig.6(b).
然后对于表（A，B），A是源表，B是目标表，令V成为所有被A覆盖
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[153791]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
