云计算架构基础之多租户数据架构 （一） 三种模式和影响选择的因素
云计算架构基础之多租户数据架构 （一） 三种模式和影响选择的因素
Multi-Tenant Data Architecture
题记：本文内容大多来自http://msdn.microsoft.com/en-us/library/aa479086.aspx
本人做了一些精炼和提取。
实现多租户数据存储的三种方式
- 分离数据库(Separated DB)
- 共享数据库，分离Schema (Shared DB,Separate Schema)
- 共享数据库，共享Schema (Shared Schema)
其中分离数据库的隔离性最好，共享数据库/共享Schema的共享性最好。
分离数据库模式如下图所示，不同租户的数据存在不同的数据库中
优点
为不同的租户提供独立的数据库，安全性更好
数据模型的扩展更容易，可以更容易的满足不同租户的特殊需求
如果出现故障，恢复数据比较简单。
缺点：
增大了数据库的安装数量，维护，备份等成本都非常高。
随之带来维护成本和购置成本的增加。
总结
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商
那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，租
用的费用会非常高。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承
受的。
共享数据库，分离Schema 模式如下图所示，不同租户的数据存储在同一数据库的不同的Schema中
与多Schema相关的一些DB操作
为一个新建的租户创建Schema，此租户名为Contoso
例：CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso
可以使用Schema名.Table名创建和访问表
例：CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key,
Resume nvarchar(MAX))
Schema创建后，可以为租户绑定缺省的Schema
例：ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema 租户与自己的Schema绑定后，就可以不用Schema名.Table名访问表了
例：SELECT * FROM Resumes
优点：
为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；
每个数据库可以支持更多的租户数量。
程序中访问DB不需要针对区分租户做特别的处理。
缺点：
如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；
如果需要跨租户统计数据，存在一定困难。
共享数据库，共享Schema 模式如下图所示，不同租户的数据存储在同一数据库的同一的Schema中
优点：
维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
隔离级别最低，安全性最低
需要在设计开发针对安全控制做大量的工作；
数据备份和恢复最困难，需要逐表逐条备份和还原。
选择合理的实现模式
衡量三种模式主要考虑的因素是隔离还是共享。
成本角度因素
隔离性越好，设计和实现的难度和成本越高，初始成本越高。共享性越好，同一运营成本
下支持的用户越多，运营成本越低。
从上面示意图可以看到，随着时间的推移，共享性越好，运营成本越低，但是初始成本更高。
安全因素
要考虑业务和客户的安全方面的要求。安全性要求越高，越要倾向于隔离。
从租户数量上考虑
主要考虑下面一些因素
- 系统要支持多少租户？上百？上千还是上万？可能的租户越多，越倾向于共享。
- 平均每个租户要存储数据需要的空间大小。存贮的数据越多，越倾向于隔离。
- 每个租户的同时访问系统的最终用户数量。需要支持的越多，越倾向于隔离。
- 是否想针对每一租户提供附加的服务，例如数据的备份和恢复等。这方面的需求越多， 越倾向于隔离
如下图表示
信息监管因素
要考虑政府，机关，企业，公司的安全和信息监管相关的一些政策和规定。
技术储备
共享性越高，对技术的要求越高。
总结:本篇精炼了多租户架构的三种实现模式以及在做合理的选择时需要考虑的一些因素。
下一篇打算接着介绍不同模式下的一些实现模式。
作者：LiuGuangLong
出处：http://www.cnblogs.com/liuguanglong/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
