云数据库

云数据库：放眼无穷处

[11-27 17:51:08]作者：王翔责任编辑：heyaorong

作为广义云计算的一种高级应用，云数据库蕴含着前所未有的数据服务交付能力。它倡导类似于自来水取用一般的服务机制，在理想状态下，它能够支持无限的并发用户，提供永不枯竭的数据应用资源。

作为企业IT系统的核心部件之一，数据库承载着最重要的信息资产——数据。不过，随着时间的推移、业务的拓展，越来越多的企业发觉正在逐渐失去对数据的控制力。数据形态的多元化、数据容量如脱缰野马般的爆炸性增长，让企业的数据环境接近容量的极限。与此同时，数据的维护于管理工作日益繁重，DBA（数据库管理员）们日复一日地在备份、优化、扩容、高可用的工作间往复循环。

如何解决数据容量激增与管理任务繁琐的矛盾？最近一段时间被业内各界大肆追捧的云计算技术或许担当拯救者的角色。通过营造服务型的数据库应用环境，立足于“云”之上的数据库系统有望被赋予全新的数据服务交付能力。

云计算与云数据库

作为一种基于互联网的超级计算模式，云计算同时也构建起一种全新的商业模式。云计算使用的硬件设备主要是成堆的服务器，企业和个人用户可以通过互联网获取计算能力，未来也可能出现一些超大型企业内容通过广域网获得计算能力的模式。这种运算模式从表面看是避免了大量的硬件投资，更深层次的优势是对运维成本的节省。其基本原理为，通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中，从而为更大范围的用户提供“足够用”的计算能力。

虽然运行方式存在很大差别，但与现有的应用一样，云环境下计算的主要对象仍是数据，因此“云+数据库”的结合产生了两种模式。一种模式为运行在“云”中的DBaas（即Database as a Service）。另一种模式为云数据库（即CloudDB，或者简称为“云库”）。

比较而言，DBaas更接近于关系数据库管理系统（RDBMS）。实施方面，我们跟运营商说需要一个运行在云中的数据库实例，MySQL也好、Oracle也好，他们基于云存储体系完成后提供给我们一个连接许可，然后我们使用这个实例即可。

反观云数据库，其与现有的RDBMS存在较大差别，虽然都是关系数据模型，但我们不应该也无法做出其是MySQL还是Oracle的假设，它就是一系列的二维表格，操作方式也是基于简化版本的类SQL或访问对象。

虽然云数据库看似相对“简陋”，但在使用上它的扩展性却更好。因为数据库实例对于并发用户的支持是有限的，即便是在基于近乎无限的云存储环境中进行操作；而云数据库的使用就

同我们打开水龙头一样，水从城市的哪个水库调过来，甚至从哪个城市调过来都与我们无关，我们只需按照流量付费好了。与我们以往购买托管服务器、自己安装和维护数据库不同，你不能控制运行数据的机器，不知道也不必关心它所处的位置。基于云数据库的这些应用便利，它将成为本文讨论的重点。

应用特征分析

企业可以在某个阶段将数据体系置于“云”上，云数据库理想的使用方式就像使用自来水一般在新的数据库环境中取用数据。从成熟度方面分析，如果实施的是业务系统，而且操作中经常会出现数据争用的情况。那么云数据库就难于保证事务处理的正确性，因为不同于商用RDBMS，它所支持就是操作二维表格。其主要事务处理方式如附图1所示。

从应用布局看，云存储和云计算能力解决了应用基础设施的问题，它相当于一个虚拟运行的操作系统。云数据库解决了数据集中与共享的问题，剩下的是前端设计、应用逻辑和各种应用层开发资源的问题。附图2即为一个典型的云应用环境。

在云应用环境中，不同类型的客户程序一般通过HTTP、HTTPS、SOAP等方式访问Web 服务器。而一些中小规模的应用可能由Web服务器直接访问云资源。一些大型项目可能还需要Web服务器访问应用服务器，然后由应用服务器间接地访问云资源，以及第三方的服务资源。

云数据库的应用风险

虽然概念上云数据库与传统的应用流程差别不大，但这个通路因为超出了用户的控制范围，因此在实际执行效率、服务响应质量方面增加了很多不确定的因素。例如，用户把客户业务办理申请的信息提交给云数据库，因为企业的业务人员散布在亚洲、欧洲的几个中心城市，所以云运营商把他们实际存储在莫斯科、东京、班加罗尔这三个中心。但有一天老板在张家界的会议期间需要尽快获得一个投资豆油的敏感客户列表，以便对这一人群加强审查和防范。IT部门提交了一个查询，接着一个很壮观的查询便在地球上“蔓延”，这个时间可能就如您打开Google Russia、Google Japan和Google India那么长，但究竟有多长，还得看情况。不过这还不算最糟糕的，IT部门提交了一个查询，结果几毫秒内就获得一个服务不可用的异常，您的Web服务器运转正常、应用服务器健康状态非常好，可惜没有数据，因为数据并不在您自己手中。

云数据库供应商在宣传时都会强调其产品多么易用、能够降低多少IT运营成本，但对数据遗失问题总是绝口不提。那么一旦数据遗失用户该怎么办呢？诉诸法律的念头还是打消为好，一方面证据不在您手中，另一方面他们在这方面几乎都是老手。

这就引出了一个新的问题，如何平衡云数据库的低成本、无限扩充能力与可能的运行风险。选择网络运营商的“双线”方案（即基于未来标准的云服务协议及相关中间件，以标准云数据服务接口的方式，同时保留两个或两个以上云数据服务提供商的Failover——故障转移方式）或许不错。不过，还要在应用上做些处理，因为现阶段云数据库几乎都是按流量收费，每次都两线提交查询太浪费。那么，“双线+云服务监控器”的方法如何呢？云服务监控器定期检查每条通道的可用性及响应时间，上层应用把通道选择交给一个集中的路由适配机制，该机制根据监控器的反馈选择某个通道，然后按照这个云数据库的接口提交完成数据交互。

这样一来，就可以用比较小的监控流量（即较低的费用）实现容灾设计，看似比较圆满，但事实上远远不够。因为今天存在A上的数据，下次在A和B都健康时，如果请求还是访问到A，那么你很幸运；如果访问到B那么上层逻辑就一定考虑它确实没有么？面对这个情况，您可能会想是不是请A和B同步？不过，似乎很长一段时间内我们还看不到Sun会和微软的云数据库进行同步的迹象。那么，我们是否应该用自己设计一个自动或半自动化的功能来完成？即便不考虑成本因素，在这样一个通道上，如果能保证全部都同步成功，那当初还需要选择“双线”么？

另外，我们还应该多思考一下，云数据库厂商要求的费用真的比用户自己部署廉价么？例如缓存，用户会发现，某些内容是访问最频繁的，它们几乎占据了网站访问请求的95%以上，如果完全基于云数据库机制，那么就是每次计费，如果自己做个数据库，则完全可以通过访问数据库自动缓冲的数据获取这些内容，CPU、磁盘还有响应时间几乎用不了多少成本。

云数据库商业分析

尽管云数据库的应该会带来各式各样的风险，但它对运行环境、数据存储、内容访问方式三者的封装交付方式却非常成功。从长远角度分析，在Web 2.0创新大潮的推动下，云数据库有望快速成熟，并在短期内实现可靠性的提升。

作为广义云计算的一种高级应用，一些机构对云数据库拥有比较显著的应用优势。例如，互联网企业，尤其是尝试进行各种新兴互联网应用的企业就能够从此项技术中获益。

几乎每个成功的互联网公司都经历过一段高速膨胀的阶段，其间新的创意一下子被一个很大的用户群所接受，应用逻辑无需复杂，而展现和内容的获取方式往往成为其中的亮点。而在应用备受好评的同时，企业却发现应用运行的基础出现了瓶颈、甚至不做大的修改就会形成死结。

鉴于有失败案例在先，后来者在将创意投入市场时应该明白，市场的反应也许还是个未知数。这时候，架构上采用什么体系和规模的运行环境还不明确，而最关键的是商机。基础固然非常重要，但如果因为“论证→测试→再论证→再测试”的往复循环而耽误上线时间的话，机会可能就此流逝了。要解决这个问题，不妨先把您的创意展现并发布出来，在必要的抽象后将其至于一个理论上容量无限的云数据库之上，这样企业就可以专心做最具创造性的工作。退一步来讲，即便这个创意无法被市场所接受，您也不用在早期投入大笔的资金和设备，商业风险相对较低。

云数据库的另一大商机可能来自硬件厂商。区别于前面几次开发浪潮（结构化、面向对象、面向组件），云数据库的出现是在应用趋于SaaS（软件即是服务）的大背景下发展起来的云计算技术。也就是说，它从一开始就面对着拉平了的世界中有着千丝万缕联系的应用，存储、计算和数据量都会在这一交织过程中快速膨胀。对于云运营商而言，实现这些需要大量的服务器，然后用户膨胀的信息需求会继续带来服务器数量的增加。

从以往的经历看，咨询和服务行业在每次技术换代的过程中都会收获颇丰。区别于以往的“企业级”（Enterprise-Class）范畴，云数据库一开始就将技术平台定位在“世界级”（World-class）。如何在另一种程度的分布式环境下完成创新应用，并且让该应用跑的快、跑的稳就成了这类企业亟需的研究内容。

正如我们今天所看到的，虽然SOA厂商本身并没有在国内通过产品获得太丰厚的收益，但整个行业因SOA相关的服务和咨询已经有了不俗的业绩表现。而云数据库作为SOA和SaaS在