SaaS模式、技术与案例详解——第12章 数据存储

【本章导读语】

不积跬步，无以至千里。

________《荀子.劝学篇》

信任，或是缺乏充分信任，都是妨碍SaaS推广的首要问题。我们可以说，关于产品、客户、雇员、供应商等的数据是商业运营中最重要的资产。当然，SaaS的核心也是数据。SaaS应用使客户能通过网络集中存取数据，成本低于使用本地安装的应用。不过，为了充分发挥SaaS的优势，企业必须在一定程度上放弃对自身数据的控制，要在确保数据安全并避免泄密方面充分信赖SaaS服务商。

为了赢得客户的信任，希望开展SaaS业务的架构师首先应创建成熟稳定、安全可靠的SaaS数据体系结构，使用户和客户都能够放心地将重要的商业数据交给第三方合伙伙伴进行管理和控制，而且该架构还应该能够以极低成本实现高效管理和维护。

12.1 数据存储的需求

一家公司的用户使用我们的SaaS应用服务存取客户信息时，该用户连接的应用实例同时可能还会为其他几十家，甚至是数百家公司的用户提供服务，各用户之间彼此互不知情。这就要求应用架构能够最大化不同用户间的资源共享，不过仍要区分属于不同客户的数据。所以，我们在设计存储结构的时候，一方面要考虑结构本身的可扩展性，一方面还要考虑数据访问的安全性。

1.数据访问控制

数据是不是安全，会不会被没有权限的人窃取或篡改，这是用户最关心的，因此也是我们最关心的。安全问题涉及的内容也确实是非常多，笔者这里试着从几个方面简单进行阐述：

（1）过滤：在用户和数据源之间加入中间层，给用户的感觉是数据库里只存了自己的数据。

在这方面，典型的手段是采用视图。

（2）权限：采用ACL来限制谁能访问什么数据，以及可以对数据作什么操作。

在这方面，有一个很关键的问题是如何建立一个受信任的连接。比较常见的方式有服务器模拟客户端用户的身份（impersonation）去访问数据；或者服务器始终以自己的进程身份来访问数据（受信任的子系统方式），额外的安全都放在应用的内部。前一种方式配置上比较复杂，但安全性较高；后一种方式不需要太多配置，但安全性较低，并且有些资源单靠服务器进程本身的访问级别是访问不到的。我们在开发的时候可能需要混合使用这两种连接方式。

另外，有些时候可能需要服务器以代理的方式来访问一些其他资源。

（3）认证（Authentication）

前面几点说的都是对于某个特定的用户，系统如何控制他的访问权限（也就是说，都属于授权/Authorization方面的问题），那么系统如何知道某个客户端请求确实是来自某个用户呢?这就是Authentication要做的工作。单就这一部分，包含的知识也相当多，以Asp.net2.0为例，就有Windows验证、基于表单的验证等；单就Windows验证，又有Kerberos，NTLM等不同的验证协议，这些验证协议在对代理服务器的支持、运行效率上都是有差别的，需要我们学习和掌握。另外，在.Net3.0中，MS在这一块儿好像又提出了一个新的概念和实现技术，CardSpace。这个技术里应该是凝结了MS对网络安全的最新思考，笔者觉得应当重点关注（此技术和Active Directory, WCF, Windows Live ID等技术都有很强的相关性）。

还有，从宏观上来看，认证的方式分为集中式认证（centralized authentication system）和非集中式认证（decentralized authentication system）两种，我们需要研究它们之间区别和联系，结合起来利用。

（4）加密

对用户的敏感数据进行加密，为授权方及时获得了这些数据也派不上用场。可以采用对称或非对称的加密算法。非对称算法的保密性好，但处理开销也大得多。实际操作中，一般是两种方式混用，即数据采用对称加密法，但用非对称加密法来加密对称密钥。

其实，和安全相关的问题还有很多，比如sql注入，代码安全等等，这里就不一一详述了。

12.2 数据存储的分类与选择

12.2.1 数据存储的分类

数据存储是SaaS系统中一个相当重要的问题，在设计SaaS系统的数据库时出于满足客户需求及降低开发成本的考虑，在数据的共享和隔离之间求得一定的平衡是必须考虑的一个重要因素。

因此一般在设计对应数据库时不仅要考虑到技术因素，例如怎样构建一个弹性架构以支持数目不定的客户、怎样消除大容量并发访问数据库对系统性能造成的压力以及怎样允许用户按需扩展自定义数据等；同时也必须将商业因素纳入考虑范围之中，例如架构在该SaaS系统上的业务应用主要面向哪些行业的客户、目标客户对于数据存储方式是否有基于一定法律法规的要求等等。一般而言，SaaS系统的数据存储有如下三种形式：

图12-1 SaaS数据的三种模型

l 独立数据库存储

将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。

图12-2 独立数据库模式

在应用这种数据模型的SaaS系统中，大部分系统资源和应用代码还是由所有的客户所共享使用，但物理上每个客户有自己的一整套数据，而且单独存放。系统将借由元数据（Metadata）来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。

显而易见的是，一旦每个客户拥有其独立数据库，那他将可以轻易的对其做个性化的修改来符合其实际业务需求，而且如果系统出现异常情况需要将历史备份数据重新恢复的话，也将是一项轻而易举的工作。但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。作为一种对应的解决技巧，系统可以定期使用例如SQL Server 2003中提供的Auto-close功能将暂时没有活动连接使用的数据库实例从服务器的内存中移除，因此每台服务器可以更灵活的支持相对较多的客户访问，但这也只能在一定程度上缓解服务器的压力。

当客户由于所处行业因素或其它商业因素的限制，愿意支付额外的费用来做到数据隔离，确保数据安全，这种独立数据库的数据模型将是最为适合的解决方案。举例来说，处于银行业或医疗行业的客户们经常会有非常强的隔离数据的需求，这些客户甚至可能根本不会考虑去使用任何不提供客户独立数据库支持的SaaS系统。

l 共享数据库存储单独模式（Schema）

第二种方式则是所有客户使用同一数据库，但各自拥有一套不同的数据表组合存在于其单独的模式之内。

图12-3 独立模式

　在这种数据模型下，当客户尝试第一次使用该SaaS系统时，系统在创建用户环境时会创建一整套默认的表结构，同时将其关联到该客户的独立模式。此时一般使用SQL CREATE命令来创建模式，同时授权一个用户帐号来访问该模式。举例来说，在SQL Server 2005中可以使用如下命令：

以下是引用片段：
CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso

接下来，系统可以使用SchemaName.TableName来访问该客户的模式：

以下是引用片段：

CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary

key,Resume Nvarchar(MAX))

　一旦模式创建完毕，它将成为该客户所属用户帐号访问的的默认模式。

以下是引用片段：
　ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema

一旦默认模式设置完毕，在使用该客户的用户帐号进行SQL语句操作时就不要再使用SchemaName.TableName来指定特定的数据表，而是只需要指明表名即可。因此在系统代码内一句简单的SQL语句就可以应用于所有客户，而且每个客户仅访问到自己的模式内的数据：

以下是引用片段：
　SELECT * FROM Resumes

这种客户独立模式的方式相对比较容易被实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由的对其中的数据结构进行新增和修改。一般在最初创建该客户的模式时，系统会预先创建一整套默认的数据结构，但在那之后，客户可以对其做个性化的修改来符合其实际业务需求。

这种客户独立模式的方式在数据共享和隔离之间获得了一定的平衡，它既借由数据库共享使得一台服务器就可以支持更多的客户，又在物理上实现了一定程度的数据隔离以确保数据安全。

但这种解决方案的一个不利之处就是当系统出现异常情况需要将历史备份数据重新恢复的话，流程将变得相对复杂。因为如果每个客户拥有独立数据库的话，那么只需恢复该客户最近的数据库备份即可。但在独立模式下，如果简单的恢复数据库备份，那就意味着数据库内所有客户的数据将一同被恢复，无论该客户是否数据受损或需要做数据恢复与否。因此，在独立模式下，如果系统管理员希望恢复某个特定客户的数据，需要将数据库的备份解压到某临时服务器空间内，然后选定特定客户的表数据将其覆盖到系统主数据库内，一般来说，这将是一项非常复杂且耗时的工作。

这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下，比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量，减低了服务供应商的运营成本。因此一旦SaaS系统的潜在客户们不介意其数据与其它客户的数据物理上存放在同一数据库内，这将是SaaS系统开发商一种理想的选择。

l 共享数据库存储 共享模式（Schema）

第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。

图12-4 共享模式

在所有这三种数据模型中，这种共享模式的方式具有最低的硬件成本和维护成本，而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表，因此可能需要在保证数据安全性上花费更多额外的开发成本，以确保一个客户永远不会因系统异常而访问到其它客户的数据。

在这种共享模式的方式下，恢复备份数据的流程类似上文提到的共享数据库但独立模式的方式，系统管理员解压备份数据至临时服务器空间，选定需要恢复的数据表，而且还需要额外的选定所需要恢复的客户记录，再导入到系统主数据库内。如果此时有大量记录需要导入，则系统的数据库服务的性能将受到很大影响，而且所有正在使用系统的客户也将受到影响。

如果SaaS服务供应商需要使用尽量少的服务器资源来服务尽可能多的客户，而且潜在客户们愿意在一定程度上放弃对数据隔离的需求来获得尽可能低廉的服务价格，则这种共享模式的方式是非常适合的。

l .活动目录

如果我们所有的数据都取自关系数据库服务器，那么可能永远不需要活动目录。但有些资源是存储在文件系统中的，这就需要活动目录为我们提供存取服务了。我们需要研究原有的Active Directory技术，以及刚提出的ADAM（Active Directory Application Mode）等技术。

事实上，由于SaaS应用渐成趋势，市场上提供此类数据整合的产品也层出不穷，AppExchange列出它能够与具体的应用程序方便地进行整合的工具和与更广泛的集成平台等范围更广的工具。SalesCentrix公司的AccountDynamics能够把Salesforce.com的数据与QuickBooks集成在一起。还有位于加州Redwood City的Ipedo公司的XIP，能够为复杂的企业架构创建一个虚拟的数据服务层。

12.2.2 几种最有代表的SaaS数据库

l 云存储

目前，无论是产品服务还是技术服务，厂商都把重心放在了客户上，存储行业也不例外。随着信息爆炸时代的到来，客户群逐渐扩大，无论是企业用户还是个人用户，数据都呈几何级的爆破性发展，数据量从GB增长到了TB，甚至更大，这对存储厂商的压力越来越大。据统计，大约有85%的数据存储在个人电脑或比较独立的服务器之中，这些数据不仅分散形成了信息孤岛，而且大多数数据没有被保护，存在着丢失的风险。针对这种情形，一种叫做“云存储”的概念呼声越来越高。

云存储简单地理解就是把用户硬盘上的数据放到一个统一的地方进行管理，并且提供统一的服务。

云存储一般具有海量存储、随意读取、实时扩容、动态扩展、StorageasaService（SaaS）、统一管理、超长安全机制以及资源共享等八大特点。

然而云存储不仅仅需要设备，还需要管理软件，而WebDisk就是一款网络文件管理系统，采用了先进的云存储概念，可以管理超大容量的存储空间，提供持续的、高带宽、高可用、自动负载均衡的网络存储，用户只要连接到因特网，就可以管理存储在远程WebDisk系统上的文件，就如同管理存储在本地的文件一样，还可以共享文件。

据介绍，WebDisk最大的亮点就是采用了P2P技术，通过把P2P技术和传统传输方式结合在一起，通过客户端共享带宽的方式，使传输效率大大提高。其次，WebDisk还具有重复数据删除技术，当客户使用云存储服务时，系统能够监测到用户传输的文件是不是已经在云存储服务器端，如果在，客户就不需要再上传这个文件了，大大提高了传输效率。另外，WebDisk还能提供超级保险箱功能，可满足电信运营商数据文件集中存储、自动备份、远程共享等需求，实现企业内部各部门、各员工之间的数据集中存储、共享、备份。

云存储最大的发展亮点就是架构在Internet上的新兴存储服务。

l SSDS

SSDS（SQL Server Data Services，SQL Server数据服务）基于SQL Server数据库架构，支持基于标准的REST（表象状态传输）和SOAP（简单对象访问协议）界面，可应用于任何网络开发工具套件。采用面向结构化数据存储的“云计算”架构。是继BizTalk Services后，微软推出的另一个运行于Web之上的软件服务。

微软强调，SSDS可以被用来构建大型数据库应用，使用基本的数据操作语言通过互联网协议对其进行访问，应用对象是那些对关注系统扩展性、需要简化数据库编程及对数据存储查询能力有较高要求且成本敏感的开发者和商业用户。

l QuickBase

Intuit自2000年起提供名为QuickBase的SaaS数据库服务，目前已经拥有22500多家付费用户。QuickBase的用户通常是非技术商业用户

l Trackvia

Trackvia公司则表示其SaaS数据库服务在易用性和存储性能方面将比微软SSDS更出色。Trackvia公司总裁Chris Basham指出，目前数据库领域的最大需求在于为非开发人员提供与数据库交互的更便利方式，而这正是Trackvia所擅长的。Chris还强调，虽然微软SSDS同样承诺交互的便利性，但是由于它以SQL Server 2008作为引擎，性能提升将会经历一段持续更新的过程，而Trackvia则准备立即更新界面，并添加关系域等特性，向“真正的关系型数据库”看齐。

l EntERPriseDB

EntERPriseDB的SaaS数据库服务目前正处于测试阶段。“我们的服务在推出时将具备完整的关系型数据库特性，能够与微软SSDS进行直接的技术对抗”。EntERPriseDB的CTO Bob Zurek说。他同时认为，Web 2.0新兴厂商对开源技术的偏爱将阻碍微软在这一领域的发展。

12.2.3 如何选择合适的数据存储

上述几种SaaS系统的数据模型各有其利弊，因此在为特定的SaaS应用选择适合的数据模型时，必须考虑到下列因素：

表12-1 影响数据模型选择因素一览表

l 成本因素

基于数据共享设计的SaaS系统要求较高的开发成本（因为基于数据共享的系统架构相对比较复杂），因此初始投入较大，到长期来看运营维护成本则相对较少。

而基于数据隔离设计的SaaS系统则由于所需要硬件会随着支持客户数的上升而快速上升，因此相对初始投入尚可，但长期来看会有一个比较高的运营维护成本。

图12-5 成本因素

总体而言，选择数据共享的方式从长远角度可以为SaaS服务供应商节省大量的金钱。但远在其最终开始盈利之前，该类系统在开发中就已经需要大量的初期投入。如果无法投入所需的开发资源，或者由于商业原因需要将所开发的SaaS系统尽可能快的投放到市场，则选择数据隔离的设计模式更为恰当。

l 安全因素

通常在SaaS系统中会存放有很多敏感的客户业务数据，因此客户会对确保数据的安全性有很高的期望，SaaS服务供应商与客户签署的服务条款中会需要包含很多数据安全保障条款。当然，一般客户常见误解是只有采取数据隔离方式设计的SaaS系统才能完全确保数据的安全性；事实上，采取数据共享方式设计的SaaS系统一样可以在使用了一些成熟的设计模式之后，为客户提供很强的数据安全保障。

l 客户因素

一个SaaS系统将来所服务的潜在客户的数量、商业背景乃至其业务需求都将在很大程度上影响数据模型的选择，下面就是一些常见的可能会影响到决定的一些因素。

估算该SaaS系统所期待的潜在客户数。到底是为数以百计的客户设计这一系统还是数以千计，又或者更多数量。简单的说，如果计划支持的客户数目越大，就应当越多地考虑使用数据共享的模式。

估算每个客户平均使用的数据存储空间。如果使用该SaaS系统的客户可能会存储海量数据，则独立数据库模式毫无疑问是最佳选择。

估算每个客户平均所需要支持的终端用户数。如果这个数字越大，则越应当考虑采用数据隔离的模式来满足终端用户的需求。

决定是否为每个客户提供类似于数据备份之类的增值服务。一般而言，采用数据隔离的模式比较便于实现这类服务。

图12-6 影响数据共享与隔离模式的选择的因素

l 法律法规因素

公司、组织和政府机关经常需要遵守特定的法律法规的要求从而影响其选择使用哪一类的SaaS系统，而这种影响一般体现在对数据安全性的关注上。因此在设计一个SaaS系统之初，就必须对可能会影响潜在客户的法律法规做一定的调研，尤其是开发企业管理软件时，由于诸如财务、雇员管理、生产等诸多模块都会受特定地域或行业法律法规的影响，因此这些因素必须在系统设计之初就纳入考虑范围。

l 综合技能因素

对SaaS系统开发商而言，设计一个单实例多用户支持的系统架构仍然是一个很大的挑战，要想熟悉对应的开发工具，掌握相应的开发环境，也需要一支具有相当技术实力的开发团队。相对来说，选择数据隔离的模式来开发SaaS系统允许开发人员更多的从以往的开发传统架构的软件的经验中受益，对于技术力量不强的开发商而言不失为一个明智的选择。

面对越来越令人眼花缭乱的产品，Brocade公司的首席信息官Marti Menacho对于考虑部署SaaS的那些公司提出了一点忠告——重点是得到一致的数据定义，采用主数据管理等规则以及在整个企业范围内的良好的数据映射。

12.3 数据存储的安全性

数据存储必然是安全的，不安全的数据无法取得用户的信任。数据存储的安全性体现在数据可安全访问，数据能极时备份并能恢复。

12.3.1 数据安全访问

SaaS本身是一个从服务提供商到各个企业，从企业到各个部门，从部门到每个最终用户的树状管理结构，这样的一个结构包含一些可以利用的技术特点：

1. 安全权限的继承性

系统的授权（Ahthorization）一般都是根据用户组/角色/Role来进行的，在对授权的管理上，MS提出了一个“配置域”的概念。存取控制由配置域管理。每个配置域根据应用的关系策略继承上级配置域的角色、许可和商务规则，并可在适当的时候对其进行修改、添加和删除。从概念上来说这是非常合理的，比如一个企业内的部门是一个配置域，它的上级配置域就是企业，而下级配置域可能会具体到每个最终用户（也可能是部门内的小组）。但具体实现的时候如何去做，还需要我们进一步研究并给出方案。

2. 用户的不同等级

按MS的文档，将用户区分为“用户”和“最终用户”。其实这里的“用户”指的就是一个单位或组织，不同“用户”之间的数据至少在逻辑上是互相隔离的。而“用户”可以为自己企业内部的多个“最终用户”授权，最终用户最终能在用户的控制之下访问到用户数据的一个子集。

这种把用户分成等级来处理的方式是很有意义的，比如在建立受信任连接的时候，就可以采用用户模拟和非用户模拟两种方式的结合。对用户采用模拟方式，对最终用户采用非模拟方式。比如在存储结构设计的时候，可以给用户单独建立数据库。

3. 企业用户数据分类

关键数据：企业商务运行过程中必需的系统级或应用级数据，或由于法律因素必须保护的数据。

重要数据：企业商务运行过程中需要的应用级数据，短时丢失不会影响企业的生存。

敏感数据：每天操作都需要使用的数据，如果丢失，很容易恢复。

关键数据：一般是指已进行备份的并对安全性要求较低的数据。

对于一些敏感数据及非关键数据，通常我们可以通过从硬盘到磁带迁移数据及回迁的方法减少对磁盘的需求。

对于非常重要的数据及关键数据，我们通常采用硬件镜像的方法来保护数据，传统的方法是通过企业级物理磁盘到企业级物理磁盘间的镜像来实现的。

图12-7 数据安全访问控制

l 数据存储安全架构

为了很好地实现平台系统的高性能和易用性，我们推荐采用1台IBM 610小型机做为平台服务器，1台IBM NAS 201作为平台服务器的网络存储单元。我们以10000左右个用户来计算，如果每个用户的日志等容量为10-20MB，则大约需要200GB的存储空间，所以在201中配置4块容量为73.4GB的硬盘，同时，考虑到平台系统中数据的重要性，在IBM NAS 201中添加1台内置的IBM 3580磁带机，作为磁带备份。图12-8是数据存储解决方案网络拓扑图。

图12-8 数据存储解决方案网络拓扑图

l 数据安全访问

1．数据加密功能

对用户数据进行高强度的加密和解密以实现数据的保密。

2．抗抵赖功能

用户的数字签名（鉴别）实现登录用户认证和不可抵赖。

返回带数字签名的回执实现用户不可抵赖。

3．防篡改功能

完整性校验功能防止信息传输过程中被篡改。

4．访问控制功能

通过安全代理和证书来实现对用户加强身份认证，给用户划分不同权限规则检验功能。

5．日志和审计功能

通过syslog来记录系统日志，并进行审计。

6．用RSA密钥算法，支持标准PKI－CA系统

支持国密办批准认可的加密算法。

支持多种硬件密码平台。

采用公开密钥和对称密钥相结合的密钥体系。

图12-9是数据安全访问的过程。

图12-9 数据安全访问

12.3.2 数据备份恢复

我们以IBM Tivoli存储管理为例来解决数据备份恢复问题。IBM Tivoli实现了真正的数据中心备份与恢复的最佳解决方案。通过IBM高性能的计算中心处理网络分布性计算与数据异地存储。系统可以跨平台，大型的ERP等业务与开发语言无关。支持多种离线设备。可接入第三方不同的业务系统。数据及时备份、灾难恢复等管理。图12-10是IBM Tivoli 存储管理结构图。

图12-10 IBM Tivoli存储管理

12.3 数据库设计

数据库系统是指数据库厂商提供的数据库服务器，目前著名的大型数据库系统有Oracle、DB2、Informix、Sybase，中型数据库系统如Microsoft SQL Server。

而应用软件的数据库则是指开发者在数据库系统中创建的库，用于存储应用软件的数据。一般地，人们可以从上下文判断“数据库”究竟是指哪一个？

数据库设计的主要工作是：

（1）设计数据库的表（数据就存在表里面），表的结构就是数据的存储结构。

（2）对这些表中的数据进行操作，常见操作如查询、插入、修改、删除等。

数据库设计的难易程度取决于两个要素：“数据关系的复杂程度”和“数据量的大小”。如果应用软件只涉及几张简单的表，并且数据量特别小，那么设计这样的数据库就非常容易（例如设计一个班级的学生成绩单数据库）。但是您绝对不能盲目乐观：以为所有的数据库设计都是那么简单。

l 开发与平台无关的数据库应用程序

目前国际上应用最广泛的数据库系统有Oracle、DB2、Informix、Sybase和SQL Server。这些数据库系统之间的激烈竞争即有好处又有坏处。竞争的好处是使数据库系统不断发展和完善，并且避免价格垄断。竞争的最大坏处是逼迫数据库厂商不断开发出独特的功能以吸引更多的用户，所以各个数据库系统的独特功能无法形成统一标准，导致用户难以开发出与平台无关的数据库应用程序，因为用户很难抵御数据库系统独特功能的诱惑。

SQL是数据库系统的标准查询语言。可是数据库厂商提供了太多超出SQL标准的特色功能，使人们陷入了进退两难的境地：（1）如果您想使程序与数据库平台无关，那么只能使用SQL，放弃各个数据库系统的独特功能。（2）如果您超越SQL，使用了某个数据库系统的独特功能，那么这样的程序就是与平台相关的。

类似问题也存在于操作系统、Web浏览器这些领域。理论上讲，只有绝对垄断才能形成绝对统一的标准，但是人们既希望打破垄断又希望有统一的标准，这种矛盾无法彻底解决，只能折衷、妥协。

如果您开发的是通用的数据库应用软件，不想让应用软件与特定的数据库系统捆绑在一起，那么您就老老实实地用SQL语言写程序。

如果您开发的是行业专用的数据库应用软件，并且这个行业已经指定了数据库系统（这种局部垄断现象普遍存在），最近若干年都不会改变的话，那么您可以超越SQL使用该数据库系统的独特功能（例如公安部采用Oracle，银行采用Informix）。

l 数据库性能优化问题

数据库设计的主要挑战是“高速处理大容量的数据”。如何优化数据库的性能是设计人员经常面临的问题。数据库性能优化主要有两种途径：“优化表结构本身”和“优化数据库的环境参数”。

在表的物理设计阶段，设计人员应当按照第三范式设计表结构（即规范化处理）。这样做的好处是：表中没有冗余数据，表结构很清晰，将来修改或者扩充非常方便。但是按第三范式设计也存在一些缺点：产生了许多表，每个表有相对较少的列，并且这些列必须使用“主健/外健”关联起来，因此某个查询操作可能会产生复杂的表链接，导致性能降低。

反规范化处理是指对第三范式的表进行修改，通过合并一些表，或者在表中创建冗余的列，从而减少表链接操作代价，达到提高性能的目的。要注意的是反规范化处理存在很大的负面影响：管理冗余数据很麻烦，如果冗余数据不同步的话，那么会发生数据错误这种严重的问题。

对表进行第三范式的规范化处理是第一重要的，而反规范化处理则需谨慎考虑、不宜过多使用。“规范化处理”以及“反规范化处理”不是自相矛盾之举，而是性能优化的策略。

除了优化表结构之外，优化数据库的环境参数也能够提高数据库的性能。例如给服务器配置更快的CPU，增加内存。运行数据库是非常消耗内存的，内存对数据库性能影响比较大。由于现在市场上的内存条越来越便宜，所以为服务器配置足够多的内存恐怕是成本最低、难度最低、见效最快的性能优化方法。

能否有效地优化应用软件数据库的性能，主要取决于开发者对数据库系统的熟悉程度以及开发经验。

l 数据库设计流程

数据库设计一般要经历“逻辑设计—>物理设计－>安全性设计－>性能优化”等步骤，通常要迭代进行。

图12-11 数据库设计流程

12.4 数据存储解决方案

12.4.1 TSM解决方案

TSM（Tivoli Storage Manager）软件是IBM存储管理经验的结晶。TSM是为解决企业级数据及系统安全而设计的备份全面解决方案，为石油、金融、电信等许多大型企业，解决困扰信息技术部门的备份管理问题。它在节省成本的前提下向您提供有保证的、自动、简单而且灵活的服务。Tivoli TSM的管理架构，真正适合企业管理级管理需求，为企业提供高效、自动、可扩展的备份管理体系。

北京瑞飞信息技术有限公司（石油地球物理勘探局信息中心）是国内最早应用TSM的企业之一，并同时把TSM应用在数据备份和数据管理领域。在此方面，我们有着非常丰富的使用经验，并且是国内最早在TSM基础上进行技术开发的企业。

现在，使用TSM企业备份解决方案可以解决各种数据备份、归档问题；使用瑞飞公司在TSM基础上开发的Data Management System（DMS）可以解决石油、数字媒体、金融、电信等各种数据管理系统的海量数据存储管理问题。

l TSM应用案例

在机房内，我们将在一台机器（IBM RS/6000服务器）上安装Tivoli TSM Server作为备份服务器，专门伺职备份。存储设备（磁带库）接在该备份服务器上，在需备份的客户端（UNIX、WIN/NT等）安装TSM Client端软件。以下为示意简图：

图12-12 IBM TSM网络结构图

图中AIX、SUN、Win/NT等机器代表了现有的应用系统和一般桌面用户，在上面安装TSM Client端，它们通过TCP/IP协议与TSM Server连接。TSM Server可以是专用的服务器，或者是借用业务不繁忙的服务器，可以是IBM AIX、SUN，也可以是运行NT的PC服务器。应用系统或数据库的数据通过网络送达TSM Server，TSM Server管理这些备份数据，将它们存放到磁带子系统中。运行数据库Oracle、SAP系统的RS/6000再安装Tivoli Data Protection for Oracle以及Tivoli Data Protection for R/3，用以备份数据库和SAP应用的数据；运行MS SQL、MS Exchange系统的NT再安装Tivoli Data Protection for MS SQL以及Tivoli Data Protection for MS Exchange，用以备份数据库和MS Exchange应用的数据。

图12-13 IBM TSM数据存储结构图

l 方案的特点

1. 高度的扩展性和广泛的操作平台支持

TSM提供对各种高性能外围存储设备的支持，TSM支持39多种客户机平台和8种服务器平台，并且支持250多种存储设备，再一次体现了在配置方面的灵活性。目前，TSM Server和Client之间可以通过多达7种网络传输协议进行备份数据的传输，支持以LAN、SAN和拨号网络等多种连接方式。

2. 集中式的自动存储管理

TSM服务器可以监控所有应用服务器的备份作业，也可以修改其备份策略，同时，TSM提供多种的定时数据备份方式，客户甚至可以方便根据自身的存储管理要求编写备份脚本且纳入TSM的定时机制中，这些定时机制可以在TSM、应用、操作系统三个层次中实现，以可以满足客户对存储管理的特定要求。

TSM可以通过WEB BROWSER登录到任何一台TSM Client进行数据的备份和恢复。同样的，也可以通过WEB BROWSER登录到TSM SERVER上进行管理。这意味，只需在一台机器上，就可以实现TSM系统的集中式远程管理。

3. 高性能的数据备份和恢复

² TSM提供后台关系数据库的支持，从而使恢复和备份速度大大加快。

² 支持备份和恢复过程中的断点再续。

² 在备份和恢复过程中，TSM都提供了多线程的数据流支持。

² 通过磁带的数据分类集中存放，可以将同类型的数据集中存放在一组或一个磁带上，从而在恢复时保证以最少的磁带恢复，大大加快了恢复速度。

² 通过磁带数据的自动重整，减少磁带碎片，提高磁带的利用率，节约客户成本，保证数据的可用性。

² 支持在SAN环境下的LAN-FREE数据迁移。

² 提供永远的增量备份，通过先进的技术手段减少需备份的数据量，最大限度的提高备份工作的效率。

² 提供Web Proxy Server（TSM代理服务器），减轻在多个备份进程同时发生时TSM服务器的负担。

² TSM提供了SELF-TUNING的调试工具，可以指导系统管理人员进行性能优化。

² 在TSM的系统配置文件，提供了一系列的参数优化TSM系统。

4. 广泛的应用支持

TSM通过Tivoli Data Protection模块对应用数据库进行在线热备份，目前，TSM支持Oracle、Informix、Lotus Domino/Notes、MS SQL、MS Exchange Server、SAP R/3 on Oracle/DB2,对于DB2数据库，TSM可以提供全面的支持，直接通过TSM就可以实现DB2的在线热备份。

对于Oracle、Lotus Domino、Informix、MS Exchange Server，TSM结合TDP模块，可以实现在SAN下的LAN-Free数据迁移。

5. 安全的存储管理解决方案

管理的安全是保护应用数据的重要因素，TSM提供管理员的多重的权限定义，实现多层次的管理方式，TSM的管理员和TSM Client的用户严格区分。因此，客户可以根据实际的存储环境和安全要求定义不同级别的管理员和用户。同时它允许用户授权进行数据恢复。TSM提供集成的一系列安全防范措施，提供对IP地址窃取、中断、加密等影响安全的操作，保证备份的安全管理。

TSM的数据传输格式为经过加密处理的TSM独有的二进制格式，可以保证数据在备份和恢复过程中的完整性和安全性。而且，在每次数据备份和恢复时，TSM都会自动进行CRC的数据校验，以保证数据的完整性。在进行数据恢复时，用户需要经过三重的安全验证，只有验证通过，才能进行数据的恢复。所以TSM的备份数据的安全性可以得到有效的保障。

TSM在磁带中的保存格式是TSM独有的格式，只有通过TSM数据库的配合，在TSM系统内部才可以将备份数据读出。而且，在每次进行数据备份时，TSM会检查介质的可用性，如果遇到错带，它会拒绝使用，防止数据备份的失败。TSM系统会在备份时在每盒磁带的带头写入一些TSM的控制信息，当进行数据恢复时，系统会自动进行这些信息的校验，如果信息校验失败（如插入错误的备份磁带），系统会拒绝使用，这可以有效的保证备份数据的完整性。

对于Oracle、Domino等应用的在线热备份，TSM通过TDP模块在应用系统所在的机器执行，也可以通过TSM的定时机制实现集中的存储管理。在定时机制执行时，并不须依赖系统的ROOT权限，可以直接通过TSM的内部安全机制实现。

6. 高可靠性的存储管理系统　

TSM对它的数据库和日志提供多达三份镜像（Mirror）保护，以防止单一备份失效和系统崩溃后给整个系统带来的灾难性破坏。

TSM对其后台数据库和LOG文件可以进行备份和快速恢复。由于TSM的后台数据库是一个关系数据库（在文件系统中以一个加密的文件的形式存在），所有的系统数据都保存在数据表中，可以有效的防止由于系统数据的分散（包括物理的分散和逻辑的分散）造成的单点故障，并且可以对其后台数据库和LOG文件提供多达三种的数据备份方式：全备份、增量备份、SNAPSHOT（只备份LOG），这样可以减轻系统管理人员的负担，而且，通过对LOG的备份，TSM自身可以实现定点的恢复。

TSM提供对IBM HACMP/CLUSTER的支持，当一个节点HACMP/CLUSTER出现故障，HACMP/CLUSTER切换节点后，TSM继续其数据备份的工作，并且保证数据的一致性。

对于复杂环境下的数据备份，可能会同时有多台客户机同时提出备份的请求，这样存储服务器的负担将非常的大。TSM提供了Web Proxy Server（TSM代理服务器，可以安装在另外的机器上）的功能，对这些请求按优先级进行自动的队列，这大大的减轻了TSM服务器的负担，提供了更好的可操作性和扩展性，由于Web Proxy Server与TSM服务器和TSM客户机的通讯采用加密机制（SSL），这也提高了整个TSM系统的可靠性和安全性。

7. 强大的存储设备管理

TSM备份管理可以将磁带有效的管理起来并建立电子标签；即使人工标签脱落导致发生混乱，也可以通过电子标签快速查询介质上数据的内容。TSM能够自动跟踪所有介质的去向和使用情况。TSM不仅自动管理磁带库、光盘库中的介质，还能跟踪放在磁带库、光盘库外的介质和保留在异地的备份介质。

TSM在介质管理中采用了独一无二的“磁带集中”和“磁带重用”技术。“磁带集中”使每个客户机的每天的备份数据都对应放在一盒或一组磁带上，使得TSM能够用最少的磁带数做恢复。这是一种迅速、可靠的数据恢复方式。

“重用”的目的是使磁带库或光盘库介质自动轮转，完全实现备份、恢复的无人值守。原理是：当介质上的过期数据越来越多并达到一定限度时，比如介质上80%的数据都过期了，TSM会自动把数个这样的介质的残余数据整合到一个介质中，而其它介质重新进入新的介质轮转中去。所以，如果用户有足够的存储容量，TSM可以做到真正的“零管理”。

在进行对备份数据存储时，TSM通过在不同的存储设备中建立不同的存储池来实现数据的分层存储和迁移，对于一些大文件，TSM可以指定直接存放在磁带上，这样可以减少对主机IO资源的消耗，也能提高备份的效率；对于一些小文件，可以先将小文件暂时存放在硬盘的存储池上，进行数据的重整，当这些文件达到一定百分比时（由系统管理员设定），再一次性的存放在磁带上，这样可以大大减少磁带的MOUNT带和就位时间，提高了数据的备份效率，数据的存放也更科学合理。

8. 强大的灾难恢复

TSM的灾难管理功能（简称DRM）能够指导用户如何操作来迅速恢复企业范围内的各种数据。

自动、准确的DRM功能帮助用户保护宝贵数据的安全性。在TSM管辖内的数据，都能通过DRM自动策划、准备及制作备份恢复计划，一旦DRM生成了计划文件，所有服务器上最新的相关信息都被收集起来，以备恢复。

如果灾难发生，DRM提供恢复步骤的详细文档，可执行的描述文件自动恢复数据、重建环境。DRM使得企业可以很快回复正常运转。

DRM智能化管理和跟踪备份介质的转移。帮助管理员决定哪些介质本地保存，哪些介质需要异地保存。当恢复灾难时，DRM帮助用户迅速找到所有需要的介质，无论这些介质是在本地或运输途中或在异地的保险柜里。

TSM客户端追踪管理功能帮助系统管理员了解哪些系统被灾害摧毁，以及这些机器所需要的软硬件，以便用户决定需要重新定购哪些设备来替换损坏的设备。其他DRM记录的重要信息包括：需要恢复的各台机器的优先级；相关人员的连续方式等。

同时，对于异地数据保管和恢复，TSM提供了一个独特功能：Instant Archive and Rapid Recovery。这个功能是在TSMserver上将所需要恢复的数据影像到其它的可移动存储介质中，如普通8mm tape、可写CD等。管理人员再将这些存储介质拿到需要恢复的设备上，利用TSMClient的功能将这些数据恢复到系统中即可。这个功能即可以帮助客户将最为重要的数据复制到CD或磁带中永久归档保存；又可以在网络出现故障时，作为解决远程恢复问题的辅助手段。Instant Archive and Rapid Recovery在功能上类似于UNIX的系统备份。这种脱机恢复方式可以允许系统恢复到任意符合要求的设备上，为分析，开发，备份提供了更大的灵活性。

9. 提供OLAP存储环境的分析工具：

TSM内置了Tivoli Decision Support for Tivoli Storage Manager，它收集TSM每次执行任务的情况，包括状态、性能等，然后给出详细的分析资料和变化趋势。针对存储管理的特点，给出量化的指标。而且，Tivoli Decision Support 还支持通过Internet定时进行分析数据的发布，从而为一个集中的管理要求提供了技术上的可能。

对今后系统管理和升级的考虑：

作为一家专业而全面的系统管理解决方案提供商，Tivoli的软件覆盖了系统管理（包括硬件、操作系统、网络、应用的监控和管理）、安全管理、存储管理等范围，而且，Tivoli所有的产品都可以良好的集成在一起，通过一个统一的界面就可以实现系统管理的所有功能。在系统管理的基础上，Tivoli同时还提供了基于业务管理模式的统一控制台，决策和多维数据分析工具等，这些增值的功能可以增强企业的竞争力。因此，企业可以先从存储管理着手，在保证应用数据可靠性的基础上，通过软硬件的综合扩展，采用统一的系统管理支撑平台，可以逐渐建立起一套全面的高度集中的高效率的系统管理机制，包括应用系统的管理、网络管理、安全管理、存储管理等各方面，以满足企业发展的需求，通过成熟的IT管理架构，最大限度的提高企业的管理水平和服务水平，减少成本，最大限度的满足目标客户的需求。

TSM可以通过Tivoli Plus Module和Tivoli的其他产品无缝集成，包括Tivoli的系统监控、事件分析处理工具、网管、安全模块等，从而构成一个完整的系统管理解决方案。

TSM系统可以根据客户的需求平滑的升级到灾难恢复系统，实现应用级的数据复制。事实上，利用存储管理软件作为灾难恢复系统的基石，构建灾难恢复系统，相对于其他的灾难备份系统，存储管理软件作为灾难备份恢复系统，具有以下独特的优势：

² 成本低，通过存储管理实现灾难恢复，可以充分利用企业现有的存储设备，减少了企业在设备上的投资。

² 风险低，由于这种灾难恢复系统可以分步实施，每一步都有明确的目标，对于客户来说，这都是可控的。

² 操作简单，对技术人员要求低，许多的步骤都可以自动执行，即使遇到意外的特殊情况，由于系统操作人员一般都熟悉存储管理软件的基本操作和原理，可以第一时间得到及时的处理。

² Tivoli Storage Manager相对其他别的存储管理工具，由于得益于IBM和Tivoli对数据存储管理、灾难恢复的高度重视和成熟技术，在灾难恢复系统的利用和建立上更是领先一大步：

² 拥有成功的灾难恢复模块，专门从事系统的重建工作。

² 拥有成熟的技术服务队伍，从事备份和灾难恢复系统的顾问和规划以及实施工作。

² 拥有多层次的技术支援体系，提供从开发人员、实验室到技术支持工程师等一系列的技术支援，及时解决客户问题。

² 最关键的是，TSM作为灾难恢复和业务接管系统在国内已经在某些客户作过成功的测试，并得到一致的认可。

² TSM作为灾难恢复系统，不需对生产系统机器进行任何的改动，并可在客户生产应用系统运行的前提下立即在线安装、配置，一旦配置成功，系统将按照事先定义的策略进行数据的自动保护。

² TSM在数据存储管理时，对生产机器和备份机器的资源占用将比较小。根据内部和客户的测试结果，TSM在备份和恢复数据时，极端情况下，占用的系统资源都不会超过20%。

² 在数据的传递过程中，数据一直都通过TSM的后台数据库进行校验，保证了数据通过网络传输的一致性。

12.4.2 ISCSI存储技术

ISCSI是IETF制定的一种基于互联网TCP/IP的网络存储协议。ISCSI存储技术则是目前应用最广，最成熟的SCSI和TCP/IP两种技术的结合与发展。因此，这两种技术让ISCSI存储系统成为一个开放式架构的存储平台，系统组成非常灵活。如果我们以局域网方式组建ISCSI存储系统，只需要投入少量资金，就可以方便、快捷地对数据和存储空间进行传输和管理。ISCSI实际上也属于SAN家族中的一名成员，它可用来构建基于IP的SAN，让远程用户也可共享ISCSI存储系统中的数据和存储空间。

下面我们就来看看ISCSI的工作流程。当客户端发出一个数据、文件或应用程序的请求后，操作系统机会根据客户端请求的内容生成一个SCSI命令和数据请求，SCSI命令和数据请求通过封装后会加上一个信息包标题，并通过以太网传输到接收端；当接收端接收到这个信息包后，会对信息包进行解包，分离出的SCSI命令与数据，而分离出来的SCSI命令和数据将会传输给存储设备，当完成一次上述流程后，数据又会被返回到客户端，以响应客户端ISCSI的请求。下图是一个ISCSI系统的大体结构图。

图12-14 ISCSI系统结构图

通过上图了解，我们知道当客户端发出数据请求后，请求数据到达ISCSI存储服务器，通过ISCSI存储服务器进行数据处理后，由交换机或者路由器将数据请求传输到ISCSI存储设备中，ISCSI存储设备接收到请求信息后，根据请求信息调用存储空间返回到客户端，供客户端使用，这种方式同样适合于远程用户连接。而采用这种方式之后，相当于将ISCSI服务器上的存储资源整合到客户端，让客户端感觉好像在使用本地硬盘一样，不过这只是理论上，实际上数据传输速度并不能完全达到本地硬盘的数据传输水平，但相差并不明显，并且这种网络存储模式还有一个优点就是其安全性高，这对于如今黑客猖獗的网络时代就显得非常重要。

ISCSI技术的应用

利用ISCSI存储技术进行数据存储的最好方式就是集中存储管理方式，也就是在企业中直接建立一个统一的数据存储中心，把各个部门以及远程分公司的数据都集中在这个数据存储中心，这样做的好处就是便于管理，并且利于数据容灾备份。

图12-15 ISCSI数据容灾备份

上图是一个比较简单的ISCSI存储系统结构图，这是一个采用统一数据存储中心的结构图，通过上面我们清楚的知道该系统虽然是一个新建的ISCSI存储系统，但它并没有改变原有的网络结构。

首先我们需要了解的是客户端与数据存储中心的连接，它们之间的连接有两种方式。一种是在客户端上采用普通网卡加协议转换软件的形式，另外一种是直接在客户端采用ISCSI适配卡的连接方式。采用普通网卡加协议转换软件的形式虽然能节约资金投入，不过这种连接方式会造成CPU资源大量被占用，并且转换率也不高。而采用ISCSI适配卡连接的方式，会大大提高数据传输速度，并且占有CPU资源非常小，实际上ISCSI适配卡也相当于一块网卡，不过ISCSI适配卡价格比较昂贵。因此，用户在选择时一定要根据自己的实际情况决定。

ISCSI服务器主要的作用在于将SCSI指令封包并置入到TCP/IP封包里，也就是当客户端发出请求后，ISCSI命令和数据达到ISCSI服务器进行处理，然后ISCSI服务器根据请求命令调用数据存储中心的数据反馈给客户端用户，它主要用来为客户端调用存储空间或者存储的数据。

交换机在系统中的作用跟网络中普通的交换机一样，只是起一个连接ISCSI存储服务器和ISCSI存储设备的作用。

ISCSI存储设备主要是用来保存大量的数据，也就是我们通常所说的磁盘阵列等。在交换机与ISCSI存储设备这里我们能看出，如果我们需要增加整个ISCSI系统的存储容量，只需要购买存储设备连接到ISCSI交换机上面就可以了，这样就大大增加了整个ISCSI系统的可扩展性，并且在增加存储设备的同时，我们并不需要关掉服务器等。

12.5 小结

本章介绍了SaaS应用系统中数据存储的需求，通过数据存储的需求分析出数据存储的4种分类，并建议选择合适的数据存储的几条原则。

通过上面讨论如何处理从完全隔离的数据直到完全共享的数据，并根据不同地点的数据隔离和共享情况指出创建数据体系结构的三种方法。随后，我们将探讨决定采用何种方法时应考虑的技术和商业因素。最后，针对确保安全性、创建可扩展数据模型以及数据基础结构的可扩展性等方面，我们提出一些设计模式。

对于成功设计SaaS应用而言，本文讨论的设计方案和模式为您提供了至关重要的信任基础。设计一套既能实现竞争优势又可充分满足数据共享和隔离要求的SaaS数据体系结构，并不是一件容易的事。不过，您可借助这些方案和模式来明确并解决将面临的众多关键性问题。尽管我们在此提出的意见和建议在细节方面不尽相同，不过它们都有助于您充分利用可配制性、可扩展性以及多用户效率等基本原则来进行设计，为SaaS应用创建安全可靠的可扩展