《面向服务的计算和web数据管理》课件第14章

第14章云计算和软件即服务14.1引言

14.2SaaS的成熟度模型

14.3多租户SaaS的数据库设计

14.4GoogleApp引擎

14.5Google文件系统

14.6BigTable14.7MapReduce14.8Hadoop48014.9微软的Azure14.10S14.11优先级和调度

14.12云计算算法

14.13数据区分器的应用

14.14讨论

近来,云计算受到了极大的关注,因为它提供了一种新的计算基础设施,能够以动态的、可伸缩的、虚拟化的方式快速地把计算资源作为一种实用工具交付。与传统的基于桌面的计算相比,云计算的优势包括灵活性、低成本、设备独立、位置独立以及可伸缩性(Aulbach,2009)。最近,IT巨头如Google,Amazon,Microsoft和IBM都开始了他们的云计算项目。云计算和软件即服务云计算为客户提供了一种大规模的服务交付,并且允许客户以“即用即付”的方式灵活支付而不需要拥有IT基础设施或应用软件。这里,客户可以是应用软件或应用软件的终端用户,因此SaaS中的服务指的是软件模块以及终端用户可用的应用。

云计算通常有几个关键组成部分,包括：

(1)顶层：该层托管用户在应用中使用的软件即服务(SaaS)。

(2)第2层：该层提供了平台即服务(PaaS)。

(3)第3层：该层提供了基本的支撑,即基础设施即服务(IaaS)。

(4)第4层：这是最底层,提供了数据中心。14.1引言目前大多数云计算建立在现代数据中心上面,它把IaaS、PaaS和SaaS集成在一起,并以公用工具的方式提供这些服务,这样可按客户的使用情况进行计费。图14.1显示了云计算的层次化视图。

1.数据中心

该层提供了云运行的硬件环境。数据中心通常建立在能量利用较低、自然灾害可能性小、人口稀疏的区域。现代数据中心通常由数千台具有大容量磁盘存储和高速缓存的服务器组成,这些服务器通过高速网络连接。

2.基础设施即服务

IaaS建立在数据中心层之上,IaaS层虚拟化了计算能力、存储和数据中心的网络连接,并作为规定服务提供给客户。用户可以按需增加或减少他们的计算资源。IaaS比较典型的应用是,多租户共享相同的基础设施资源。IaaS层的例子如Amazon的EC2,Microsoft的Azure平台。

图14.1云计算的层次化视图3.平台即服务

平台即服务(PaaS)通常被称为cloudware。PaaS提供了一个集成了许多服务的开发平台来辅助应用的设计、开发、测试、部署、监控和云托管,并支持地理上分散的团队在项目中协同工作。它通常不需要下载或安装软件。Google的AppEngine,Microsoft的Azure,Amazon的MapReduce/SimpleStorageService都是PaaS层的例子。

4.软件即服务

SaaS按需把应用软件作为服务提供给终端用户,通常以浏览器的方式提供。它免去了用户部署和维护软件的麻烦。来自于云的软件是自动更新的,并且不需要购买额外的许可证。产品特征按需请求,并且频繁使用。SaaS应用通常是面向服务的程序,它可以很容易地和其他mashup应用集成。GoogleMap是SaaS的一个例子,它可以参与Web上的多种mashup应用。S和Zoho的生产及协作套件也是SaaS的例子。

这四层并没有明显的分界线。一层的组件和特征也可以认为是另一层的。例如,数据存储服务可以是IaaS层或PaaS层的。

在云环境中,每样东西都可以看做并被实现为服务。SaaS运行在云环境的顶层,它把基于Web的服务交付给客户,并把IT应用的功能、部署、维护的职责转移给服务提供商。客户虽然没有拥有软件但是要支付软件在Web上提供的服务。通常用户通过API访问Web上的服务。

PaaS运行在云环境的中间层,它通过使用IaaS提供的计算、通信和存储资源为SaaS的执行提供计算环境。这些功能传统上是由操作系统提供的,但是,和传统的计算系统相比较,PaaS有更多的资源,并需要实时处理数以百万计的用户。PaaS使用的一个通用技术就是虚拟化,并且它为终端用户或SaaS提供了许多虚拟系统。在一个典型的云环境中,IaaS可能有数千个甚至上万个拥有巨大存储容量的处理器。

注意,SaaS应用也可以看做是传统的服务,因为二者都是基于面向服务的计算并使用相同的面向服务技术,例如发布、检索、发现、本体、组合以及执行策略。然而,在以下几个方面,SaaS应用确实不同于服务应用：

(1)服务应用可以放置在本地计算机(如笔记本或台式机),或成为服务器支持的Web服务；相反地,SaaS应用必须是Web应用,并且必须运行在有巨大计算能力和存储资源的服务器之上。

(2)用户可以共享服务应用,但是每个用户看到的是具有相同功能的相同服务；相反地,用户共享SaaS应用时,每个用户可能看到具有不同用户界面和功能的相同SaaS应用。例如,用户可以定制用户界面并要求特定的项作为优先项显示。Gmail是一个典型的SaaS应用,用户可以指定用户界面并要求特殊的特征。在服务应用中一般不具有这一特性。这是SaaS的可配置性。

(3)SaaS应用通常使用多租户体系结构,相同的软件可以服务于具有不同特征的多个用户。然而,一个典型的服务应用没有多租户体系结构。14.2节将介绍多租户体系结构。

本章将涉及SaaS的基本特征和它们的实现策略。

SOA和云计算是相联系的,具体地说,SOA是一个体系结构模式,是用来指导创建、组织及重用计算组件的业务解决方案；而云计算是一组技术,为企业提供更大的、更灵活的平台来构建他们的SOA解决方案。换句话说,SOA和云计算是共存的、互补的和相互支持的。注意,SaaS应用的参与者至少包括下面的人员：

(1)终端用户：他们使用提供的服务并支付相应的费用。他们可以组成COI(兴趣社团)来分享他们的服务和经验。

(2)业务提供者：业务提供者影响、部署并支持服务的客户使用。

(3)服务提供者：服务提供者为用户创建、迁移和组合服务。注意,服务提供者不必提供服务运行的平台；他们可以使用公有云、私有云或混合云环境运行他们的软件。

(4)平台运营商：他们为服务从创建、部署、运营到退出的整个生命周期的管理提供了一个平台。公有云指的是每个人都可以访问。私有云指的是仅允许指定机构中的人员访问。混合云指的是部分资源可以公开使用,但是其他资源只允许指定人员使用。

一般来说,云计算有以下特征：

(1)面向服务计算：大多数云环境支持面向服务计算和SaaS。因此,云环境通常支持发布、发现及服务组合,这些服务包括应用服务和支持服务,例如信息服务、存储服务和通信服务。

(2)基于Web的运营：人们使用Web上提供的软件,当SaaS运行在PaaS和IaaS上时,这些软件通常是可用的。这一特征提供了设备和位置的独立性。

(3)动态供应的可伸缩性计算：典型的云环境将自动提供充足的资源完成一个任务请求。这可能涉及工作负载的自动监控、资源的自动分配、负载均衡、智能调度以及群集处理器上的并行处理。

(4)自动配置和定制的多租户体系结构：多个客户可以共享相同的软件,而不是每个客户使用一个单独的软件。这样,可以削减开发软件的成本,因为只需要开发一个软件版本。但是,每个客户仍然认为软件是定制的。

(5)可靠性和可用性：云环境通常有冗余资源,因此,如果系统的某些部分失效,系统其余部分可以自动从故障中恢复。此外,这一工作的完成不需要用户的知识,因为恢复工作由系统自动完成。

(6)隔离和策略实施的安全性：因为云环境通常提供了分散资源的集中管理,所以数据安全很重要。此外,在多租户体系结构中,彼此不认识的不同用户共享软件和数据库,用户要求较高的安全保证。为了确保系统的安全性,在运行期间强制实施多种安全策略。

(7)自动的系统维护和升级：云环境经常自动地维护它的资源,包括软件和计算机的升级。可以通过服务更新、软件配置和数据库设计进行软件升级；系统升级包括系统管理和硬件更换。此外,这些升级可能与用户使用各种云服务同时执行。

微软已经提出了如下的SaaS成熟度等级(Carraro,2006),其中每个等级在前一等级的基础上添加了新的特征。

1.等级1——随机的/定制的

这是最简单的等级,它类似于传统的应用服务提供者(ASP)模型。14.2SaaS的成熟度模型在这一级,每个客户有他自己定制的应用版本并在服务器上运行自己的应用实例。租户之间不存在共享并且软件的每个实例需要单独开发。通过把软件移到集中的服务器上为客户提供服务,现有的许多软件程序都将满足这一等级。图14.2说明了这一点。

图14.2随机的/定制体系结构2.等级2——可配置

该等级为软件增加了灵活性。每个客户有自己定制的软件版本；但是,在这一级上,客户通过选择同一软件提供的各种配置选项指定配置选择。在前一等级,每个软件版本是为客户独立开发的,但是在这一级,只需开发一个有许多配置选项的软件程序,让客户自己选择。与前一级相比,这一级的软件更成熟、更复杂,但是只需开发一个版本。由于开发者不需要为满足每个用户的需要而开发成百上千个版本,因此,这一级软件的管理和维护较容易。一般而言,定制化服务可是轻量级或重量级的：

(1)轻量级的变体：这些服务有不同的选项或特征,并且相同的服务使用不同的策略和/或SLA(服务等级协议)提供给不同的客户。例如,具有高级功能,如大容量存储、较好的用户界面、允许24小时访问的优质服务；具有标准特征,如有限的存储、普通的用户界面、只在特定时间内访问的常规服务。可配置的体系结构如图14.3所示。

图14.3可配置体系结构(2)重量级的变体：这些服务提供了不同的业务过程,包括行业相关需求、不同的基础设施以及通信需求。这些服务可能有相似的名字,但是如果你测试这些服务,它们是明显不同的。

3.等级3——可配置、高性能的多租户

这一级在前一级基础上添加了多租户体系结构,如图14.4所示。在这一级,所有客户将运行相同的软件版本；然而每个客户可以看到同一软件的不同配置。注意在前一级,每个客户看到的是一个定制的版本并单独地运行此版本,但是,在这一级,尽管每个客户看到的是一个定制的版本,但实际上每个客户与成千上万个其他客户共享同一个软件。很容易看到,这一级的SaaS软件比前一级的SaaS软件更加复杂。在前一级,尽管软件由客户定制,因为每个客户只能使用一个副本,因此它不需要处理运行时管理。但是这一级的SaaS软件需要解决这些新问题。SaaS软件需要追踪每个客户的单独配置、维护他们的数据库、在运行期间提供定制的服务。事实上,你可以认为这一级的SaaS软件后面有一个微型操作系统,它可以运行数据库,并在运行期间为成百上千个客户划分工作区。

图14.4可配置、高性能的多租户体系结构4.等级4——可伸缩、可配置、高性能的多租户

SaaS的这一级在前一级的基础上添加了可伸缩性,如图14.5所示。前一级SaaS软件的问题是不能伸缩。因为每个SaaS软件需要追踪成千上万个客户并提供实时服务,软件负载过于沉重。解决这个问题的一个方法是让等级3的同一SaaS软件有多个副本,并且在运行时每个都可以被调用以提供服务。客户不与SaaS直接交互,但是首先和一个负载均衡器交互,负载均衡器将每个请求分配到一个合适的软件副本上执行。负载均衡器不断地监控每个软件副本的工作量,并把客户的新请求分配到合适的软件副本上执行。如果工作量增大,运行在后台的副本数量增加；如果工作量减小,副本数量减少。这样,在服务器上维持合适的副本数量以提供最佳的性能。这一级的云环境比前一级的云环境更加复杂,因为在运行时负载均衡器要和多个SaaS副本交互。但这一级的云环境比前一级的云环境提供了更好的服务,因为它可以根据环境的变化调整资源。

图14.5可伸缩、可配置、有效的多租户体系结构不管是否有多租户体系结构,SaaS软件都可运行在VM(虚拟机)上。VM是实际机器或系统的隔离副本,多个VM可以运行在同一物理系统上。一个VM可以和一个OS一样大,例如,一个物理机可以运行多个OS平台为不同的客户服务。VM的概念并不新颖,因为它已经出现了至少40年。在那时,计算机非常昂贵,为了节省费用,多个OS平台运行在一个物理机上。

尽管40年以后计算机便宜了,但是VM的概念仍然被大量地应用,尤其在云计算中。因为在云计算中,应用和数据比物理机更贵重,但是许多应用只运行在某一平台上,所以为了运行这些应用就需要很多VM。注意,在云计算中,多租户体系结构和VM是互补的。虚拟化允许提供不同的平台而不需要大量额外的编程,但是,多租户为软件设计和编程提供了可伸缩性,因为只需要开发一个软件版本而不是独立开发多个软件版本。完全可以把VM和多租户体系结构结合起来实现可伸缩性和灵活性：VM为建立程序的执行平台提供了一种方便的方式,多租户体系结构用于软件的共享。

每个SaaS应用都有一个前台和后台。前台为SaaS用户定制需求提供条件,而后台使用一种低成本、一致的和可伸缩的方法支持客户。为了达到这个目标,多租户成为SaaS的一个重要特征。在多租户体系结构中,SaaS软件的一个单一实例支持多个客户。以这种方式,服务提供者可以同时支持多个租户,而从客户的角度看,租户是隔离的并按照他们的需求定制。14.3多租户SaaS的数据库设计多租户体系结构不同于多实例体系结构。在多租户体系结构中,运行在服务器上的一个软件实例为多个客户或租户服务;在多实例体系结构中,有多个(不同的)软件副本为它们的客户服务。多租户体系结构需要在内部对数据进行分区,并且需要追踪不同客户的不同配置。

据报道,目前的多实例体系结构可以支持几十个租户,而多租户体系结构可以支持更大数量的租户。但是,这要付出代价的,因为伸缩性增加,隔离级别降低。换句话说,潜在地,多租户体系结构需要阻止一个租户的QoS受到其他租户的影响,因为他们共享软件以及数据库。注意：等级1和等级2的SaaS主要使用多实例体系结构,本节主要关注等级3和等级4的SaaS应用。

多租户体系结构需要解决以下问题。

1.资源隔离

因为所有租户共享同一个基础设施和软件,所以SaaS应用以一种公平的方式为租户隔离资源就很重要。每个租户当然希望能够访问所有需要的资源以获得最好的服务性能,但是,在资源有限的情况下,这对于租户来说是不现实的。因此,系统需要指定租户的优先权,并为不同的客户提供有差别的服务。一个简单的方法是分配资源,例如,如果用户请求是规律的或经常的,就为SaaS应用静态分配CPU和存储器。但是,在一个云环境中,这是不可能的,因此需要一种动态分配模式。一个租户可以指定他的资源需求,如将来的使用模式,以便SaaS应用相应地调度资源。

2.定制

SaaS应用通常允许租户定制他们的服务,包括QoS需求。例如,GoogleDoc允许不同的用户指定不同的特征,包括软件的外观,可能在以后,也可以允许每个用户指定SLA(服务等级协议)需求。注意：在多租户体系结构中,每个用户使用软件的同一实例,因此任何定制信息需要存储在数据库中。为了提供定制服务,需要在运行时检索这些信息并使用。这增加了SaaS的灵活性,但是处理速度下降,因为在运行时需要额外的计算,还增加了数据库的复杂性,这是因为除了要存储各种数据,还要存储个人定制信息。

3.安全性

在多租户设计中,租户共享软件代码和数据,这导致了严重的安全风险问题：一个租户意外地或故意地访问另一个租户的数据。事实上,安全问题是云计算和SaaS的重要的问题之一。

4.可伸缩性

从成熟度1级到3级,伸缩性的考虑是软件设计和编码的问题。3级SaaS允许所有租户使用同一软件,因此明显地节省了软件设计和实现的工作量。但是,如果基础设施没有同一软件的多个副本,而这个软件是为提供服务而动态创建的,3级SaaS应用的可伸缩性就是有限的。

图14.6是一个简单的体系结构框架,用来帮助解决上面提到的多租户体系结构的挑战,显然它在创建和运行时都可以支持多租户。租户使用相同的应用实例而不会导致性能、系统安全性、隔离和可配置性的显著降低。

图14.6多租户实现框架在框架中有两种类型的开发者/用户：

(1)面向应用的开发者(在顶层)：他们负责开发或定制UI(用户界面)的内容、业务流程和服务,不需要了解多租户体系结构。

(2)面向基础设施的开发者(在底层)：他们负责以最低成本确保应用的有效性和可靠性。

多租户层是框架的核心,它隔离了应用和支持系统资源。租户可以获得多租户的益处而不用担心实现多租户体系结构的复杂性。14.3.1资源隔离模式

在多租户体系结构中,资源隔离是很重要的,其解决方案可以从完全隔离的设计到完全共享的设计。

1.独立数据库(SD)

这一模式中,每个租户有自己的数据库,与其他数据库相分离,这是一种完全隔离的解决方案,如图14.7所示。注意,尽管数据是隔离的,但是计算资源如CPU、存储设备、应用代码仍由租户共享。因为每个数据库与其他数据库相分离,所以每个客户的数据模型就相对容易扩展,这和传统的系统一样,并使用传统技术从故障中恢复。这个解决方案简单但是昂贵,因为独立数据库需要维护备份。如果一个SaaS应用有许多租户,每个租户需要一个独立的数据库,数据库的数量将会很庞大,并且这大大地增加了云基础设施的费用和开销。因此,这种方法的可伸缩性是有限的。

图14.7隔离的数据库2.共享数据库但隔离的模式(SDSS)

这一模式中,多个租户在同一数据库中存储各自的数据表,如图14.8所示,但是每个租户有他自己的数据库模式和数据表。当新租户出现时,系统使用传统的SQL语句为他创建一组离散的表和模式。这一模式容易实现,容易扩展。如果一个租户想要改变他的数据模型,其他的租户将不会受到影响,因为他们有独立的表和模式。

图14.8共享数据库和隔离模式3.共享数据库和共享模式(SDSHS)

这一模式中,多个客户共享同一数据库并在同一表集合中共享数据,如图14.9所示。这是一种灵活的方法,因为只有唯一的一组模式为所有的租户服务,并且系统只维护一个数据库。虽然这种方法对数据库的设计和维护很方便,但是一个系统缺陷可能损坏整个数据库,或把数据呈现给不同的租户。考虑一个由多租户共享的抵押贷款的数据库,租户ID是代表每个租户的主键并把它作为关联其他表的外键。因为它允许同一个数据库服务为大量的租户服务,所以在这种模式下,硬件和备份费用较低。然而,考虑到安全性问题,这种方法将是最复杂的。这种模式也很难从故障中恢复,因为整个数据库要恢复到以前的状态,而不仅仅是故障部分,但是系统不能精确地知道数据表的哪一部分出现故障。

图14.9共享数据库和共享模式从数据库角度看,多租户数据库系统提供的模式需要具有下面的灵活性：

(1)可以通过扩展基本模式来支持应用的多个专用版本；

(2)基本模式可以动态地变更和演化,并且扩展在数据库在线时完成。换句话说,完成扩展不影响服务提供者维护数据库。

把应用中的多个单一租户的逻辑模式映射到数据库中的一个多租户的物理模式不是很容易,因为企业应用通常允许每个租户扩展他的基本模式。如IBM文档讨论的,为SaaS应用设计灵活的模式有7种可用技术,可进一步把它们分为两类：

(1)数据库“拥有”模式(用DDL或数据定义语言明确定义)；

(2)应用“拥有”模式(映射到数据库中的通用结构)。

本节用一个例子来说明这些技术。一个SaaS应用有3个租户,每个租户都有一个包含AccountID(Aid)和Name字段的账户表。租户1属于宾馆行业,用Hotel和Rooms两个字段扩展账户表。租户3属于抵押行业,用Borkers字段扩展账户表。租户使用租户ID列(租户)共享表。分类1：数据库拥有模式。

用户视图：数据库视图用于共享数据库表,它只包含特定租户的数据。当出现一个新租户时,可以为其创建一个新的视图。

私有表：每个租户有自己的基本表的私有实例,可以根据需要扩展,如图14.10所示。而在所有其他的映像中,租户共享表。

图14.10私有表扩展表：扩展表是指将表垂直分割成单独的表,它们根据一个ID列连接到基础表,如图14.11所示。图14.11扩展表稀疏列：每个租户的每个扩展字段作为稀疏列添加到与它关联的基本表。如图14.12所示。图14.12稀疏列

一般而言,数据库“拥有”模式技术表现良好,但是对现有的数据模式的演化提供的支持有限,而且在某一级别上不能伸缩。

分类2:应用拥有模式。

XML：每个基本表通过列扩展,列中存储了XML文档中租户的所有扩展字段。这些文档会因租户而变化,因此它们是无类型的,如图14.13所示。

图14.13XML图14.14数据透视表“应用”拥有模式中,应用可以完全控制模式演化,但是在性能方面,可能受到很大影响。具体来讲,对于基于XML的解决方案,必须解析XML文档,然后重新组织行以处理那些扩展字段。性能的下降与扩展字段的数量成正比。对于基于透视表的解决方案,由于处理大型表的复杂性,使性能下降不止一个数量级。14.3.2安全性

安全机制是指防止一个租户获取访问其他租户数据的权限,目标是使多租户应用有一个与传统应用软件类似的安全保证。一般来说,实现数据安全有两种方法。

1.应用级别的过滤方法

对于SD或SDSS方法,可以使用数据库名或模式名控制相应租户的访问。对于SDSHS方法,过滤是通过每个表中的tenantID列访问与之关联的相应租户的记录来实现的。它容易实现,但为恶意访问留下了机会。例如,一个黑客可以使用‘tenantID＝XXXor1＝＝1’访问所有租户的数据。SQL语句如下面所示：SELECT*

FROMTENANTS_TABLE

WHEREtenantID＝2or1＝＝1

2.DBMS级别的许可方法

这种方法为每个租户分配一个专用的DB访问账号并且每个租户只有访问自己数据的权限,例如SD和SDSS方法。对于SDSHS,需要平衡DBMS提供的行级访问机制,也就是LBAC(基于标号的访问控制)。例如,假设一个租户在一个应用表中对自己的数据有SELECT权限,当这个租户执行一个SELECT语句时,LabelSecurity评估选定的每一行并根据安全管理员分配给租户的权限和访问标号来决定是否能够访问它。类似的,LabelSecurity可以对UPDATE、DELETE和INSERT语句进行安全检查。通过这种方法,可以防止潜在的SQL注入攻击。图14.15显示了LBAC的实体关系(ER)图。三种类型的安全标号授权给三种类型的数据库对象,分别包括行、列和用户。此外,一个安全标号可以由几个安全标号组成。DB2V9是一个例子,它提供了这种支持,并使用DB2S

ecurityLabel保存安全标号和为表提供安全策略。

图14.15LBAC的实体关系图可以使用一个预定义的LBAC规则集和安全标号进行比较。当比较两个安全表的值时,规则集中的一个或多个规则用于判定一个是否阻塞另一个。例如,在DB2V9中,有一个叫做DB2LBACRULES的单一规则集,它有16个预创建的安全标号组件。图14.16中,为了共享CUSTOMER_ORDER表,产生了一个称为“SecurityPolicy_Customer”的安全策略,它含有一组安全标号。在CUSTOMER_ORDER表中,使用DB2S

ecurityLabel列把每个租户和他的数据关联起来。每个安全标号包括一个从16个标号组件中选出的元素。

图14.16CUSTOMER_ORDER表的安全标号的实例当出现一个新租户时,操作员可以简单地选择一个未使用的标号,并使用如下所示的SQL语句把它授权给该租户：

GRANTSECUTIRYLABELSecurityPolicy_Customer.0001toUSERTenantXforallaccess

LBAC的优势是它可以控制DBMS级别的跨租户数据的访问,而不是应用级别的。但是,它也有局限性,例如在DB2中,至多支持16个安全标号和64个元素,因此租户的最大数量是1024(16×64)。对于云计算,这个数量可能太小了。14.3.3可伸缩性

可伸缩性是多租户的一个重要特征。随着工作量的增大,为了保持系统的性能,需要的资源与工作量成比例增大。可伸缩性有两种：

(1)向上伸缩或垂直伸缩：通过添加额外资源完成,例如在一个集群系统中,给一个节点添加CPU、内存以及磁盘。这样,由于拥有更多的资源,节点功能就更强大；

(2)向外伸缩或水平伸缩：通过给一个已有的集群系统添加额外的节点(处理器)完成。例如,一个集群系统原有30个节点,现在可以拥有50个节点。垂直伸缩容易使用,但是由于资源管理的开销,不能提供线性递增伸缩。水平伸缩提供了一个性价比更好的方法,它可以通过为廉价的硬件设施添加更多的资源来递增地扩展系统。此外,由于冗余,它可以提高系统的可靠性和可用性。

1.数据库分区

在垂直伸缩中,可以在同一物理机上创建多个数据库分区；而在水平伸缩中,可以在多个物理机上创建分区,并且每个分区有自己的内存、CPU和存储设备。数据库中的数据可以分布到几个分区中。分布码是一列用来判定数据存储在哪一行的分区。

数据库分区有两种方法：基于应用的分布码和基于租户的分布码。

(1)基于应用的分布码。这是数据库分区的传统方法,它根据领域知识,通过选择一个或多个属性作为分布码来进行分区。例如,“REGION”可以用做一个分布码。但是,这种方法需要一个合适的分布码来平衡多个分区的负载,并且需要数据剖面信息。考虑到多租户体系结构,这种解决方案需要更新,并解决相关的隔离问题。

(2)基于租户的分布码。这种方法把每个租户的数据存储在一个单一的分区中。它可以使用TenantID作为分布码。使用这种方法,通过设定或变更TenantID,可把租户自由地映射到任一指定分区。作为一种租户感知方法,它提供了比前一种方法更好的隔离性和可用性。此外,它可以通过开发负载均衡算法确保大多数分区有相同的负载。

2.表分区

表分区提供了一种创建表的方法,表中数据的范围分别存储。这种分区的优势是提高了查询性能并使表的改变更方便。例如,可以使用ALTERTABLE语句修改一个表。这要求用户对表的存储信息有清晰的了解,因此,它只适用于高级用户。

GAE(GoogleApp引擎)是一种在Google管理数据中心开发和托管Web应用的平台。它提供了似乎无限计算资源,并虚拟化跨多个服务器和数据中心的应用。GAE的基础设施使托管的Web应用容易伸缩,并使开发者从硬件配置和许多其他繁琐的系统管理任务中解脱出来。GAE处理程序把代码部署到一个集群上,并在必要时执行监控、故障恢复、创建应用实例。GAE被设计为语言无关的,然而,当前它仅支持Python、Java以及JVM兼容的语言。14.4GoogleApp引擎图14.17GAE应用体系结构的一个简化的Java版本常支持JDK1.5和JDK1.6。Google提供了一个eclipse插件用来帮助开发者创建、开发和部署GAE应用。编译后的应用被部署到Google云上的只读文件系统。GAE提供了一个管理控制面板,它允许应用管理员创建GAE应用,监控它们的运行状况,检查使用/限额信息。

任何持久性数据通过JDO/JPA接口写到数据存储中,数据存储类似于数据库服务。通过SDC(安全数据连接),GAE允许它的应用在公司数据库中检索数据并写数据,这使得企业系统和GAE的集成更容易。

GAE应用使用资源的数量最多到一定的限额。通用的资源包括请求数、输入带宽、输出带宽、CPU时间、数据库API调用、数据库查询。14.4.1服务

GAE通过JavaAPI暴露的服务如下：

(1)URL获取服务:它允许应用访问资源,并通过HTTP与HTTPS与Internet上的其他主机通信。

(2)邮件服务：通过GAE的邮件服务,应用可以使用Google的基础设施发送邮件消息。

(3)内存缓冲服务：内存缓冲服务是一个分布式的内存数据高速缓存,应用的多个实例可以访问它。

(4)图像处理服务：它提供了允许用户处理图像的API,如调整大小、旋转、压缩和翻转。

(5)任务调度服务：任务调度服务也可称为cron服务,它使应用在指定的次数或时间段内响应Web请求时能执行其他任务。换句话说,应用可以在处理Web请求的同时创建并运行后台任务。

(6)Google账户：为了鉴定用户,GAE把应用和Google账户集成在一起,它减少了开发者实现个人用户账户系统的工作量。如果用户已经拥有一个Google账户,它使用户能更快地使用应用。14.4.2数据存储

GAE使用数据存储服务Datastore存储和查询数据。Datastore是一个无模式的具有查询引擎和支持原子事务的对象数据库。该服务可以通过开源的DataNucleusAccess平台实现JDO(JavaDataObjects)和JPA(JavaPersistenceAPI)访问。

Datastore建立在BigTable之上,BigTable建立在GFS(Google文件系统)之上,因此当数据增加的时候,它可以很好地伸缩,并具有高可用性和高可靠性。GFS将在下一节进行讨论。虽然GAE的Datastore与传统的关系数据库具有类似之处,但实际上它们有很大区别。首先,Datastore是无模式的,数据实体的结构由应用代码决定；其次,它支持连接查询,但不支持多对多关系、分组和其他的聚合查询。

GAE的Datastore实际上是一个层次数据库,不同区域的实体在Datastore里有严格的分层(Barrett)。一个节点有一个父节点,也可以没有。如果没有父节点,这个节点称为根节点。根节点和其所有的子节点构成了一个称作实体组的实体集群。Datastore里的每个实体都有一个关键码,用来唯一标识应用里的一个实体。实体的本地码由实体类别和ID组成,ID可以是应用指定的名字或者Datastore指定的数值型ID。对于根实体,它的关键码就是它的本地码。子实体的关键码是一条路径,由根到子实体路径上的祖先的本地码组成。

GAE的Datastore使用了BigTable,它支持以下操作：读、写、删除、单行事务、前缀浏览和范围浏览。为了使用BigTable,Datastore按照不同BigTable服务的关键码分配存储实体的范围,以分布式的方式存储实体。因此,Datastore也可看做碎片分类数组(Barrett)。实体组成员在任何时间都处于同一BigTable服务中。用一个服务管理包含同一实体组的实体的事务,实现起来简单高效。目前,GAE仅支持一个实体组上的事务。

Datastore支持很强的数据一致性并使用优化的并发控制维护数据的一致性。事务中会发生实体的更新,这意味着它或者成功或者失败。事务操作在实体组的根级别上。一旦相同实体组内有更新实体的多个请求,就会发生竞争,获胜者可以执行更新,而其他的请求在固定的次数内继续竞争直到请求超时。与锁并发控制算法相比,这种方式具有更好的吞吐量(Barrett)。

Datastore默认在类别和所有的属性上创建索引,通过用户指定的配置文件创建多个属性的复合索引,所有索引通过BigTable实现(Barrett)。14.4.3开发可伸缩应用的提示

GAE用户或许使用以下技术开发可伸缩的应用(JasonCooperj):

(1)通过关键码、码的名称或ID检索对象/实体。与传统的关系数据库相比,GAE的Datastore更像是一个分布式的分类数组/哈希表,并且读操作高度优化。

(2)不使用偏移量分页,检索立即使用的数据。因为Datastore的查询最多可以返回1000个结果,如果超过了1000个,执行效率会降低。另一个原因是许多资源实际上被浪费了,因为大多数返回结果在使用前被丢弃了。

(3)保持实体组较小。由于事务的发生仅局限于实体组内,GAE对事务的支持是有限的。这意味着,大的实体组竞争概率大,并行度低,这限制了应用的吞吐率。

(4)碎片常写实体。对于数据,通过碎片技术,可以使写操作分布式和并行化。事实上,碎片化有效地把单个实体分割成许多片。当查询一个结果时,可通过查询所有碎片并组合查询结果快速得到计算结果。14.4.4开发工具

用于Java的GAESDK(软件开发工具包)包括：

(1)支持本地GAE应用开发和调试的本地仿真器,它有一个本地Web服务器和数据库服务。真实的GAE运行时的安全策略也应用到仿真器上。

(2)SDK包含了GAE中所有可用的API和库。

(3)EclipseIDE插件简化了GAE应用的开发和部署。14.4.5其他约束

考虑到安全因素,GAE应用运行在一个受限制的“沙箱”环境中,因此,有以下约束：

(1)GAE应用不能写文件系统,但允许从文件系统读。应用必须用Datastore服务写数据。

(2)不支持Socket通信或直接访问另一个主机。HTTP/HTTPS请求需要通过GAE的URL获取服务生成。

(3)不支持子进程或线程。Web请求必须在一个单一的进程中处理。

(4)有响应时间的限制。Web请求处理必须在30秒内完成,否则它将被终止。

(5)不支持系统调用。

GFS(GoogleFileSystem,Google文件系统)是一种支持查询和信息搜集的文件系统。它很可能是最大的文件系统。在查询和搜集时,由于Google依赖有效的文件访问,所以文件系统必须是高效的并且可伸缩。据Google报告,使用Google的用户数量在不断上升,有时高速上升。GFS技术成为Google向用户提供即时服务的关键技术,因而大量的工作量花费在GFS工程和再工程上。据Quilan报告(Quinlan,2010),GFS经过了重要的设计变更以满足不断变化的环境。14.5Google文件系统

S.Ghemawat,2003年提到了早期的GFS设计,后来做了许多改变,所有的文件被划分成64MB大小的块。大多数情况下,用户会在文件末尾追加信息或者读文件,因此GFS的设计支持那些操作。GFS运行在数以千计的廉价的处理器的Google基础设施之上。

GFS早期有几个关键的考虑和决策：

(1)系统结构应该开发起来简单,节省实现的工作量。

(2)系统使用数以千计甚至百万个处理器支持可伸缩的操作。

(3)由于数据庞大并且许多数据是流动的,所以不需要缓存。流动的数据是不需要缓存的。

(4)使用的廉价处理器可能会失效,系统至少应该提供三个副本避免这种失效。更多的副本可以增加系统的可用性。

(5)应当提供常见的接口和API,同时这些API应该支持常用的Google操作,如快照和记录追加。

(6)初步设计要具有高的吞吐量而不是短的延迟。注意,吞吐量和延迟本质上是冲突的。根据排队论(Lavenberg,1983),具有高吞吐量的系统一般上都有大的延迟,而具有低延迟的系统,它的吞吐量也比较低。第一个考虑导致了简单的设计,它允许Google把软件部署到市场上获取市场占有率。然而,由于更多的用户使用Google查询和获取页面,用户体验成为一个关键的问题。用户体验的一个关键是低延迟,因此,后来GFS做了相应的变更来解决这个问题。14.5.1GFS系统结构和操作

GFS系统有两类节点：用来管理元数据的主节点和用来提供数据存储的块服务器,如图14.18所示。为了节省时间,数据直接在客户/块服务器间传输而不经过主节点。为了高效处理,主节点总是驻留在内存中。

图14.18GFS体系结构主服务器存储和管理以下与块关联的元数据：

(1)把文件映射到块位置(64位)地址的表。

(2)把文件映射到它的副本的表。

(3)读写一个具体块的处理表。

(4)支持文件持久性的操作日志,日志中还包括块服务器失效后,使用文件复制时的信息以及可以恢复的检查点。

为了更新表实体,主服务器定期接收来自块服务器的更新。它也负责创建、复制和重新均衡块。块的重新均衡可以提高空间利用率和访问速度。同时,主服务器也负责回收垃圾。块服务器存储数据文件,每个独立的文件被划分成固定大小为64MB的块。每个块有唯一的64位的标识,同时维护文件到组成块的逻辑映射。每个块也有一个检测系统故障的64位的校验码。在系统中每个块至少有三个副本,而需求量大的文件有更多的副本。块服务器运行在Linux上并维护数据的一致性。

如果一个进程需要访问某一块,它首先必须获得主服务器的许可。在检查一个具体的块可用(也就是没有其他进程正在使用它)之后,主服务器提供块服务器地址,允许此进程在一段时间访问这个块。在这期间,此进程可以访问这个块服务器,而为了维护系统的一致性,其他的进程不能访问这个块服务器。进程和块服务器直接交互,不受主服务器的干涉。如果进程更改了这个块,这个更改被传送到这个块的副本所在的块服务器上,在收到所有副本所在块服务器的确认之前,系统不会提交。这通过主块服务器管理。

早期,Google使用的GFS有200多个集群、5000多台机器、5＋PB大小的文件系统、在硬件频繁失效情况下单个集群上每秒40GB的读写负载。由于越来越多的人使用Google,GFS有了显著的改进。

注意,GFS不是作为OS内核的一部分实现的,它的许多操作用户可以直接使用。由于任何文件系统访问不需要经过OS功能调用层,这提高了系统性能。传统的系统调用,如OS中进程的创建,开销是比较大的。14.5.2GFS开发中的经验

本小节重点讨论主节点。从一开始,Google就知道单一的主节点存在问题。然而,Google仍然决定采用这种方式,并且这也是最早作的决定。这个决定使GFS能够快速实现并部署到市场中。考虑到这一方面,Google做出了正确的决策。

然而,当越来越多的人使用Google时,许多问题变得突出,特别是文件大小的增加,从几百万兆到几千万兆,然后到数亿兆。主节点上元数据数量急剧增加,因此主节点上的负荷也急剧增加。并行MapReduce的使用对此问题没有帮助,由于上百万的MapReduce操作需要同时访问文件,主节点的负载会急剧增加。注意,主节点一直驻留在内存中,元数据信息量会随着时间显著的增加。

失效的单个节点也会对某些应用,如视频服务,带来不好的结果。而且,刚开始,GFS对主节点没有自动恢复计划。因此,当主节点失效时,将需要很长一段时间恢复。Google的解决方案是生成影子主节点,它存储主节点状态的快照以快速恢复。此外,初步设计的目标是高吞吐量,而延迟是其次考虑的问题,后来才强调了低延迟。根据排队论,吞吐量和延迟是冲突的。服务器偏爱高吞吐量的系统,而用户却被长时间延迟。低延迟系统得到用户的喜爱,但系统因此要向用户提供支持快速服务的能力。Google的解决方法是通过冗余操作确保任何失效可以容易地隐藏,因为失效导致了大多数延迟。例如,如果一个写操作失败,而没有可用的冗余操作,这个失败的操作会导致系统明显延迟。GFS有两个写日志,如果一个失败,另一个会立即接管。由于相同的原因,主节点需要多个影子副本。此外,GFS通过容错机制支持并发读写,因此,和典型的文件系统相比,它的一致性模型更复杂。根据(Quinlan,2010),这是问题的根源,尤其是允许多个写操作同时执行时。

Google也尝试采用多单元方法,它在数据中心上创建多个单元,用这种方法,多个GFS主节点将运行在一个块服务器池上。这也需要应用把数据划分到不同的单元上。14.5.3其他类似项目

其他分布式文件系统也是可用的。如HadoopHDFS(Hadoop)、CloudStore(CloudStore)。HDFS和Cloudstore几乎是同时开发的。HDFS使用Java语言,而为了提高效率,CloudStore后台采用C＋＋语言。

HDFS也把文件划分成64MB的块,存储在一组机器上。与GFS相似,它通过在多个主机上复制数据实现可靠性。每个主机都可以和其他主机进行通信完成数据复制。类似于GFS,HDFS也有一个唯一的服务器,称为节点,如果它不工作了,文件系统就不可用。恢复后,需要执行以前所有的命令确保文件系统的一致性,整个过程需要较长的时间。

CloudStore具有与GFS类似的体系结构,它有三个主要组件：

(1)元数据服务器,它提供全局的名字空间；

(2)阻塞服务器,文件像GFS一样存储在块中；

(3)客户库,它提供文件系统的API,实现应用和CloudStore的连接。

CloudStore是一个开源程序,它复制了Hadoop项目的许多特征,包括数据完整性、C＋＋语言访问、Java和Python语言访问、复制和可伸缩性。

HDFS的一个特征是写操作要求从文件的开始写起,直到到文件的结尾,实际上,任何写操作都是整个文件的完全重写。然而,KFS允许在任何位置写,也可以追加一些内容到当前的文件。KFS也支持简单的自动负载均衡机制,因此系统可以把数据从拥塞的节点移到不拥塞的节点,但是HDFS没有这样的机制。

BigTable用于处理Web应用的大量的半结构化数据。例如,URLs(包括内容、搜集的元数据、链接、导航和网页级别)、用户喜好数据(包括个性化设置、最近的查询/检索结果)、地理位置(包括诸如商店和餐厅类的物理实体、道路、卫星图像数据和用户标注)。因为拥有1012数量级的URLs,每个URLs有多个版本/页面,每页有约20KB的数据、上亿的用户,每秒有上千的访问请求,并且有超过100TB的卫星图像数据,因此,这个数据量是非常庞大的。14.6BigTable有人可能使用商用数据库开发Web应用,如Oracle、DB2和SQLserver等,但是这些数据库系统多用于商业计算,而不是用于Web应用,很多底层优化无法做到。因此,Google决定开发在存储和数据传送操作方面有很多底层优化机制的BigTable。

BigTable欲达到如下目标：

(1)它能异步和无间断处理请求。

(2)它能支持高达每秒百万次速率的读/写操作。

(3)它能从搜索到的网页中扫描所有的或感兴趣的数据来识别需要的信息,并在巨大的一对一或一对多数据集上执行join操作,这是涉及许多数据集的复杂计算。

(4)它能随时检查并跟踪数据变化,这对搜集信息很有用。如果一个Web页没有改变,没必要再次搜集相同的网页。

(5)它能存储各网页的历史数据,为数据挖掘和分析提供统计信息。

(6)当请求数量和数据规模随时间增加时,它能在性能上进行伸缩。将来数据的规模肯定会增加。

(7)它能以内建的容错机制提供可靠和高可用的计算与数据服务。基本上,BigTable是一个分布式存储系统,而不是一般意义上的、建立在数千台廉价服务器上、管理PB(1015数量级)级字节的大型结构化数据的数据库管理系统。目前,BigTable每天能高效、可伸缩、高可用地处理PB级字节的数据。BigTable的最初设计开始于2004年,它目前广泛用于Google服务中,包括Google分析、Google金融、Orkut社会性网络服务、个性化搜索、Writely字处理软件和Google地球。14.6.1主要构件

BigTable有如下主要构件：

(1)GFS：提供可伸缩的Web文件系统支持；

(2)Scheduler：提供大量机器之间作业调度,并监控任何机器的错误,在必要时重新调度；

(3)Lockservice：是一个分布式锁管理器,提供对小文件的可靠管理；

(4)MapReduce：用于读写BigTable数据。

BigTable集群管理一个分布的运行不同类型应用的机器共享池,这个集群管理系统把作业分配到不同的机器,管理共享机器上的资源,监控机器状态,处理运行时错误。系统的体系结构如图14.19所示。

图14.19BigTable集群的系统结构图14.6.2BigTable概述

1．数据模型

BigTable实质上是一个稀疏的分布式多维存储图。图的索引是一个由三个部分组成的字符串：行关键字、列关键字和时间戳,定义如下：

(row:string,column:string,time:int64)>string

图14.20是一个存储在“”的Web页中的表的切片。

图14.20BigTable的数据模型

(1)行：行关键字是任意的字符串(最多64KB,大多数用户使用10～100Byte),对行的数据访问是原子性的,由事务处理支持。行的建立隐含在存储数据之上。BigTable按字母顺序对行关键字排序,并根据一个或少量处理器动态划分行的范围。每一行范围被看成一个数据片,它是分布和负载均衡的基本单元。这样便于阅读,并利用本地化原则的优势使访问更加有效。这些工作的完成是通过遍历URLs的主机名称部分获取相同域中的信息,然后把相关信息组织在一起形成一些连续的行。例如,一个人可以在/index.html中存储/index.html的数据。在相同域中存储同一领域相互紧密关联的Web页具有空间和时间上局部化的优势。一个用户访问一个页很可能在最近的将来(时间局部性)访问相关的页(空间局部性)。

(2)列：Web页被划分为若干个集合,称为列簇(Columnfamilies),是访问控制的基本单位。列簇通常存储相同类型的数据。列簇仅在列关键字产生以后创建,并在那个创建关键字的表中使用,因而不同列簇的数量很小,且在操作过程几乎不变。列关键字的词法是：family:［optional］qualifier,其中列簇名字应当是可打印的,限定符是任意字符串。例如：一个可能的簇名字是“language”,它存储每一个Web页的语言标识(ID)。访问控制和磁盘/存储费用在列簇级上执行。

(3)时间戳：BigTable可存储通过时间戳索引的相同数据的多个版本。时间戳是一个64位整数,它要么被BigTable赋值成以毫秒表示的“实时”时间,要么被客户应用明确赋值。为避免冲突,应用需要产生独一无二的时间戳。最近时间戳的版本存储在第一位,不同的版本按降序存储。为了自动进行垃圾回收,客户要么指定一个单元的最近n个版本,要么保存足够多的最新版本。

2．实现结构

数据片(Tablets)：为了让数据分发至不同的机器,BigTable按行把大表分割成若干数据片。一个数据片存储若干邻接行,在任何给定时间内,数据片都是单个机器管理的基本单位。每个数据片有起始和结束行的关键字,大约存储100～200MB大小的数据。

给定一个服务器,它可能负责约100个数据片,因为按这个比率,它能很快执行恢复和负载均衡。例如,如果一个机器失效,100个其他机器通过每台从失效机器上抓取一个数据片的办法进行恢复。主机也可在某机过载时,把这个机器的一些数据片移到另一台机器上。数据片的例子如图14.21所示。

图14.21示例数据片

当数据片过大时,例如,大于期望的兆级字节时,数据片被一分为二,如图14.22所示。

图14.22划分数据片使用数据片时,有几个问题需要说明：

(1)定位数据片。

因为数据片会从一个服务器向另一个服务器移动,“给定一行,客户如何找到正确的机器？”。每个数据片有一个起始和结束行,因此可以通过查看每个机器的数据片范围识别出数据片。一种方法是使用BigTable主机存储每个机器的行范围,但当数据片数量巨大时,中央服务器将变成系统的瓶颈。

另一种方式是,存储一个包含BigTable中定位数据片信息的表。数据片的“3级层次查找模式”如图14.23所示。位置用相关服务器的IP：端口表示。在第1级,它从一个锁服务器开始,指向根数据片的拥有者。在第2级,使用根数据找到合适的元数据数据片的拥有者。在第3级,元数据表保存所有用户表的数据片位置。图14.233级层次查找模式特别说明,为避免根数据片成为瓶颈,BigTable使用主动预取和缓存方法。

(2)数据片服务。

为存储数据,BigTable使用Google的SSTable文件格式。SSTabler提供一种长久有序且不改变的从主键到值的映射,键和值都定义成任意的字节型字符串。数据片的持续状态存储在GFS中,如图14.24所示。更新时,当前提交的数据存储在缓冲区的内存中,旧的更新存储在SSTables集合中,提交日志记录所有的还没有提交的变化。当一个写操作到达数据片服务器时,服务器首先检查它格式是否正确、发送者是否有改变数据的权限。如果是,写操作被处理。写操作提交后,相应内容被插入到内存。当一个读请求出现时,服务器在执行读操作前执行相同的检查。读操作的执行基于SSTables集合和内存的合并视图,如图14.24所示。

图14.24表的表示(3)数据片压缩。

每个数据片的状态表示成内存中一个不变的SSTable压缩文件,并以一个日志缓冲作为结束。BigTable提供两类压缩：辅压缩和主压缩。辅压缩在内存满时发生,系统可选择带有多数数据的数据片并把内容写入GFS的SSTable。另一方面,系统周期性地执行主压缩,把所有SSTables打包成GFS中新的基础SSTable。

(4)数据片服务器。

BigTable能够处理数千数据片服务器。假定每个服务器拥有100个数据片,将会有1M数据片。每个机器上的所有数据片共享一个日志。否则,一个集群上的一百万数据片将导致写太多的文件,而且,同时写1M个日志会使得性能急速下降。

通过使用共享日志,每一个表服务器有一个用于存储它上面的所有数据片的写日志,并在同一个日志文件中更新多个数据片。因为每一个数据块为64MB,因此当不断更新时,新的日志块将会频繁创建。共享日志存在的一个问题是,在恢复期,服务器需要读日志数据进行数据片的变更,如果大量数据片需要恢复,并且很多机器从同一日志块中读取,则可能导致I/O的极大浪费。共享日志的恢复机制如下：当一个机器不工作时,主机重新分布它的日志块到其他机器去处理,这些机器在本地存储处理的结果。想获得数据片的机器从主机中查询处理结果的位置,以更新它们最近获取的数据片,然后直接访问这些机器获取数据。

3．APIs

BigTable的API支持通过函数调用创建和删除表、列簇,改变集群、表和列簇的元数据以及访问控制优先级。而且BigTable支持从单个行查询,或在表中的数据子集上不断迭代查询。

例：下面的C＋＋代码使用RowMutation抽象执行一系列的更新。

//Openthetable

Table*T＝OpenOrDie("/bigtable/web/webtable");

//Writeanewanchoranddeleteanoldanchor

RowMutationr1(T,"edu.asu.www");

r1.Set("anchor:","ASU");

r1.Delete("anchor:");

Operationop;

Apply(&op,&r1);

调用对Webtable执行了一个原子变化：它给添加了一个导航并删除了另一个导航。

4．其他数据库方法

注意,GFS和BigTable被设计为专用于基于Web的云计算,因而它们的设计不受传统数据库管理设计或文件系统的约束。因为Google确实不存在数据库管理或文件系统,所以可以从头开始一个新的设计。Cattel调查了很多其他的具有相似目标的类似数据库系统的设计,他认为这些系统的特征是数据存储而不是数据库,因为这些系统不提供传统数据库系统管理的全部特征。这些现代数据存储具有如下共同特征：

(1)支持调用级交互(而不是绑定到SQL语句),因而应用可能直接控制数据库的存储。

(2)有效的索引以利于大数据量的有效处理。

(3)通过把不同行分配到不同服务器,支持可伸缩性。因此当行数增加时,用户不会感到过度延迟。

(4)支持动态数据模式,因而不同租户虽然有不同的数据模式需求,但他们仍然共享相同的数据存储和模式表。

(5)索引在内存中缓存以得到有效的访问,这可能会在不同的节点中分发或复制索引。这些数据存储据根以下原则存储数据：

(1)关键值存储:系统根据一个设计者定义的关键字存储数据。

(2)文档存储:系统存储索引文档而不是文档中的特殊项被索引。

(3)可扩展的记录存储:系统存储可扩展的记录,并且按不同节点划分它们,这有时被称为面向列的数据库。

这些现代数据存储的例子包括SimpleDB和Cassandra。

另一个方法是扩展现有的数据库管理系统用于Web应用。例如RAC(OracleRealApplicationClusters)。它是一个集群数据库,并在访问单个数据库时允许多个处理器运行数据库软件。集群数据库本质上是运行在处理器集群上的数据库,它利用了这些便宜处理器的伸缩性和可用性。

集群数据库可被分为两大类：

(1)无共享：每一个参与节点拥有一个数据子集,每个节点只运行它自己的数据,但是节点间可相互通信交换数据。

(2)全共享：每个处理器可以访问数据库中的任何数据。

任何一种情况,节点都通过诸如infiniBand或Myrinet的高速网络互联。有高速网络把集群和存储器连接起来是致关重要的。最初,集群数据库使用诸如磁盘的存储设备来传送数据,当存储设备速度很慢时,操作速度也会慢。在采用诸如光纤信道技术的专用通信系统用于系统和存储器通信后,这个问题得到了解决。光纤信道是用于存储器网络的网络技术,它的传送速度达Gigabit,它是SAN(存储器局域网)的通用技术。在2008年,这种技术能以5100MB/s的吞吐量传送21.04GBaud的数据。

无共享和全共享两种集群数据库都需仔细地对应用划分以达到优化性能的目的。无共享体系结构的可伸缩性依赖于数据划分。这种方法的一个问题是如果一个节点崩溃,数据的一部分将无法得到,因而通常数据的划分应保证数据实际存储在后台的多个磁盘上,如果其中一个失效,其他的磁盘可以自动再存储相应的数据。这种无共享的集群数据库方法被很多数据库系统使用,例如IBM的DB2、Microsoft的SQLServer、MySQL的Cluster和Bizgres的MPP。

在全共享体系结构中,物理设计通常涉及网络附加存储器,通过诸如光纤信道的高速互联网络,所有节点都和诸如RAID的独立共享磁盘通信。在这种体系结构中,当多个处理器同时访问同一数据库时,它们之间会有竞争。RAC是一个全共享数据库,每个处理器有自己的缓存,有必要通过高速网络协调各种并发读写以维护系统缓存的一致性。RAC有一种叫做缓存融合的机制。一般来说,数据库系统将面临如下情况：

(1)并发读；

(2)不同节点的并发读写；

(3)不同节点的并发写。

第一种情况不是问题,因为多个读用户能没有任何冲突地并发读数据。但是,处理第二和第三种情况时,缓存融合维护全局控制器,全局控制器维护每个节点上每个缓存块的状态。如果存在冲突,全局控制器要求拥有数据的节点通过高速网络传送大量最新数据到接收节点,而不需要通过磁盘系统,从而维护了系统的一致性。当缓存数据被替换或在检查点时,实际数据写入磁盘的操作将会发生。基本上,传统数据库管理系统中的并发控制现在是在缓存级完成的,并由支持处理器到处理器和处理器到存储器两种通信的高速网络支持。全局控制器通过涉及缓存管理、数据通信、并发读写的复杂协议维护数据的一致性。每个写用户仍然需要声明一些排它性,其他写用户必须服从且等待它的写操作完成,除非修改的数据是可用的,并且当它们在不同的节点上时,将通过高速网络从一个缓存传送到另一个缓存。因为全局数据控制器完成的大多数操作要么是在计算节点、要么是通过高速通信系统完成的,因而操作比传统的通过磁盘参与的方法更有效率。因为并发写比并发读消耗更多的时间,这种全共享方法更适合大多数是读操作的应用。

如果多租户应用有很多写操作,数据划分变成一个关键问题,因为同步多个写操作比同步读操作消耗更多时间。

使用全共享方法的有：IBM的用于z/OS的DB2、IBMDB2pureScale、SybaseAdaptiveServerEnterprise、ClusterEdition。

MapReduce是一个分布式编程模型,可用于处理用廉价处理器集群搭建的云计算环境中的海量数据集(Ghemawat,2004)。这种计算模型起源于函数式程序设计语言Lisp中的map和reduce函数。但是,MapReduce的含义和操作不同于map和reduce函数的含义和操作。用户可指定一个map函数处理一个关键字/值对,以产生一个中间值,一个reduece函数合并全部的中间值以得到最终结果。这两个函数能运行在不同的计算机上,主机为工作节点分配处理任务。14.7MapReduce14.7.1MapReduce编程模型

图14.25展示了一个MapReduce体系结构,它有一个主节点和多个工作节点。

图14.25MapReduce体系结构

计算分两步完成：

(1)Map：主节点接收输入(