多租户环境

多租户环境（共7篇）

多租户环境 篇1

1 引言

我在单位长期从事数据库应用系统的管理和维护工作。随着应用系统的逐年增加, 服务器由原来的十几台到现在的几十台, 日常维护的工作量急剧上升, 本来就不多的系统管理员忙得团团转。

在配置Oracle Database 12c系统时仔细研究了多租户架构, 觉得特别适合单位的情况: 部门多, 部门间应用系统相对独立, 每个应用系统占用独立的服务器资源, 实际利用率却不高。 通过创建多租户环境将这些相关部门的应用系统整合到一台性能优良的服务器上, 合并成一个容器数据库, 既降低了资源消耗, 也减少了系统维护成本。

2 多租户环境

多租户环境使Oracle数据库具有容器数据库 ( CDB, Container Database) 的功能, 可以将众多的可插接数据库 (PDB, Pluggable Database) 插入到容器数据库内, 共享多租户环境。 一个容器数据库也被称为多租户数据库。

2.1 多租户环境的组成

多租户环境即容器数据库由根、 种子和零个或零个以上的插接式数据库组成。

(1) 根 (root) : 每个CDB有且只有一个根容器, 名称为CDB$ROOT, 其中保存了管理所有插接数据库PDBs所需要的系统元数据和通用用户, 通用用户是适用于任何容器的数据库用户。

( 2) 种子 ( seed) : 种子PDB是系统内置的模板, 帮助CDB创建新的PDBs, 只读并不可修改。 种子PDB的名称为PDB$SEED。

(3) PDBs: PDB是用户 ( 租户) 创建的实体, 包括一组完成特定功能所需要的数据和代码。 PDB在CDB内插入, 和非CDB即传统的Oracle数据库完全兼容。

以上3 个组件在CDB中都是容器, 每个容器对应唯一的容器ID和名称, 例根的名称为CDB$ROOT, 容器ID为1。

如图1 所示为显示容器数据库CDB1, 它由根、 种子和4个PDBs组成。

2.2 多租户环境的优势

多租户环境特别适合有很多的传统非CDBs部署在不同硬件上的多个Oracle数据库的场合。 这些非CDBs可能只使用了硬件资源的很小部分, 而且每个数据库并不需要全职的数据库管理员进行管理。 通过将这样一些非CDBs连入一个CDB中, 可以更好地利用现有的硬件资源和管理员资源。

在Oracle Database 12c的帮助文档中介绍了很多这项新特性的优点, 特别列出以下3 点。

(1) 降低成本

通过将多个数据库系统合并到一台独立的服务器上, 共享数据库内存和文件, 大大减少了硬件、 存储、 可用性和劳动力的开销。 例如, 在一台独立服务器上的100 个PDBs共享一个数据库实例和一组数据库文件, 所需要的设备和人力大幅降低。

(2) 数据和代码迁移简单快捷

在多租户环境中, 可以快速将PDB插入CDB内, 将PDB从CDB内拔出, 然后插入到另一个CDB中。 这种插拔技术和可传输表空间技术很相似。

(3) 数据和代码分离

尽管合并成一个物理CDB, 每个PDB仍然作为独立的数据库加以管理, 且和传统非CDBs的行为特性完全一致。 例如, 如果用户由于错误丢失了关键数据, PDB管理员可以使用Oracle Flashback或时间点恢复程序找回丢失的数据, 同时不会影响到其他的PDB。

3 多租户环境实战应用

以下多租户环境实战应用均在实验环境中调试通过, 服务器操作系统Windows 2008 企业版, Oracle Database 12c企业版12.1.0.2.0。

3.1 通用用户和本地用户

2.1 节提到过通用用户。 CDB支持两种用户: 通用用户和本地用户。

通用用户保存在CDB中, 大家熟知的系统用户sys和system都是通用用户, 可以在CDB中创建通用用户, 用户名要求以c## or C## 开头。

通用用户在ROOT里和所有PDBs中拥有相同的标识, 在所有PDBs中具有同样的权限。 拥有管理权限的通用用户可以插入、 拔出和删除PDB。

本地用户只能存在于PDB中, 与传统的非CDB中的用户相同。

3.2 创建CDB数据库

在Oracle Database12c中配置多租户环境, 使用数据库配置助手 (DBCA, Database Configuration Assistant) 。

在创建数据库时, 通过 “创建为容器数据库” 选项创建容器数据库 (CDB) , 创建容器数据库的同时可以选择创建零个或零个以上的可插接数据库 (PDB) 。 如图2 所示创建了一个实例名为cdb1 的容器数据库, 包含一个名称为pdb1 的可插接数据库。

上述工作完成后, cdb1 包含了3 个容器对象: 根CDB$ROOT、 种子PDB$PEED和插接数据库pdb1。

3.3 创建PDB数据库

实验环境为SQL*Plus, Oracle Database 12c安装在服务器的D:apporacle_user 下, 文件系统工作路径为F:cdb_test。

首先需要启动SQL*Plus并连接到cdb1 容器数据库。

(1) 从种子创建PDB。 例如, 通过种子在cdb1 中创建名为pdb2 的插接数据库。

(2) 通过PDB克隆创建PDB。 例如, 通过3.1 节创建的插接数据库pdb1 创建pdb3。

(3) 通过插入已拔出的PDB创建PDB。见3.4节“拔出PDB的代码”。利用生成的“F:cdb_testpdb3.xml”文件, 可以将pdb3重新插回到cdb1中, 前提是需要先删除该pdb。

(4) 从非CDB创建PDB。

这种方法相对比较复杂。 实验环境中使用exp/imp技术, 将应用程序的数据从所在服务器上的非CDB导出, 再插入到cdb1 的插接数据库内。

1) 从应用程序所在服务器上导出数据到其文件系统的D:cdb_test 下 ( 例如, 需要导出的方案名称sales, 其表空间sales_data, 临时表空间sales_tmp, 用户sales具有DBA权限 (或相应权限) ) 。

2) 将sales.dmp从应用程序所在服务器复制到cdb1 所在服务器的文件系统F:cdb_test 路径下。

3) 用SYS连接到cdb1 容器数据库。

4) 通过克隆pdb3 创建pdb4 ( 见本节上) , pdb4 用于导入sales方案。

5) 用SYS用户连接到pdb4 容器数据库。

6) 修改pdb4 的打开方式为Read -Write。 ( 注: 如果pdb4 处于打开状态需要将其关闭)

7) 在pdb4 中创建表空间sales_data和临时表空间sales_tmp, 创建本地用户sales并分配sales_data表空间和sales_tmp临时表空间, 为sales用户授予DBA权限。

(命令和非CDB相同, 这里略)

8) 将文件sales.dmp导入pdb4。

通过以上步骤, 非CDB上的sales被成功迁移到插接数据库pdb4 上。

3.4 在SQL*Plus中管理CDB数据库

CDB容器数据库除了针对容器的操作, 其他和非CDB数据库完全兼容。 以下是在实验环境中管理CDB时用得较多的命令。

(1) 连接到容器 (例, 用SYS连接到pdb1 插接数据库) 。

(2) 返回当前容器的名称 ( 例, 接着上一条命令会返回PDB1) 。

(3) 切换容器 (例, 切换到根容器) 。

(4) 查看根容器下每个容器 (包含根容器) 的标识信息。

(5) 查看根容器下的所有PDBs对象。

(6) 查看根容器中的PDBS (种子除外) 的打开方式。

(7) 改变PDB的打开方式 (例如pdb1, pdb1 必须处于关闭状态才能修改其打开方式) 。

( 8) 拔出PDB ( 在将PDB从CDB拔出前, 必须关闭PDB, 例如pdb3) 。

(9) 删除PDB (KEEP DATAFILES为缺省项, 例如删除pdb3) 。

(10) 插入PDB (见3.3 节, 通过插入已拔出的PDB创建PDB) 。

3.5 在SQL*Plus中用Oracle资源管理器管理PDBs

在多租户环境中需要关心的问题是同一台计算机上的多个PDB之间的系统资源争用和可预测资源的使用限制, 可以使用Oracle资源管理器 (Oracle Resource Manager) 在多租户环境中为插接数据库 (PDBs) 分配资源并管理资源的使用。

以下是在实验环境中根据每个PDB的实际负载量创建的CDB资源计划, 如图3 所示。

通过设置每个PDB的Share值, Utilization Limit (有效率限制) 和Parallel Server Limit (并行服务器限制) 两个百分比, 资源管理器可以精确控制分配给每个PDB的资源使用量, 达到负载均衡的目的。

4 结语

多租户架构轻松实现了类似Oracle多个数据库一体机的功能, PDB和非CDB的完全兼容, 使Oracle数据库的开发和管理模式与以往并没有太多的改变, 对很少直接和容器数据库打交道的使用人员而言应该不会意识到正在使用插接数据库。 单位的系统通过数据整合, 节省了相当一部分服务器和网络资源, 维护人员也可以有更多的精力从事其他的工作, 是一次很好的系统升级体验。 对于有商业需求的用户可能需要购买真正的多租户环境, 以获得更好的支持和服务。

摘要：多租户环境是Oracle Database 12c的新特性, 通过将不同计算机上的多个物理数据库整合到一台计算机上的一个容器数据库 (CDB) --包含零个或零个以上供用户 (租户) 使用的插接式数据库 (PDB) , 极大降低了硬件需求和管理成本。同时, 不同PDB的数据和代码分隔设计, 使数据库系统的管理和维护工作变得简单、灵活。

关键词：多租户环境,容器数据库,插接式数据库

参考文献

[1]Bob Bryla, Kevin Loney.Oracle Database 12c The Complete Reference.北京:清华大学出版社, 2015.

[2]石彦芳, 李丹.Oracle数据库应用与开发.北京:机械工业出版社, 2012.

多租户环境 篇2

云计算是一种基于网络的可扩展的分布式计算平台, 通过虚拟化技术对各种资源进行有效整合, 建立满足服务需要的资源池, 实现资源的集中化管理。SaaS多租户共享同一SaaS服务提供方的应用服务实例, 而多终端用户间具有潜在服务质量需求差异。现有基于QoS的服务组合选择技术多面向单一租户, 即将满足单租户的服务组合选择技术逐一应用于多个租户服务组合选择方法中, 会导致整体服务质量不佳。设计面向多租户并行QoS服务组合选择技术, 弥补现有多基于单租户的服务组合选择性能不足;高效的QoS服务组合选择技术可满足未来大规模SaaS服务应用需求, 拓展云计算下SaaS模式适用范围。

2 基于QoS的SaaS小规模单一服务组合选择技术

SaaS服务需求方和提供方是博弈的双方, 基于QoS的服务组合选择是满足服务双方目标的复杂决策过程。

(1) 在SaaS服务提供方优化目标和可选服务下, 模拟实现终端用户间多维QoS约束差异。

(2) 对于SaaS终端用户服务请求规模较小, 计算量不大的情况, 实现SaaS多租户最优服务组合选择方法。

(3) 对于SaaS终端用户服务请求规模较大, 计算量大而难以有效实现SaaS服务质量最优目标的情况, 实现SaaS多租户次优服务组合选择方法。

(4) 通过URL测试数据集, 满足SaaS终端用户多维QoS约束和SaaS服务提供方优化目标, 实现基于服务质量的服务组合选择技术。

(5) 模拟SaaS终端用户间多维QoS约束差异:服务响应时间、服务吞吐量、可用性;模拟SaaS服务提供方不同优化目标:最少服务资源成本、最佳服务性能、最大营收额。将SaaS多租户服务选择问题转化为约束优化问题。

(6) 满足小规模终端用户服务请求的SaaS最优服务组合选择, 采用整数编程, 混合整数编程技术解决约束优化问题 (COP) 。

(7) 满足小规模终端用户服务请求的SaaS次优服务组合选择, 采用贪婪算法选择天际服务以缩小服务组合搜索范围来解决约束优化问题。

3 基于QoS的SaaS大规模并行服务组合选择技术

通过大量真实URL网站作为测试数据集, 对比现有QoS服务组合选择技术:局部精确, 局部天际, 局部贪婪;研究面向多租户并行服务需求特点的QoS服务组合选择技术:全局精确, 全局天际和全局贪婪, 得出新技术性能更优的结论。

3.1 局部精确 (Exact-Local)

在不同约束优化问题模型下, 优化方法逐个为每个终端用户创建执行计划, 考虑每个服务类中所有服务作为候选服务。

3.2 全局精确 (Exact-Global)

在单一约束优化问题模型下, 优化方法为所有SaaS终端用户创建执行计划, 考虑每个服务类中所有服务作为候选服务。这种方法适合服务数据量较小情况下, 采用整数编程技术解决SaaS终端用户多维QoS约束和SaaS服务提供方优化目标。

3.3 局部天际 (Skyline-Local)

在不同约束优化问题模式下, 优化方法逐个为每个终端用户创建执行计划, 考虑每个服务类中优先天际服务作为候选服务。

3.4 全局天际 (Skyline-Global)

在单一约束优化问题模型下, 优化方法为所有SaaS终端用户创建执行计划, 考虑每个服务类中的天际服务作为候选服务。这种方法适合服务数据量较大情况下, 在非天际服务失效的情况下有效使用。

3.5 局部贪婪 (Greedy-Local)

在不同约束优化问题模式下, 优化方法挨个为每个终端用户创建执行计划, 使用贪婪算法在每个服务类中选择最有代表性服务作为候选服务。

3.6 全局贪婪 (Greedy-Global)

在单一约束优化问题模型下, 优化方法为所有SaaS终端用户创建执行计划, 使用贪婪算法在每个服务类中选择最有代表性服务作为候选服务。这种方法适合服务数据量更大情况下, 在非天际服务失效的情况下有效使用。

比较分析共三组, 每组各两种新旧方法之间的执行性能差异, 证明采用的全局天际和全局贪婪方法比现有的局部天际和局部贪婪方法在服务组合选择有效性和服务优化性能方面有显著提升。新技术是满足SaaS终端用户多维QoS约束和SaaS服务提供方优化目标的理想方法。尤其在SaaS服务请求数据量不断激增情况下, 采用贪婪算法的天际服务组合选择技术具有有效性和高效性。SaaS服务提供方全局优化目标实现的同时, 可有效拓展云计算SaaS适用范围, 提升SaaS服务性能。

摘要：研究一种在云计算环境下, 基于QoS的面向SaaS多租户服务组合选择技术, 可满足SaaS终端用户多维QoS约束和SaaS服务提供方全局优化目标。

关键词：SaaS,云计算,QoS,多租户

参考文献

[1]Mohammad Alrifai, Thomas Risse, "Combining Global Optimization with Local Selection for Efficient QoSaware Service Composition", WWW2009, April 2009, Madrid, ACM 978-1-60558-487-4/09/04.

[2]Tao Yu, Yue Zhang, Kwei-Jay Lin, "Efficient Algorithms for Web Services Selection with End-to-End QoS Constraints", the 3rd International Conference on Service Oriented Computing, 2005.

多租户环境 篇3

一、多租户网站云平台

1、多租户网站云平台逻辑结构

多租户网站云平台形成一个逻辑结构表, 主要划分为元数据存储区, 业务数据存储区, 快速访问区。租户之间利用ID进行表内的信息交流。元数据主要是用来存储租户的所有信息及其相关的字段信息, 这些数据对象和字段, 用于记录租户的数据模型, 通过预先定义完整, 给予租户进行使用, 同时, 有部分数据对象和字段是根据租户的需求, 实现个性化的定制。业务数据区是平台系统中业务数据处理的中心, 元数据模块与业务数据模块的关联, 可实现元数据的使用和操作, 同时两者之间又有隔离, 因此, 构建的动态调整数据库结构是具备双向作用的。快速访问区是通过预先保留近期系统租户经常使用的数据结构及数据, 这样有利于租户能够快速地获取最近的数据, 并达到高效使用的目的, 对系统查询过于复杂的情况有积极的改善作用。

2、数据存储区域的关系

上述平台的逻辑结构表中, 元数据区作为存储租户的信息, 主要是通过租户信息表来实现租户ID和详细的信息存储, 而字段信息表来完成对所有租户可能会使用上的不同类别的字段和相关类型。租户信息表和字段信息表是元数据存储区的组成部分;而部分字段则需通过特殊数据的说明来进一步的区分与使用, 包括索引项、唯一字段、外键等。业务数据区的组成包括了不同的业务表, 而与元数据区的结合, 这是通过关联表来实现, 在实际查询使用中, 关联表链接ID来实现数据的查询获取。快速访问区中, 通过存储常用的数据信息, 如门户网站信息发布中的标题、作者和内容等, 上述的数据通过算法的处理, 如LRU替换算法, 来实现预留信息的存储和更新。

二、元数据驱动

多租户数据存储结构采用元数据驱动方式支持网站云平台中租户对数据的表示和访问需要。在这种方式下, 将租户业务数据与其描述信息分开表示和存储。这些描述信息作为元数据, 存储在数据库的元数据存储结构中。业务数据被存放在专用来存储业务数据的共用存储结构, 并提供索引等措施加快访问。彼此之间则通过各种关联表互相关联。

通过关系代数的基本论证, 在元数据的驱动中, 各个租户的数据得到很好的隔离, 在数据库系统中, 数据有序存储, 而在系统运行时, 各个租户根据自身ID可以方便地查询到属于自己的数据内容。

三、XML业务数据转换

通过元数据驱动获得租户相应的业务数据之后, 由于之前对这些业务数据进行了统一格式的包装, 因此还需要对取得的业务数据进行转换以供平台使用。平台设计了一个通用模块, 用于在业务数据增删查改时, 对数据与统一格式的XML模板进行转换。

四、快速访问区

虽然元数据驱动可以方便地实现多租户数据管理, 但是由于关联表的存在, 多租户数据的查询常常需要多个表格的联合查询, 关联查询过多造成查询速度慢效率低, 为此, 本文实现过程中引入了快速访问存储区来弥补这方面的不足。

快速访问存储区由多个基本数据表组成, 这些表存放的是共用类型的应用数据和字段, 并且使用LRU算法来对数据进行更新。系统引入快速访问存储区的日的就是把这些共用程度高的数据单独存储, 保证良好的单次存取速度, 最终有效地提高系统的整体性能。快速访问区的表存储的是租户的业务数据, 当一个租户查询请求时, 根据租户的ID可以查询到所需要的数据。随着系统的应用, 快速访区的数据将会越来越多, 考虑到这种情况, 快速访问区还必须有索引结构, 这里的索引是建立在租户, 这个属性列上的, 这样, 租户查询时根据ID可以快速找到对应的数据项。通过索引结构, 可以有效地解决索引文件膨胀导致占用多个数据存储块的问题, 使用索引读取数据时减少了磁盘访问次数, 有助于提高数据库系统的访问效率, 提高吞吐量。

五、外部数据接口

在网站云建设的初期, 往往在云平台需要集成已有的数据, 租户只有这些数据进入平台后才能进行进一步的建设和改善。由于系统业务数据采用了XML进行统一格式的封装, 因此, 对于外部数据可以很方便地表示成统一的XML模板后保存到相应的表, 大大缩短了网站集成所需的时间。

六、结语

网站云平台要求是高效利用, 管理效率高, 但是在实际现实中, 却存在网站资源的利用率低等情况, 本次研究通过构建多租户的平台, 实现平台的可伸缩性, 在统一管理, 动态配置, 个性化实现的基础上, 有利于提升网站云平台的安全、高效。

摘要：如何构建多租户的网站云平台, 并实现该平台的安全高效性是数据管理的核心。本次研究针对多租户网站云平台的特点, 提出在逻辑结构表中, 构建多个存储区, 通过不同存储区的功能设置, 实现元数据的驱动和XML业务数据转换, 在平台内达到数据隔离完好、运行安全高效的要求。

关键词：多租户,网站云平台,数据管理,技术,实现

参考文献

[1]Hui M, Jiana D, Li G, et al.Supporting database application as a service[C].Proceedings of the2009IEEE International Conference on Data Engineering (ICDE’09) .Washington, DC, USA:IEEE Computer Society, 2009:832-843.

[2]朱翠苗:《一种改进的智能化SWJS云平台》, 《计算机与现代化》, 2011 (12) 。

多租户环境 篇4

关键词：SaaS,多租户,MongoDB,定制性,设计模式

0 引言

随着经济社会的发展,日益增加的信息量和产业规模对多租户系统的定制性和时间性能提出了更高的要求:由于多个用户共享相同的架构和资源,进行用户间的个性化修改本身就是一件困难的事,再加上现有的数据层解决方案RDBMS(关系型数据库)的种种规范制约,实现定制化的设计将会更加困难;同时,爆炸式增长的信息量需要数据层提供更高的时间性能,以便大批量的插入和查询,这对于拥有复杂严谨的条件约束体系的关系型数据库来说又是一个严峻的考验。因此迫切需要一种更好的解决方案,来满足多租户下定制性和时间性能的需求。

MongoDB是一种NoSql数据库,它的文档式特点为存储大量信息提供了便利,其非关系型的特性使得人们在设计数据库时抛弃了大量复杂的约束条件,定制信息变得灵活,扩展数据变得高效。不过,也带来了较大的安全隐患。

尽管一项典型的SaaS应用由应用实例(例如用户接口、流程、业务逻辑等)和数据库组成(如图1所示),本文主要研究数据层的多租户技术,首先从几个方面探讨设计模式,例如隔离性、安全性、定制性等。

1 相关工作

现有的多租户数据层解决方案面对的挑战是:其一,数据库能否容纳不断增长的数据量和租户,以及满足它们的扩张速度;其二,数据库如何安全而又高效地满足一个租户的特定需求,同时不影响其他租户。针对这些问题,已有多人基于不同的数据库提出了自己的解决方案。

1.1 基于RDBMS的解决方案

在关系型数据库的解决方案中,根据它们如何对待共享数据和定制数据,可将其划分为四类[3]:

1) Private table[4],该种方法为每个租户分配一个私有的表,每个表中有自己的全部数据。2) Extension table[5],在该种方法中,大量共有的数据被提取出来,置于一张共享表中,而租户各自的定制数据则放在扩展表中,两者通过Tenant键来进行联接。3) Universal table,该种方案将所有租户的数据放置于同一张表中,对于租户间的定制化差异采取留白的方式,即将自己不需要的字段设为空值。4) Pivot table,这是一种更为精细的机制,将每行中的每一个字段切分开来,给与其特定的行列号,把具有相同类型的字段放置于同一张表中。

在以上四类方案中,不管以何种形式解决定制性的问题,由于关系型数据库本质特性的制约(完整性、一致性约束等),都会需要生成复杂的机制,造成资源的浪费,使得在多租户环境下进行的查询和插入等操作的时间性能极为低下。

1.2 基于XML的解决方案

在2003年Bourret给出原始XML数据库(NXD)[6]的初步定义之后,它获得了人们的广泛关注。NXD处理原始的XML而不是将其转换为关系数据模型或面向对象模型,从而避免了模型转换时的耗费,同时它支持XML的特性,诸如自我描述、半结构化、XML查询语言等[7]。

Xu W J于2010年尝试将原始XML数据库(NXD)作为多租户的存储方案,然而经过评估,由于XML的本质属性所限,其只适合作为标准的文档进行传输,而不适合作为存储大量数据的多租户数据库。

1.3 其他解决方案

BechMann等人于2006年提出了通过键值对来存储稀疏列的方法[8]。Hui M等人于2009年提出了一种名叫位图解读元组(BIT)的方法,可以将租户信息添加到表结构中而无需存储冗余的空值[9]。Foping等人于2009年提出将XML数据结合到扩展表方案中[10,11]。

在上述方案中,由于数据库本身特性所限,其定制化的机制都过于复杂,且时间性能较低。然而,在MongoDB数据库中,由于数据库本身的结构发生了巨大的变化,其文档性和非关系型的特点,将使得定制信息变得灵活,查询等操作的时间性能变得高效。

2 多租户设计模式

在MongoDB中,多个租户的数据可以被存储在同一个存储单元中,同时各个租户数据的格式各不相同:同一张collection(类似于表)中的各个document(类似于行)可以具有不同的列数,每列存储不同类型的数据,这就极大地方便了数据的定制化。

具体来讲,在多租户系统中,所有的租户共享相同的基础架构和应用实例,然而,从用户的角度来看,每个租户应该很自然地访问和使用独享的服务,因而设计一项安全而有效率的多租户基础架构变得很有必要。在MongoDB中,多租户数据层的设计应考虑以下几个重要方面[12]:

1) 数据隔离:在租户之间隔离数据的分配和使用。

在数据层面,从完全隔离到完全共享,多租户应用有不同程度的数据隔离方式。其设计模式遵循三种模型[13]:

完全隔离(独立数据库模式):每个租户拥有各自的数据库;

半共享(独立表/Schema模式):多个租户共享一个数据库,但每个租户拥有各自的表/Schema;

完全共享(共享表/Schema模式):多个租户共享相同的数据库,共享相同的表/Schema。

值得注意的是,在第三种方式中,所有租户的记录被放置于一张共享表中,故必须要插入一列Tenant-ID属性来关联数据记录和所属的租户。

2) 定制化:支持租户间的不同特性。

对于定制化模式,现有的方案大都与关系型数据库联系紧密,对MongoDB并无可用之处,故而本文将在后面详细设计针对MongoDB的定制化模式。

3) 安全性:阻止非授权的数据访问和潜在的恶意攻击。

4) 扩展性:扩展SaaS应用基础架构来支持更多的租户,并能保持性能的稳定和成本的合理。

由于本文旨在解决SaaS数据层的定制性和时间性能问题,因此多租户设计模式主要针对数据隔离和定制性两个方面展开研究。

2.1 数据隔离模式

在前文中已经提到,MongoDB是一种基于文档式的非关系型NoSql数据库,故其数据模型自然与传统关系型数据库大不相同。对于三种数据隔离方案,本文进行了如下设计:

首先,第一种独立数据库方案较为明确,每一个租户对应于一个DateBase,其记录存储于各自的collection中,此时的collection等效于表/Schema,document等效于记录;

其次,第二种独立表/Schema方案,所有租户存储于同一个DataBase中,每个collection从属于一个租户,而每个租户作为一项独立抽象的模型,具体由若干个collection组成,此时的collection同样等效于表/Schema,document同样等效于记录;

最后,第三种共享表/Schema方案,所有租户存储于同一个表/Schema中,此时的collection成为租户上层的数据模型,而租户抽象为一项独立的对象,具体由若干document组成;租户拥有若干属性,具体对应于document的键值对。表/Schema没有了固定的结构,租户内的若干document组合起来等效于表/Schema,document等效于记录。为以示区分document的所属性,需要为每个租户内的document添加不同的tenant_id键。也正如前面所提到的,组成document的键值对等效于组成record的字段。

MongoDB中,多租户的三种数据隔离方案模型如图2所示。

针对以上三种模式,在MongoDB环境下,它们有各自的长处和短处以及不同的适用场合:

方案一隔离程度最高,安全性最好,但共享程度最低,耗费资源最大;

方案二有较高的安全性,有一定隔离性但不是完全隔离,属于半共享;

方案三成本最低,完全共享,但隔离性最差,安全性最低。

若是对安全性要求更高的企业,可以选择方案一或方案二,而对于准备降低安全性来换取低成本的企业来说,方案三是更好的选择。

2.2 定制化模式

定制性是多租户系统必须解决的关键性问题之一,由于各个租户的要求各不相同,如何处理租户属性间的差异就显得尤为重要。

由于MongoDB的文档式非关系的特点,使得多租户的数据层有了本质的改变,其定制化数据模型与上述诸种方案截然不同。考虑到前文所述的三种隔离方式,很显然,定制化对于方案一和方案二来说并不是什么大问题,因为租户拥有自己独立的表/Schema,一个租户数据模型的变化,在不影响其他租户的前提下,可以直接映像到自己的数据库/表里去。而对于第三种方案,由于租户间共享表/Schema,且租户对属性的要求各不相同,如何处理分属不同租户的各组记录属性间的差异就显得尤为重要。本文将对其数据模型进行定制化扩展。

考虑如下场景,以一项基本的功能需求为例:租户1欲添加"Nat"属性,租户2欲添加"Dep"属性,而租户3不欲改动。若是在关系型数据库中,同一张表中的记录是不允许出现不同字段结构的,故必须采用扩展子表。而在MongoDB中,本文根据其文档式非关系的特点,设计如下数据模型:

针对第三种完全共享(共享表/Schema模式)隔离方案模型,本文考虑对collection下的每个租户进行定制。在本文所提出的数据模型中,将租户抽象为一项独立的对象,具体由若干document组成;每个租户对象拥有若干属性,具体对应于组成每个document的若干键值对。根据场景,对租户1添加属性"Nat",对租户2添加属性"Dep",而租户3不变,具体到数据库中为特定document中键值对的变化。如图3所示。由于MongoDB非关系型的特点,尽管三个租户在属性结构上存在巨大不同,分属三个租户的用户数据,仍然可以置于同一项collection中(类似于表),无需关系型数据库中的各种扩展子表,查询等效率必将大增,在下一部分中将以实验形式证明。

3多租户环境下MongoDB与MySQL对比实验

在上一部分中,本文提出了MongoDB下的若干多租户设计模式的解决方案。下面,为了验证MongoDB在多租户环境下的可行性,本文将在遵循所提出的设计模式前提下,通过MongoDB与MySql的对比实验,实际评估其性能。

3.1 实验条件设定

1) 硬件条件

实验环境:五台台式机,一台为Server,四台作为客户端;

电脑配置:Dell(CPU 2.6GHz*2,RAM:2G);

网络状况:100Mb/s LAN。

2) 软件条件

由于没有针对此项任务的标准数据集,本文针对多租户环境对数据的需求,生成了模拟的微博数据资料,作为多租户环境下的数据集。其中,需要增加一列TenantId属性来标识不同租户间的数据。共有3000000条数据为1000个租户所共享,两种数据库的记录结构遵循上一部分所提出的设计模式。

3.2 实验用例设计

下面,本文将设计相应的实验用例,根据所进行的操作是否涉及定制数据,将分为两部分进行实验。

1) 简单条件

先以较为简明的条件开始本文的工作,即:在各个租户共享数据库和Schema(数据隔离方案三)、暂不考虑扩展定制的条件下,对比MongoDB和MySQL的时间效率。

在MySQL中,本文增加了一列TenantId属性来标识同一张表中不同租户间的数据;而在MongoDB中,本文将不同租户的用户数据置于同一项Collection中,等效于共享Schema模式。

时间效率依据响应时间,计算出响应的TPS(每秒处理的事务数)进行评估,分别考虑增删改查四类数据库操作。

2) 定制查询

在关系型数据库MySQL中,为了解决可定制化提出了很多方案,这里仅以扩展子表为例;而在文档式数据库MongoDB中,可定制化由于其无模式的概念变得非常方便,各个租户间的属性可以大不相同。本文所要进行的实验,将针对于定制化以后的数据库查询效率(由于MySQL涉及到扩展子表,其查询必然会用到多表联合查询)。

3.3 评估结果

根据多租户环境的真实场景,需要考虑多个租户间并发操作的情况。在实验中,多个租户将从四个客户端,并发地向数据库服务器发出请求,并记录下各自的响应时间以供评估性能。客户端通过Java写成,可以模拟多个租户。

为了更大程度上的降低误差,对每项用例,本文均进行四次循环实验,每次循环均进行1万级、10万级、100万级等三次不同操作,将四次循环的结果取平均值,实验结果如下(以10线程为例):

在简单查询、插入条件下,MongoDB比MySQL速度更快,有近十倍的优势,然而也有较大波动,不如MySQL曲线平滑稳定;在更新、删除操作中,MongoDB由1万级向10万级过渡时有较大衰减,减小了与MySQL的差距,本文认为此时的瓶颈已经变为内存而非数据库,故测得的数据并不能完全体现数据库的性能,如图4所示。

在定制条件下,由于MySQL涉及到扩展子表,其查询必然会用到多表联合查询,速度会更慢;而MongoDB中,尽管租户在属性结构上存在巨大不同,然而由于其非关系型的特点,分属不同租户的用户数据,仍然可以置于同一项Collection中(类似于表),查询速度比MySQL更快,更适合于多租户的存储方案,如图5所示。

3.4 实验结论

从以上实验数据对比本文可以得出:

MongoDB适合场景:擅长大批量简单查询、插入,定制化查询;简单更新、删除较优于关系型数据库,但由于内存所限,优势不大。这也印证了MongoDB相比传统关系型数据库拥有较强定制性和时间性能的特点;

MongoDB不适合场景:复杂查询,多表联合查询。并且其安全性较低,若是银行、医院等对安全性要求较高的场合,应使用拥有复杂规范约束的关系型数据库。

4 总结与展望

本文针对开篇背景中所提出的问题,进行了研究和实验,首先对比分析了多种现有的多租户的解决方案,然后基于MongoDB提出了一套具有更强定制性和时间性能的多租户设计模式,并通过与MySQL数据库的对比实验证明了MongoDB的适用场合:对安全性要求不高,主要进行大批量简单插入查询,或对定制性有较高要求的场景。在今后的工作中, MongoDB的安全性以及复杂联合查询将是重要的研究方向。

多租户环境 篇5

关键词：云服务,多租户,技术

软件即服务(SaaS)可以称得上是最为常用和普遍的云服务类型。独立的应用利用SaaS就可以在供应商服务器上向所有用户送达。客户为自己的的使用支付一定的费用,用户只需利用Web就可以对其进行使用和访问。供应商所面临的每个组织被称为租户,这种配置类型叫做多租户构造。供应商利用虚拟化技术可以虚拟分割服务器,使其成为多个部分,让每个租户可以通过相对应的应用来对工作进行完成。SaaS对客户来说可以为多次投资软件许可或者服务器。同时,对于开发者来说,维护一个应用就可以使得多个客户正常工作。那多租户技术是如何实现的呢?

1多租户技术

SaaS服务模式与传统软件模式的区别就是多租户,只要SaaS解决数据隔离的问题,能够达到第三水平的等级要求就可以根据需要实现多租户的模式。

传统软件的开发模式就是只有单一的一个用户,不会涉及到用户间数据的混乱。因为在多租户的SaaS服务模式系统, 要保证租户之间的隐私就需要进行增加TENANTID或者COMPANYNO字段才能够做到各租户之间数据的区分和隔离。

针对教育系统,租户包括:学习用户, 资源提供者和系统管理员,每一个角色都具有不同的属性以及使用到不同的系统功能,所以采用多租户的方式是十分有必要的。

TENANTID其实就是用来区别各个租户之间的信息的作用,这个在传统软件模式的时候是没有这个字段的。其实这就是能够保证租户之间的隐私就是自己的信息不回被其他的租户看见。因为它通过这个TENANTID字段来了解属于自己的信息,在使用时不回看到别的租户的只要输入是增加TENANTID=‘?’语句。

2数据扩展技术

其实在不同的模式下,使用数据扩展技术的意义是不同的,因为不同的租户的名称和信息都是不同的,当在传统软件模式下,直接用这个技术,就能够实现数据模型的扩展,但是如果在多租户的模式下,进行数据扩展技术来之间扩展字段这样是不可用的,不能满足不同租户不同业务的需求数据,反而会造成资源的浪费而且会破坏这个模型的结果。

因此在多租户的模式下的时候如果需要进行数据扩展,那么就需要在系统中独立的构架一个多租户的管理表,字段配置表和数据业务扩展表,这样才能够不在资源浪费和破坏结构的情况下能够很好地进行数据扩展。

在扩展数据中,因为根据满足不同租户的需求时,这个数据表是从横向的转化为纵向的,都会形成一个扩展数记录的, 因为它把每一条的数据都保存了下来都会形成一个扩展数据行,因此数据记录和数据配置都是有关联的。

(l) 数据类表中主要的就是记载着各租户相应的业务数据。

(2) 数据扩展表中都可以知道每个租户的扩展数据:扩展数据所对应的业务表TABLE,数据编号DATA_NO,扩展编号CONF_NO,租户扩展数据值EXT_ VALUE。

(3) 配置表中有租户的很多类型的分类:扩展编号CONF_NO,租户编号TENANTID,扩展数据所对应的业务表TABLE,扩展数据的内容CONTENT,扩展数据的扩展类型TYPE。在以上的几个中的构成配置表的核心的是CONF_NO和TENANTID,而且扩展数据和TENANTID是相对应的,而且DATA_NO和ID主键也是相对应的。

有很多相对应的数据,如配置数据表中的扩展编号和数据扩展表中的CONF_ NO,还有就是租户的配置的扩展数据之间和租户业务和扩展数据这些都是相对应的数据。

3配置性技术

SaaS服务模式是需要按照租户需求使用,按照需求付费的,因此这个就需要租户在使用SaaS服务模式的时候要选择自己需要的功能,而且可以选择一个功能大集合避免重复的选择,这样还可以满足各租户要求的功能,这个是SaaS服务模式强调的。

按照租户需求使用,按照需求付费其实就是为了让租户在不同的时候不同的需要下,可以选择不同的功能,这样付费可以节约。

要实现功能的配置就需要因为不同的功能模式,让租户可以选择自己需要的功能模式。其实就是需要将一个整体的系统粉尘一个个基本的独立的而且不重复的原子功能,而且如果这些原子功能加起来就能够形成一个整体的功能。但是租客是要根据自己的需要进行选择的,因此可以按照租客的要求和使用进行组合和划分。

(1) 存储租户信息的就是租户表,上面记载着很多信息:租户所属于的行业编号CO_NO,租户编号TENANTID,租户的系统登录账号USER_ID,租户名USER_ NAME,租户系统登录密码PSSWORD, 租户使用系统包括的功能模式编号PATTERN_NO,租户所属于系统使用范畴PATTERN_TYPE。主要的就是租户所属于的行业编号CO_NO和租户编号TENANTID。而且租户拥有自己的登陆信息可以查找自己的使用的功能。

(2) 就是在功能表中一些被分离的原子功能,例如原子功能编号MENU_NO,原子功能分类MENU_TYPE,原子功能详细描述标签名MENU_NAME。

当然原子功能编号MENU_NO是最主要的构成,因为这个是唯一的,可以识别系统的使用的功能的。

(3) 有关的信息资源存在于对应的模式表之中。在PATTER_NO中,主要是对各模式进行了连续的号码标注,在MENU_ NO中,主要针对原子功能进行了连续的号码标注,这两者作为主键而单独存在, 它们的编号是唯一的。一切原子功能都存在于模式表之中,这就保障了系统的协调稳定性。当用户在第一次使用的时候,可以给予其起到导航的作用。

多租户环境 篇6

在云计算应用中,多租户技术可以让多个租户共享使用同一个应用程序或运算环境,对云服务供应商来说可以有效降低运营成本[1,2]。对于多租户应用,同一物理资源由多个应用共享,共同构成了资源总的消耗,但从总的资源消耗中很难直接获知各个应用的资源消耗量。租户的共享使得资源使用率得到提高,但若租户之间难以完全信任,会存在恶意侵占其他租户资源的行为;即使在同一组织内部,相互信赖的多个租户,仍有可能由于误操作或过载而导致租户侵占大量资源,影响其他租户的性能[3,4]。为了避免性能干扰,直接的方法是对租户的资源消耗做好监控,当租户发生或可能发生性能侵占的行为时,对租户的资源分配进行调整,避免系统过载而影响其他租户。在多租户环境下实施资源调整,需要建立在对多租户的负载进行动态检测以及分析的基础上,对资源消耗进行评估,适时发现系统的性能瓶颈,从而使租户的资源分配对优化系统性能起到效用[5]。

文献[6]提出一种基于Kalman滤波的多租户Web应用CPU资源动态评估方法,通过近似最优方式利用可观测值估算不可观测值,随着新的观测值的到来更新之前的估算值,更适用于时变资源状态的在线评估。Song等人[7,8]利用机器学习的方法来计算每个应用程序的优先级,提出了基于优先级降低能耗的资源分配方案。文献[7,8]关注数据中心虚拟机资源的各种静态配置方案以保证资源分配的公平性,并提高资源利用率。文献[9]利用服务器产生的日志分析资源消耗,根据日志信息提供的服务请求和响应时间分析运行服务的资源消耗。文献[10]使用修改内核指令的方法来测量资源消耗,此方法测量精度较高,但需要对操作系统进行修改,产生的额外开销过大。在多租户环境中由于租户行为的不确定,负载动态快速变化,资源分配量若不能根据负载需求而变化,可能会导致负载很轻时浪费许多不必要的资源,因此需要对负载的分析和评估进行进一步的处理,在良好的负载分析结果基础上,提升多租户应用动态资源调整的效果。

CPU是具有代表性的、宝贵的计算资源,与内存、网络等其他资源相比,它更加难以准确获取。在多租户环境中由于租户间共享资源,简单的CPU直接测量法的开销较大,也不灵活。本文设计和实现了一个基于CPU分析的多租户应用动态资源调整机制及其原型Tenant CPUMan。其主要实现了云环境下多租户的对资源的动态变化的检测,在采集租户的信息基础上,利用多元线性回归分析评估CPU等资源消耗,以此为基础进行资源的动态调整。在多租户负载多变的环境下,系统具有资源浪费少,系统的利用率高等优点。

1 工作思路和框架

通常的多租户支撑环境中,由管理员根据各租户的需求分配租户的CPU、内存、网络带宽和硬盘大小等资源。静态的分配方式不能感知租户应用的负载情况,无法及时根据负载情况做出准确的反映和保护措施。Tenant CPUMan设计的出发点是租户应用的资源需求要与租户的实际负载相适应,在线获取预测租户应用的负载,然后及时做出调整租户的物理或虚拟资源,实现弹性资源供给。租户的资源调整过程不能强行中断租户应用,而是连续动态化的再分配资源。Tenant CPUMan的框架如图1所示。

信息收集模块

获取租户应用的运行时数据,包含租户的ID、CPU个数、CPU频率、CPU使用率、内存使用情况、最大内存值、网络带宽使用率和最大设定的网络带宽等;周期性将所收集到的数据发送给信息分析模块分析,使用基于回归分析的方法进行估算租户的CPU资源需求,以降低多租户环境中直接使用探针方法估算,带来的额外开销。

信息分析模块

动态地估算CPU资源消耗分析,分析当前租户的负载情况和当前的资源分配方案是否合理,是否存在租户负荷过载的情况。例如,当前租户应用的请求速率增快和平均响应时间变慢时,信息分析模块根据当前负载给出适当的资源分配操作。该模块着重分析能反映出租户当前负载情况的平均响应时间(而非直接的响应时间)。

资源调整模块

接受分析模块的反馈信息,根据信息判断是否对租户的应用环境制定分配方案并进行资源再分配。资源调整模块不仅可通过分析模块进行调整,管理员可直接向多租户资源调整程序进行申请,申请后也可根据租户的要求进行资源的动态调整。

在Tenant CPUMan框架中,租户资源调整流程如图2所示。基于以上思路设计和实现系统时,关注的关键技术主要涉及资源消耗分析评估以及调整策略的实现,如下一小节所述。

2 关键实现

Tenant CPUMan原型系统的实现在开源的KVM(Kernelbased Virtual Machine)虚拟化管理平台上,并通过对libvert[11]的API库的修改实现了资源的动态调整。Tenant CPUMan提供支持多种远程传输协议,包括SSH、VNC、SPICE等。Tenant CPUMan操作租户虚拟机使用SSH协议,通过远程命令对租户的应用环境进行修改。下面分别介绍Tenant CPUMan两个核心模块的实现机制。

2.1 负载分析

在多租户环境下内存、网络等资源消耗较易于直接获取,但多租户的CPU资源消耗因直接获取需要租户系统兼容性支持,并会对租户产生额外的开销。因此,我们重点研究了CPU负载分析的实现。我们采用了偏最小二乘回归分析预测模型[12]来估算租户的CPU资源消耗,其具有允许在样本个数较少的情况进行回归建模、能提高模型的预测精度等特点。

在估算租户的CPU资源消耗过程中,首先利用系统探针在线获取服务端的日志信息,包括服务器的CPU平均利用率、响应时间和租户的吞吐量等,这些运行信息在固定时间间隔(称为监测窗口)中获取。设服务器有K个租户,T为监测窗口的时间长度,Ni表示第i(1≤i≤K)租户在监测窗口的时间内所完成事务数;Acpu,n表示在服务器n上经过监测窗口记录时间内CPU平均利用率;Di,n为第i(1≤i≤K)个租户在服务器n上所完成所有事务的平均时间。根据效用法则,租户CPU资源利用评估指可用吞吐量与服务时间之积表示,如式(1)所示:

由于难以获取精确的服务时间Di,n,用Ci,n来表示其近似值,则Acpu,n的近似值A'cpu,n计算如式(2):

为减小Acpu,n与A'cpu,n间的误差以提高衡量精确度,我们使用偏最小二乘回归分析法对监测窗口中记录的事务吞吐量、响应时间等参数进行回归建模计算出Ci,n。服务时间C建模如下:

其中:C为N×1矩阵,表示N个租户的平均服务时间;e为常量;B为1×m回归系数矩阵;X为N×K矩阵。

通过监测窗口获取租户运行时的N个记录,一个记录包含m项数据,则第k个记录的解释变量为X1k,X2k,…,Xmk,包含各租户的吞吐量、平均响应时间和负载的事务概率等数据项。根据偏最小二乘分析法计算出系数矩阵B,然后代入式(3)、式(2),即得出分析结果。

2.2 资源调整

资源调整模块接收信息分析模块的结果后,通过基于libvert的API库的调用修改虚拟机实例,进行动态资源调整。虚拟机的资源调整分为配置修改和动态迁移两种类型,均可以通过扩展libvirt的API功能而实现。资源调整模块实现了资源配置修改、资源限制、物理CPU和虚拟CPU的关系调整、内存和网络配置修改等调整功能。

Tenant CPUMan设定一个租户独占一个虚拟机,使用共享CPU的调整方式(如图3所示),多个租户虚拟机运行在一个主机上,在底层共享资源的基础上实现多个CPU间的调度。CPU的调整首先在线获取物理机的CPU消耗,然后获取相应租户的映射关系与虚拟CPU的资源消耗,通过查询映射关系表,根据信息分析模块对租户虚拟机的负载进行评估,对租户虚拟机做出迁移、释放和增加虚拟CPU等资源调整,调整流程如图4所示。

3 测试

本节介绍Tenant CPUMan的测试效果。测试环境部署如图5所示。每个租户的应用分配在一个虚拟机上,租户使用的是符合TPC-W的规范的电子商务网站[13]。TPC-W是一个广泛使用的电子商务测试基准,其定义了14种事务操作,包括网上书店的浏览、查询以及订单等事务操作。实验目的是测试原型系统能否自动调节租户资源,避免个别租户资源使用率过高而影响其他租户的资源消耗。租户的负载分别考虑为负载长期使用率过低,负载突然急聚上升和稳定负载的状态。实验记录时间长度为2小时,设内存调整的前提条件为内存使用率是否超过阈值90%。我们考察其中5个租户的表现。考虑网络和硬盘读写在本实验的Web应用中不是性能瓶颈,这里主要考虑的是CPU和内存的负载,负载的基本单位为模拟浏览器线程的数量。模拟的租户负载的平均分布如图6所示,不同租户的负载有不同的特征。

我们通过资源监测模块记录下CPU的消耗,统计出每分钟的CPU利用率平均值,得出CPU的平均利用率和内存的平均使用率的分布如图7所示。

然后再次使用设置参数生成租户重新模拟生成负载。我们通过多租户调整资源调整系统后统计资源消耗,此时CPU的使用率分布图和内存的平均使用率如图8所示。

对比图7与图8的CPU平均使用率,租户4的负载有多租户资源调整系统对VCPU(租户虚拟机的虚拟CPU)进行调整后,持续高负载的CPU使用率得到缓和,最后CPU的使用率保持在65%左右。租户2的调整后的CPU使用率持续上升的利用率也在70分钟后的得到稳定。可以看到,租户的负载高,CPU使用率相应提高,但我们对CPU的利用率上升的状态时,不是即刻执行调整资源的,这是防止短暂的负载抖动而资源导致CPU使用率过高的现象。如果因负载的短暂抖动现象而调整资源,负载稳定后资源的使用率过低则会造成资源浪费,资源分析模块需一段时间判断后才向资源调整模块申请资源,然后分配VCPU给租户,使得租户的性能提高,避免租户应用高负载的状态。租户1的CPU使用率保持较低,但由于使用KVM释放VCPU资源需要租户的环境影响,不做直接修改。

对比图7与图8的平均内存使用率,租户4内存的使用率在使用Tenant CPUMan前内存的使用率较高,保持在80%以上,在调整后内存的使用率降低并稳定在40%。而租户2的使用率虽持续上升但达到62%后保持稳定,Tenant CPUMan并未对内存资源进行调整。这是由于内存调整的前提优先判断内存使用率是否超过阈值(90%)。观察图6租户1的内存使用率始终保持在较低的使用率下,始终保持在20%之下,而在图7的租户的内存使用率在第40分钟上升了。这是由于多租户资源调整系统对租户1的内存动态调整释放了资源。租户的总内存减少从而内存使用率提高。租户3和租户5的内存使用率较为平稳,Tenant CPUMan并未做修改,租户的平均内存使用率变化不大。

综上所述,Tenant CPUMan系统在基于负载预测的前提下,分析多租户应用的资源消耗,对负载进行预测和资源调整。由于提前进行资源分配的调整,租户的CPU和内存的负荷过载得到了有效的减少,也证明了多租户资源调整系统有效性。Tenant CPUMan可以针对多租户环境中由于租户行为的不确定,负载动态快速变化等问题,根据负载的变换动态地调整资源分配,减少了负载很轻时浪费不必要的资源,减少应用程序的响应时间和租户的等待时间,保证了租户的服务质量。

4 结语

多租户环境 篇7

关键词：多租户,SaaS成熟度模型,RDB,数据隔离,数据扩展

云计算(Cloud Compute)的提出解决当前软硬件系统及应用面临的诸多问题:硬件基础设施众多分散、维护和管理困难、利用率和效率低、成本高;系统应用扩展性低、业务稳定性和灵活性差;信息孤岛现象;安全机制不明显等。当前,云计算的服务模式主要是:基础设施即服务(Infrastructure as a Service,Iaa S)、平台即服务(Platform as a Service,Paa S)、软件即服务(Software as a Service,Saa S)[1]。其中Saa S应用最广、发展最早、技术最为成熟。

Saa S是一种新型的软件运营服务模式,最初的表现形式是ASP模式,随着“按需软件”的理念、互联网Web技术、硬件设施带宽的发展日益增长并成熟[2]。 Saa S服务模式与传统软件开发运营模式有着很大的不同,它以“按需使用、按需付费”为特征,软件服务提供方只需将应用软件统一部署在自己的服务器上,并进行定期维护工作;通过高速的网络,客户方根据自己的需求以较低的价格租赁软件的使用权,不用担心软件的维护、升级、安全等问题[3]。这样软件从产品的概念转换成一种服务,能够有效地降低了软件开发和使用过程中的各项成本和风险。

1多租户技术和Saa S成熟度模型

1.1多租户技术

Saa S服务模式的核心在于多租户技术(Multi- ten- ancy Technology,又称多重租赁技术),是区别于传统软件开发运营模式的最本质的地方。传统软件模式需要为每个用户开发定制软件并独立部署;而在多租户模式下,多个租户共用一套软件实例和运行实例,即多用户单实例[4,5]。多租户技术是一种软件架构技术,探讨和实现多个用户在同一环境能力下,保证应用稳定性、业务灵活性、数据安全性前提下如何灵活使用同一套应用系统。对于数据层面,多租户技术重点是解决数据隔离,即在数据隔离和共享之间找到一个平衡,租户既可以共享数据,又能定制自己的数据,同时不影响其它租户的访问性能。

1.2 Saa S成熟度模型

根据Saa S服务应用是否具有可配置、高性能、可伸缩的特性,将Saa S服务应用分为四个等级,称之为Saa S成熟度模型;其中,每一级都比前一级增加以上三种特性中的一种见表1[4,5]。

Level:仍然是传统的软件开发模式,需要为每个用户开发一套定制软件并独立部署;开发模式是多次开发多次部署。Leve2:根据用户的不同需求提供不同的配置功能,将单独定制性软件变为具有租户个性化需求的通用性软件,使通用性软件具有可配置性,但并没有改变软件的部署架构,每个租户仍然需要独立部署一个运行实例;开发模式是一次开发多次部署。 Leve3:前两级都是单租户单实例,而这一级则是通过某些的策略保证多个租户共享同一个实例,同时又能为租户提供个性化定制需求;开发模式是一次开发一次部署。Leve4:随着租户数量的逐渐增多,不需更改应用架构,而仅需要增加硬件设备的数量,就可以支撑应用规模的增长;开发模式是一次开发无限扩展[5]。

2数据存储

Saa S模式数据存储常用的存储模式是:独立数据库存储模式、共享数据库独立Schema存储模式、共享数据库共享Schema存储模式[4]。三种存储模式在隔离程度、共享程度、可配置性、可伸缩性、成本、安全性、数据备份和恢复、技术性能、使用对象多方面对比见表2[5,6,7]。

文献[6] 提出一种“共享数据库半共享半独立schema”数据存储模式,将租户的共有信息提取出来存储一个可以各租户共享的父模式中,而租户的定制信息放到租户独立的模式中存储。这种策略在一定程度上提高了数据的物理隔离级别,保证租户数据的安全性。但随着租户定制信息的增多,以及租户扩展数据也有部分共性,导致共享程度会越来越低,数据整合程度变难,影响数据访问性能。

3数据扩展

数据扩展,又称数据可配置,即各租户根据自己的个性化需求定制数据,并不能影响到其它租户的正常使用。这是实现多租户的关键因素之一。基于关系型数据库的解决方案技术相对成熟,主要有定制字段、预分配字段、稀疏列、名称值对、通用表、基于xml等方式。 定制字段[6],根据租户的定制需求在数据表上加相应的字段保存,是传统应用最常见的实现方式,但是由于租户定制字段对其他租户没有意义而产生大量的数据冗余,严重破坏了数据表结构。

预分配字段[6],在系统设计时事先给租户预留一定数量的通用字段,当用户需要数据扩展时,就把通用字段定制所需要的字段;传统应用的一种常见的解决方案,但是通用字段的个数限制了数据表的结构和用户的可配置需求。

为了优化定制字段和预分配字段中过多的null值,Micorsoft SQL Server[8]提出了一个存储变体Saprse Columns,即将属性名称和值存储到一块。稀疏列减少了Null值的空间需求,但对于非Null值的检索开销增加;同时,采用稀疏列还会有许多限制[8]。

名称值对扩展方式,又称扩展表技术,就是将原数据表和扩展数据分离,增设扩展字段表存储租户的定制字段,增设扩展数据表存储租户扩展的数据[9]。 这种方式可以无限量的扩展数据,但由于访问时需要多表数据重构,增加了操作的复杂性,影响系统性能。

通用表技术[10],将所有租户的数据放到一个通用数据表中,字段类型采用可以转换成其他类型的通用数据类型,待用户使用时改成自己的需要类型。数据放到同一张表中,共享程度高,但也导致了数据表较宽、 null值较多等问题。

目前,主流的关系数据库都增加XML数据类型, 例如SQL Server、DB2。将扩展数据存到xml字段中,能够无限扩展,但由于需要数据解析,降低了数据访问效率。如果数据量过大,就不适合用xml类型存储[11]。

各扩展方法在实现方式、实现复杂性、空间利用率、灵活性、性能等方面的对比见表3[12]。

文献[6]在稀疏列扩展方式和通用表扩展方式的基础上,在租户独立模式下将属性和值存到同一张扩展表, 克服了NULL值较多、数据表较宽等缺点,但也导致扩展记录很多,扩展数据的共享程度低,数据冗余度高。

4可伸缩性

文献[5]指出,对于Saa S应用最理想的情况是:随着租户数目大量增加,无需调整数据存储结构,仅通过增加硬件方式即可实现负载的扩展,例如增加或增强相应的应用服务器、数据库服务器。实现方式通常是 “scale up”(垂直扩展或者向上扩展)和“scale out”(水平扩展)。相对于应用层的伸缩性,数据库层的伸缩性是制约Saa S应用系统性能的瓶颈。对于数据库层,垂直扩展是通过增设硬件设备并重新开发部署运行多租户实例,面临着高成本的问题;而水平扩展是将数据库进行分割或者划分并分担到单独的数据库个,实现采用方式通常是数据库的垂直划分、读写分离、水平划分[5], 面临着数据分割、数据备份、数据动态迁移等问题[13]。

5结束语