数据库即服务（Database as a Service; DBaaS）是以传统数据库技术为基础，将数据库资源以标准服务的形式提供给一个或多个租户的服务能力。数据库即服务平台为用户提供一个统一的数据库访问服务，它屏蔽了底层的异构数据库，为上层应用提供了简单方便的数据库访问接口，将应用和数据库隔离开来，降低了耦合性，增强了系统的灵活性和健壮性，为增强数据访问控制提供了可能。

以云计算为代表的新型互联网计算模式正成为当前企业界和学术界的研究热点。云计算的一个特征就是通过基于互联网的服务和“托管”及“租用”的模式为各类用户提供IT基础设施能力。随着云计算的发展，其应用范围得到进一步的扩展，人们开始尝试利用云计算技术来提供数据应用托管服务，特别是大量的行业数据应用，即数据库即服务(Database as a Service，DBaaS)，以降低数据应用系统部署及运维的成本。DBaaS平台使用多租户实例隔离和资源池化的技术手段，对用户和真实硬件资源的使用情况进行隔离；这样不仅能更好地利用底层的硬件资源，也使得用户更关注数据业务本身。混合、异构数据库即服务平台在原有数据库即服务平台的基础上优化了异构特性支撑能力和跨数据中心异构支撑能力。当然，一个完善的 DBaaS架构还应具有较为完备的安全机制、自动资源管理和综合性能规划等功能，并且能够适配各种不同的接入设备，DBaaS所具备的很多特性也是传统数据库服务架构自身已具备的，所以DBaaS 是对数据库功能的封装和创新，DBaaS不能脱离传统数据库技术而独立存在。

DBaaS的优势

DBaaS解决方案既可以解决这些问题，又能为客户节约资金。相反作为解决方案提供商，采用DBaaS模式似乎就并不那么有吸引力了，因为与企业内部署软件的解决方案相比，DBaaS意味着更低的利润。但DBaaS系统其实具有更大的市场机遇：像其他云服务一样，DBaaS意味着更短的销售周期，更少的启动费用，持续不断的收入，也意味着比之前更多的客户。

由于DBaaS解决方案可以降低首次投入成本，对于那些小企业来说，他们往往认为内部部署的数据库成本太高，DBaaS的成本和灵活性优势对小企业吸引力更大，他们是云数据库解决方案的重点客户群体。采用DBaaS解决方案，他们也可以使用同大企业一样的技术。在大型组织中，DBaaS可以提供部门级解决方案，而无需IT部门和采购部门的介入，提供更快和更容易的方法来实现小型解决方案。由于能够以较低的成本向客户提供IT所有权，当节约成本成为客户最高优先级时，解决方案提供商可以向更多的客户同时提供服务。虽然有许多来自RDBMS固有的局限性，客户还是可以使用DBaaS系统所能提供的所有能力。数据库云服务消除了组织对专职人员、本地数据库存储设备的需要。他们不必安装、配置和维护任何软硬件。

事实上，任何规模的组织都可能受益于外包服务，并在一个标准化和优化的平台上统一其数据库管理任务。基于其本身的特性，DBaaS提供了敏捷和高效的数据库服务，它可以支持多变的需求。而且其固有的弹性使得它易于扩展以处理不断增长的需求，或当需求减弱时缩减规模。

然而，DBaaS并不意味着解决方案提供者要让自己失业。与其他系统一样，在实施DBaaS解决方案时，客户可能需要部署、迁移、支持、异地备份、系统集成和灾难恢复等方面的帮助。接下来，应用程序需要使用数据库，数据库本身需要设计、开发和部署。还有，客户怎样实施混合系统，或者需要帮助管理多个云服务?

与此同时，与数据库相关的流程的逐渐标准化，使得解决方案提供商能以更便捷的方式提供服务、部署应用程序、规划容量和管理资源。DBaaS模式还有助于减少数据和数据库的冗余度并提升整体服务质量。

最重要的是，解决方案提供商应记住DBaaS通常仅仅是解决方案的一部分。客户之所以与他们的解决方案提供商协同工作，不仅是因为他们出售的产品，而且还因为他们所提供的服务。DBaaS系统本身并不提供面对面访问或个人客户关系或持续不断的支持。这些就是需要解决方案提供商的原因。他们帮助客户选择正确的解决方案、规划集成和迁移战略，然后协助实施。

DBaaS的缺点

当然，这一切听起来不错，无疑DBaaS具有很多相对于RDBMS的优势。然而，DBaaS也有其局限性，云服务中固有的局限性就是之一。当客户开始将数据放入云端时，他们会遭遇到无法控制的网络性能问题。如果互联网服务提供商，支撑数据的云服务，或它们之间任一点网络被堵塞或中断，他们就会遇到与数据延迟或应用程序故障有关的问题。如果问题发生在企业内部，解决方案提供商可以排除故障找出原因。

此外，一些典型的RDBMS功能并不总是在DBaaS系统中可用。例如，Windows Azure SQL Database(以前的SQL Azure)是微软的DBaaS产品，提供了一个类似于SQL Server的数据库平台。然而，Windows Azure SQL Database并不支持数据压缩和表分区之类的功能，而且SQL Database支持的Transact-SQL语言只是完整版的一部分。另外，因为解决方案提供商不能控制物理资源，所以他们不能将数据文件和索引分配给特定的硬件。事实上，在任何DBaaS中，解决方案提供商对如何管理物理资源都没有控制权，因此他们可能会发现由于DBaaS的局限性使得他们提供给客户的远远小于客户所期望的。

此外，使用DBaaS能让收入损失从其他业务上得到弥补，如软件更新和硬件管理。也许决定走DBaaS之路的客户可能会跳过解决方案提供商，尽管这个决策看起来有点短视。另外，DBaaS会导致单一客户利润率的下降，因为云服务一般是依靠高客户数来抵消较低的利润率。

DBaaS的走向

尽管DBaaS模式有缺点，但它还是适合某些客户群体，这为解决方案提供商提供了新的商机。鉴于云服务的增长，解决方案提供商除了拥抱这些技术还有什么选择呢?如果他们不这样做，他们就会冒着被竞争对手击败的风险。但他们不能只想到如何把DBaaS的利润率与企业内部系统相比较。这是无法比较的，因为基于云的数据库提供了不同的模式。关键是要通过围绕云计算产品来包装其他增值服务以适应不断变化的市场条件：这就是DBaaS。

也许最好的策略是以不变应万变：给客户他们所需要的，不多也不少。如果DBaaS适合他们，他们就不应该买别的东西。事实上，云计算产业一直推崇自助服务，但提供这些服务的公司已经开始认识到解决方案提供商推销他们商品的价值。如IBM公司最近宣布让渠道合作伙伴分销其SaaS应用程序的新计划。微软认为合作伙伴是销售其云计算服务的重要组成部分。然而即使有这种趋势，DBaaS仍然不同于内部数据库，解决方案提供商必须认识到这一点；否则，他们不仅仅是丢失几个客户，而是要失去的更多。

行业数据应用托管不同于面向公众的数据托管(如Amzon的RDS等互联网公司提供的数据托管服务)，在数据服务方面存在以下特定要求：

(1)数据隔离要求。不同单位/部门出于安全等方面因素考虑，对托管的数据具有严格的隔离需求，因此难以采用当前SaaS多租户数据库中广泛使用的共享数据库(包括共享数据Schema和隔离数据Schema)的技术。

(2)性能隔离要求。不同单位/部门的数据应用具有不同的用户对象和使用模式，由此会产生不同的用户负载并进而占用大部分系统资源，从而影响其他租户请求负载的执行，即发生资源劫持，然而从租户自身的角度这种情况则是不希望发生的。

(3)可靠性保障要求。由于行业数据应用所需托管的数据资源具有较高的业务价值，提出数据托管需求的单位/部门在数据存储及数据访问的可靠性保障方面具有高于一般互联网用户的要求。

针对上述要求，提出一种无共享架构(Shared-Nothing)下基于虚拟机的数据应用托管方法及相应的数据库即服务系统。该方法的基本思想是为租户提供基于独立虚拟机的数据库托管环境，从而在满足不同租户数据库之间的数据隔离和性能隔离的前提下，同时使得不同租户数据库之间共享服务器以减少系统资源(CPU、内存和IO)使用量；同时，为了提高托管数据的可靠性保障，每个租户数据库至少建立两个数据库副本。在这种方式下，租户的数据库副本部署在虚拟机上，使得服务器资源可以分配给不同租户，从而能够灵活地控制租户数据库服务的服务器资源分配并保障租户间的数据隔离和性能隔离。此外，在无共享架构下，提出了支撑多租户数据库的虚拟机资源分配这一关键问题，该问题可以看作是如下优化问题，如何在服务器集群上为每个租户配置部署数据库副本的虚拟机所占用的系统资源，从而实现用最少的系统资源满足所有租户的数据库性能需求。按照上述思路，支持行业数据应用托管的数据库即服务系统包括以下三个层次的内容：

(1)数据托管基础设施层。该层次在一组共享的物理服务器环境基础上，通过虚拟机的形式提供对租户数据库的支撑，包括租户数据库虚拟机的创建及撤销、计算及存储等物理资源的分配与监控等。

(2)数据托管管理层。该层次是数据库即服务系统的核心，它对托管的租户数据库进行统一的管理、监控，并利用数据托管基础设施层根据数据请求负载对承载数据库的虚拟机进行动态资源调度(即CPU、内存等资源分配的调整)。

(3)数据托管应用层。该层次由归属不同租户的众多数据应用系统构成，由于数据托管管理层提供了标准的数据库服务，应用系统可以基于标准的数据库接口来完成对数据存储及数据访问等请求，而不必考虑数据实际部署的虚拟机、物理机器及网络地址等信息