云计算架构基础之多租户数据架构 (二) 三种模式实现相关的一些模式

云计算架构基础之多租户数据架构 (二) 三种模式实现相关的一些模式

Realizing Multi-Tenant Data Architecture

Technorati 标签: Azure,SaaS,云计算,多租户


作者:LiuGuangLong
出处:http://www.cnblogs.com/liuguanglong/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

本文大部分内容来自http://msdn.microsoft.com/en-us/library/aa479086.aspx

本人做了一些提炼和总结。如对内容有疑义请看原文。

 

上一篇介绍了多租户的三种数据模式,本篇介绍实现方面的一些常用的模式。

 

无论是哪种模式都要考虑安全性,数据模型的扩展以及性能方面的可扩展性。

下表列出了实现三种模式时常用的一些模式。

 

image

 

安全相关的模式

数据安全相关模式主要使用下面三种方式来实现

  • 过滤(Filtering):通过过滤,租户只能看到自己的数据。不能看到其他租户的数据。
  • 许可(Permission):使用访问控制列表(ACL:Access Control List)来决定谁能访问数据以及谁能作那些数据操作。
  • 加密(Encrption):存储的数据都是加密的。其他租户即使能够看到,也是经过加密的数据。

 

Trusted Database Connections模式

在通常的多层架构中通常使用模拟(Impersonation)和信任子系统(Trusted subsystem account)两种模式

 

模拟(Impersonation)模式如下图,DB控制不同的用户访问不同的表,视图,查询等数据对象。

当用户的请求到达时程序使用最终客户的ID访问DB。

Aa479086.mlttntda08(en-us,MSDN.10).gif

 

信任子系统(Trusted subsystem account)模式如下图,程序使用自己的ID访问DB。必须在程序中实现安全控制逻辑。

Aa479086.mlttntda09(en-us,MSDN.10).gif

 

在多租户数据架构中通常把两种模式混合在一起使用。如下图所示。

程序通过某种机制使用与最终用户的ID对应的租户ID访问DB。

 

 Aa479086.mlttntda10(en-us,MSDN.10).gif

 

 

Secure Database Tables模式

主要用在DB分离或者Schema分离方式,通过授权不同的用户只能访问自己的数据表。

例如

   GRANT SELECT, UPDATE, INSERT, DELETE ON [TableName] FOR [UserName]
 
Tenant View Filter模式

租户试图过滤模式用在共享DB,共享Scheam方式。

通过表示图使得一个租户只能看到共享表中的自己的数据。

例如

   CREATE VIEW TenantEmployees AS
   SELECT * FROM Employees WHERE TenantID = SUSER_SID()

 

Tenant Data Encryption模式

租户存储的数据都是加密的。加密通常分为对称加密和非对称加密。对称加密只需要一个

公有Key,加密解密都要用这个公有Key。非对称加密,加密使用公有key,解密用私有

Key。非对称加密比对称加密的计算量要大很多,在多租户数据结构中所有数据都使用非

对称加密不现实。一般采用两种模式混合的方法。

使用对称加密算法加密解密所有的租户数据。使用非对称加密来加密解密租户的公有Key。

私有key和公有key都保存在DB中,当一个请求到达时,程序使用租户的ID通过模拟模式

访问DB取得私有Key(保证了租户只能访问自己的私有Key)。使用私有key来解密公有Key。

再使用公有key来加密解密用户的数据。

 

扩展相关的模式

对于多租户数据模型来说,总是要面对不同租户的不同需求,例如表中添加字段等。这里

提到几个模式用来完成此目的。

 

Preallocated Fields

此模式主要用在共享DB共享Schema实现方式下,在表中预留一些字段,供租户扩展使用。

Aa479086.mlttntda11(en-us,MSDN.10).gif

此表中存有不同租户的数据,预定义的字段的定义是由不同的租户自己指定的。

 

此模式的问题是预留字段是固定的,不能动态调整,定义少了有可能不能满足租户的需求。

定义多了,浪费空间。

 

而且字段类型和一些关联数据须在另外的表中记录。通常采用下图所示的方法。

Aa479086.mlttntda13(en-us,MSDN.10).gif

 

Name-Value Pairs模式

实现方式如下,避免了预留字段模式的缺点。

此模式为每个扩展的字段定义个ID,并在扩展元数据表中记录此ID的关联属性。

扩展字段的数据保存在扩展数据表中。数据表中的一条记录与扩展属性表中的多条记录关联。

Aa479086.mlttntda14(en-us,MSDN.10).gif

 

Custom Columns模式

用在分离DB和分离Schema实现方式下,租户的扩展需求直接通过修改表定义来实现。

如下图

Aa479086.mlttntda15(en-us,MSDN.10).gif

 

Scalability Patterns

当数据量非常巨大或者并发访问量特别大的时候会严重影响程序性能,这是会采用一些扩展的模式。

在分离DB实现方式下,与通常的DB扩展方式一样,包括复制和表分区。

在分离Schema和共享方式下,通常使用基于租户的水平表分割模式。把不同租户的数据分区到不同的DB中。

 

 

 

 


作者:LiuGuangLong
出处:http://www.cnblogs.com/liuguanglong/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

posted @ 2011-01-14 09:58  软件猎人  阅读(1234)  评论(0编辑  收藏  举报