在企业、学校和各类服务提供商的计算中心建设中，数据库的搭建具有重要的地位。而为了满足应用的需求，需要不断地提高和更新硬件设施，这是一笔巨大的开销。并且随着数据量的增加和服务请求的增长，传统数据库将会面临诸多问题：
1)可扩展性差：传统数据不是为大规模可伸缩的分布式处理设计的，虽然也提供复制和分区的解决方案，但不能从根本上解决问题，并且非常难以安装和维护，甚至要牺牲一些传统RDBMS(Relational DataBase Management System：关系型数据库)的重要特性，不满足弹性需求的要求；
2)海量数据条件下读写性能低下：当数据或并发用户超过某个数量级后，性能上会有明显下降，不能满足高并发读写的服务请求；
3)管理复杂困难：传统数据库的维护要求人员专业性强，管理人员要进行严格的培训，对数据的管理和维护复杂；
4)运行维护成本高：传统数据库很难进行升级和更新，当现有数据库不能满足应用需求的时候一般是全部采用新的更强大的硬件和新版本的软件，这样不仅需要巨大的开销，还会使数据库暂停服务，在很多场合这是不能容忍的。
1、云数据库技术的发展和优点
传统数据库在一定程度上满足了目前传统的应用需求，但是由于其自身的缺陷和信息技术的发展，特别是在云计算平台上海量数据的管理和应用的背景之下，云数据库成为新一代数据库的发展方向，研究云数据库具有重大的意义。
云计算按照服务类型大致可以分为三类 ：IaaS(Infrastructure as a Service：基础设施即服务)、PaaS(Platform as a Service：平台即服务)和SaaS(Software as a Service：软件即服务)。云数据库是在SaaS成为应用趋势的大背景下发展起来的云计算技术，它极大地增强了数据库的存储能力，消除了资源的重复配置，让软、硬件升级变得更加容易。云数据库具有高可扩展性、高可用性，采用多租户形式和支持资源有效分发等特点。可以说，云数据库代表着数据库技术未来发展的一种主流方向。目前，对于云数据库的概念定义不尽相同，文中云数据库定义是：云数据库是部署在云计算环境中的数据库。
在云数据库应用中，客户端不需要了解云数据库的底层细节，所有的底层硬件和实现对客户端而言是透明的，它就像在使用一个运行在本地的数据库一样，非常方便简单，同时又可以获得理论上近乎无限的存储和处理能力。具有如下优点：
动态可扩展：理论上，云数据库具有无限可扩展性，可满足不断增加的数据存储需求。在面对不断变化的条件时，云数据库可表现出很好的弹性。如：对于一个从事产品零售的电子商务公司，会存在季节性或突发性的产品需求变化；或者对于网络社区站点，可能会经历一个指数级的增长阶段。这时，就可以分配额外的数据库存储资源来处理增加的需求，其过程只需几分钟。一旦需求过去以后，就可立即释放这些资源。
高可用性：不存在单点失效问题。如果一个节点失效了，剩余的节点就会接管未完成的事务。而且在云数据库中，数据通常是复制的，在地理上也是分布的。诸如Google，Amazon 和IBM 等大型云计算供应商具有分布在世界范围内的数据中心，通过在不同地理区间内进行数据复制，可以提供高水平的容错能力。例如，Amazon SimpleDB 会在不同的区间内进行数据复制，因此，即使整个区域内的云设施发生失效，也能保证数据继续可用。
较低的使用代价：通常采用多租户(multi -tenancy)的形式，这种共享资源的形式对于用户而言可以节省开销；而且用户采用按需付费的方式使用云计算环境中的各种软、硬件资源，不会产生不必要的资源浪费。另外，云数据库底层存储通常采用大量廉价的商业服务器，这也大大降低了用户开销。
易用性：使用云数据库的用户不用控制运行原始数据库的机器，也不必了解它身在何处。用户只需要一个有效的链接字符串就可以开始使用云数据库。大规模并行处理：支持几乎实时的面向用户的应用、科学应用和新类型的商务解决方案。
2、主流的云数据库产品和比较
经过近几年的发展，各企业根据自身的业务需求和数据特征设计了各自的云数据库，通过对当前云数据库市场的调查，结果如表1 所示。
使用云数据库平台可以直接采用Amazon、Microsoft、Oracle 的云存储解决方案，但是建设这样的平台代价很大，对经费要求很高。同时也可以采用HBase、Hypertable 等开源的解决方案，这虽然免费并且可以根据自身应用做相应的优化，但是对技术要求很高，后期开发具有一定难度。为了选取合适的云数据库，对各个产品进行了对比。
2.1 Amazon 的SimpleDB
SimpleDB是Amazon 提供的简单数据库服务，主要用于存储结构化数据，并为数据提供查找、删除等基本的服务，其具体的实现细节Amazon 没有公开。由于Amazon 主要是提供商业性的服务，使用其服务需要一个Amazon 的帐户，那么一个用户帐户就相当于全集，而具体的数据则相当于子集。由于SimpleDB简单的数据存储方式，其所有的数据都是以字符串形式存储，导致其采取词典顺序进行查询，数据操作很不方便。考虑到其技术封闭性，不能在实验环境中使用其平台。
2.2 Google 的BigTable
BigTable是Google 基于GFS (Google File System)和Chubby 开发的分布式存储系统。BigTable 是非关系型数据库，是一个稀疏的、分布式、持久化存储的多维度排序表。它采用行键(row key)、列键(column key)和时间戳(timestamp)对表进行索引。表中的每个值都是未经解释的字节数组。BigTable 在行键上根据字典顺序对数据进行维护，并且一张表的行键也是其划分行区间，进行Split 和负载均衡的依据。其设计目的是可靠地处理PB 级的数据，并且能够部署到上千台机器上。BigTable 已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性。BigTable已经在多个Google 的新产品和项目中得到了应用，如Google Analytics 和Google Earth 等。
根据对BigTable 的研究，了解到BigTable 主要是Google 针对自身各种应用设计的存储系统，并且没有开源，在实验中无法使用。但是BigTable 的主要技术和实现都对外开放，并且BigTable 的研究资料非常丰富，在研究云存储的过程中具有很高的借鉴意义和参考价值。
2.3 Microsoft 的SQL Azure
SQL Azure 是微软的云关系型数据库，是基于SQL Server 技术构建的，主要为用户提供数据应用服务。SQL 简化了数据库的部署，用户无需安装和配置数据库，也不需进行维护和管理。并且，SQL Azure 还为用户提供高可用性和容错能力。SQL Azure 做为一个商用数据库，其提供一个云端的DBMS(DataBase Manager System)，这使得本地应用和云应用可以在微软的数据中心的服务器上存储数据。用户是按需付费，其中主要的费用是操作费用，而不是磁盘和DBMS 软件投入的费用。
SQL Azure 做为一款商业软件，其采用按需服务、按需收费的模式。由于其不开源，所以无法在实验环境中搭建，但是做为云数据库中采用关系型数据模型的典型代表，依然具有重要的研究意义。
2.4 Apache 的HBase
HBase数据库是基于Hadoop 的Apache 顶层项目，它是BigTable 的开源实现，但存在很多不同之处。HBase 是一个在HDFS 上开发的面向列的分布式数据库，主要支持实时的随机读写超大规模数据集。HBase是自底向上地进行构建，能够简单地通过增加节点来达到线性扩展。HBase 是非关系型数据库，不支持SQL 查询，但其具备了RDBMS 无法比拟的特性：在廉价硬件构成的集群上管理超大规模的稀疏表。HBase系统结构如图1 所示。
HBase 采用一个Master 节点协调管理一个或多个RegionServer 从属机(HBase 把表水平划分成Region“区域”)。HBase 主控机(master)负责启动和注册RegionServer，把Region 分配给RegionServer 并负责RegionServer的故障恢复。RegionServer 负责Region 的管理和响应用户的读写请求，当有新的Region 产生时，RegionServer 将通知Master 节点。
HBase 依赖于Zookeeper(Zookeeper 提供分布式锁服务，类似Google 的Chubby)，它管理一个Zookeeper实例，作为集群的“权威”(authority)，并负责根目录表的位置、当前集群主控机地址等重要信息的管理，并负责维护整个集群的工作状态和灾难恢复。
HBase 是开源实现，可以方便地从互联网上下载安装包和源代码，非常适合企业、科研单位和学校进行使用学习和再开发。但其操作和管理界面比较简单不够友好，需要进一步提高。
2.5 云数据产品比较结果
通过对几种具有代表性的云数据库进行研究，比较结果如表2 所示。
3、实验
综上所述，决定采用HBase 做为研究云数据库的实验平台。
HBase 的安装可以分为三种模式：单机模式、伪分布式模式和完全分布式模式。文中采用完全分布式模式，这样可以模拟实际网络环境，能够体现云数据库的特性，使实验结果更具有说服力。
3.1 实验环境的搭建
在实验环境中共有6 台服务器，搭建完全分布式HDFS 与HBase 环境，采用hadoop0.20.0 与HBase0.92.0 版本，其中二台节点做为Namenode 和Master 节点，另外四台做Datanode 和RegionServer，并且在其上运行Zookeeper 服务。整个实验环境如图2 所示。
在安装Hadoop 和HBase 之前要在系统中安装JDK 并配置好环境变量。在用户目录下安装好Hadoop和HBase 之后，进入Hadoop 目录下输入命令：
rm / tmp/ *
bin/ hadoop namenode – format
bin/ start-all.sh
来启动HDFS，可以使用bin/ hadoop dfsadmin – report来查看HDFS 的可用资源、实际使用百分比和Datanode的运行情况。
HBase 是运行在HDFS 之上的，所以必须确保HDFS 处于正常运行状态。同时因为存在版本兼容性问题，在启动HBase 之前必须让HBase 确定使用Hadoop的版本，需要把Hadoop 目录下的hadoop-0.20.2-core.jar 替换掉HBase/ lib 目录下的hadoop-core-1.0.0.jar。最后确保集群中每台的时间保持相对一致(误差小于30 秒)，进入HBase 目录输入命令bin/ start-hbase.sh 启动HBase。用命令bin/ hbase shell 进入外壳程序，用命令status 查看HBase 的状态。
3.2 实验详解
在完成实验环境的搭建之后，为了对HBase 官方描述的HBase 系统具备的特性进行验证，设计了一些实验对HBase 集群进行初步的测试：
1)海量数据的存储
HBase 提供JAVA 编程API，在Eclipse 环境下编写数据库写入程序，并且递增数据写入量，查看所需的时间，对性能进行简单的分析。
根据HBase 存储的特点，因为HBase 是对Rowkey进行排序的，随机Rowkey 将被分配到不同的region上，这样能发挥出分布式数据库的优点。而Value 对于HBase 来说不会进行任何解析，其数据是否变化，对性能是不应该有任何影响的。同时为了简单起见，所有的数据都将只插入到一个表格的同一个列中。
数据插入性能测试的设计场景是这样的：取随机值的Rowkey 长度为2000 字节，值的Value 长度为4000 字节，每次插入10000 条数据，直到1000 万条结束。实验建立的表名为TestData，实验开始后可以从
http：//master：60010 查看进展。
结果表明从数据刚开始写入时，只存在1 个Region，随着数据达到一定的规模之后TestData 开始分裂，并实现负载均衡，把Region 平均存放在Datanode中。
HBase 不仅支持自动的负载均衡和副本容灾机制，并且读写性能也很优秀，通过对上述实验数据写入时间的统计，数据写入速度达到0.47ms/ 条(2127 条/秒)，并且在理论上还有很大的提高可能，因为实验用的数据库写入程序为单线程，没有采用MapReduce 并行编程模型。如果采用MapReduce 模型，写入速度将会有很大程度的提高。这将在以后的研究工作中得到实验验证。
2)数据库的动态扩展。
相对传统的数据库，云数据库具有近乎无限的可扩展性，可以满足不断增加的数据存储需求。在面对不断变化的条件时，云数据库可以表现出很好的弹性。为证明云数据库具有的这个优势设计了如图3 所示的实验。
首先用5 台服务器建立一个云数据库平台，其中2台Namenode 和Master，另外3 台为Datanode 和RegionServer。启动HDFS 和HBase，待系统正常运行之后查看HDFS 和HBase 状态可以得到系统中正常的Datanode 和RegionServer 都是3 个。然后，在Namenode上注册想要加入的节点IP 地址，于Hadoop 的conf目录下的slaves 文件和HBase 的conf 目录下的regionservers文件中添加新增节点描述，并把配置文件复制到整个集群的每台服务器上。用start-all.sh 命令对整个HDFS 系统进行启动，这时系统会对注册Slave 的节点进行检测。如果已经挂载那么则跳过，否则将在该节点上启动HDFS 并挂载到系统中来。再运行starthbase.sh 把新添加的RegionServer 挂载到集群中。最后，可以看到整个HDFS 和HBase 的可用节点都动态地增加了。这种动态扩展性能能够满足动态的需求并在节能方面具有很大的优势。
3)数据库集群的抗毁性。
云数据库的抗毁性是其中一个很重要的性能指标，主要体现在数据节点的容错性和Master 节点的动态备份容错。针对这两点设计实现了如图4 所示的实验。
数据节点的容错性实验：在搭建好数据库集群中创建表并写入一定量的数据，手动进行负载均衡让数据平均存放在每个节点中。然后，再在数据节点集群中kill 一定数量的节点，并检测数据是否可用。结果是：当down 掉的数据节点小于集群配置dfs.replication的数据副本数时，该集群的数据始终保持可用。
Master节点的动态切换：Master 节点是管理数据的元数据表，表的查询都要经过元数据表的索引，所以Master 节点具有唯一性，并且Master 必须要高可靠。设计如图5 所示的实验。
两个节点同时运行HMaster 服务，其中一个为主Master，另一个为备份Master 并与主Master 保持同步。在数据库集群正常运行的情况下，在主Master 节点中kill 掉HMaster 进程，集群在经过zookeeper.session.timeout 定义的时间之后，检测到主Master 节点不可用，这时集群将进行Master 节点的切换，并且之前数据库的数据不会丢失，整个集群依然可用。所以，备Master 在主Master 出异常不可用后将接替其管理HBase 数据库的功能。
4、实验结果
通过实验可以看出HBase 在可扩展性、海量数据存储、高可用性以及管理和运行维护方面具有很大的改进和提高。
在动态可扩展性方面：实验表明HBase 在添加存储节点对数据库进行扩容的过程中，数据库没有停止服务，并且也不要求物理机具有相同的架构。说明HBase 的扩展是在线、动态具有弹性的。从而使得HBase 可用于提供弹性服务，在服务峰值动态加入大量节点用以满足服务请求，提高服务质量。而在低谷时期则关闭大量节点，这样可减少能量消耗降低成本。海量数据的读写性能方面：由于HBase 是基于HDFS 之上建立的，所以也继承了其Map/ Reduce 的计算模型，这使其具有优秀的读写性能。淘宝网通过优化HBase 使得在数亿条商品数据中查询指定商品的时间可以达到毫秒级。
高可用性方面：传统数据库设计时是考虑如何避免故障的发生，而HBase 则是以大的集群为出发点，把故障做为一个常态来进行对待。HBase 采用多Master节点同时运行的策略：其中一个Master 为主Master 提供服务，而其它的Master 节点则保持与主Master 的同步，当主Master 出错之后由Zookeeper 选举产生新的主Master 继续提供服务。对RegionServer 而言只要不同时有大于副本数目的节点失效则可保证数据一定可用。
另外，在低成本和易用性方面HBase 对传统数据库也有很大的优势。硬件方面HBase 只要求使用普通的商用服务器即可，软件则是开源，节约了大量成本。并且，HBase 屏蔽了物理层，对于客户端而言就像使用一个安装在本地的数据库，操作简单，维护方便。
5、结束语
文中提出了可以使用云数据库来解决当前传统数据库面临的诸多问题，并用HBase 做了验证性的实验。通过实验发现云数据库除了可以提供传统数据库一样的数据存储服务以外，还解决了目前传统数据库面临的问题，特别是在可扩展性方面具有无与伦比的优势。云数据库是未来数据库发展的主流方向，可以做为企业单位、科研院所和学校数据库的首选产品。
下一步实验和研究工作主要集中在云数据库性能的详细测试和分析，并根据实际的应用场景进行性能的优化。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：云数据库应用研究
本文网址：http://www.toberp.com/html/consultation/10839713204.html
相关文章
