SaaS多租户模式数据存储方案比较

  云计算多租户几乎用于所有软件即服务 (Software as a Service, SaaS) 应用程序,因为计算资源是可伸缩的,而且这些资源的分配由实际使用决定。话虽如此,用户可以通过 Internet 访问多种类型的 SaaS 应用程序,从小的基于 Internet 的小部件到大型企业软件应用程序。根据存储在企业网络之外的软件供应商的基础架构上的数据不同,安全需求也在不断增长。应用程序需要多租户是有许多原因的,其中最明显的原因就是成本:在大多数情况下,为每个客户增加几个服务器和一个数据库是远远不够的,尽管在安全要求很高的情况下这么做有点用处。

  多租户就是说多个租户共用一个实例,租户的数据既有隔离又有共享,说到底就是如何解决数据存储的问题。

  现在SaaS Multi-Tenant在数据存储上存在两大类共三种主要的方案,分别是:独立数据库和共享数据库,其中共享数据库又可分为共享数据库,隔离数据架构和共享数据库,共享数据架构。下面就分别对这三种方案进行介绍:

  独立数据库:

  

  这是第一种方案,即一个Tenant一个Database,这种方案的用户数据隔离级别最高,安全性最好,但成本也高。

  优点:

  为不同的租户提供独立的数据库,有助于简化数据模型的扩展设计,满足不同租户的独特需求;如果出现故障,恢复数据比较简单。

  缺点:

  增大了数据库的安装数量,随之带来维护成本和购置成本的增加。

  这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户,可以选择这种模式,提高租用的定价。如果定价较低,产品走低价路线,这种方案一般对运营商来说是无法承受的。

  共享数据库,隔离数据架构

  

  这是第二种方案,即多个或所有租户共享Database,但一个Tenant一个Schema

  优点:

  为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可以支持更多的租户数量。

  缺点:

  如果出现故障,数据恢复比较困难,因为恢复数据库将牵扯到其他租户的数据;如果需要跨租户统计数据,存在一定困难。

  共享数据库,共享数据架构

  

  这是第三种方案,即租户共享同一个Database、同一个Schema,但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。

  优点:

  三种方案比较,第三种方案的维护和购置成本最低,允许每个数据库支持的租户数量最多。

  缺点:

  隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量;数据备份和恢复最困难,需要逐表逐条备份和还原。

  如果希望以最少的服务器为最多的租户提供服务,并且租户接受以牺牲隔离级别换取降低成本,这种方案最适合。

  总结

  三种方案好比学生分宿舍,隔离数据库就好比10名学生一人一个宿舍,每个人拿着自己宿舍的钥匙,一般贵族学校才有的待遇,学生都得是土豪;共享数据库,隔离数据架构就好比10名学生一个宿舍,没人一把宿舍钥匙,一般家庭的学生都能住;共享数据库,共享数据架构就是家里条件比较差的学生,10个人一个宿舍,连宿舍钥匙都配不起,大家只有一把钥匙。

时间: 2024-11-19 03:36:24

SaaS多租户模式数据存储方案比较的相关文章

SaaS多租户模式数据存储方案

  云计算多租户几乎用于所有软件即服务 (Software as a Service, SaaS) 应用程序,因为计算资源是可伸缩的,而且这些资源的分配由实际使用决定.话虽如此,用户可以通过 Internet 访问多种类型的 SaaS 应用程序,从小的基于 Internet 的小部件到大型企业软件应用程序.根据存储在企业网络之外的软件供应商的基础架构上的数据不同,安全需求也在不断增长.应用程序需要多租户是有许多原因的,其中最明显的原因就是成本:在大多数情况下,为每个客户增加几个服务器和一个数据库

Android Learning:数据存储方案归纳与总结

前言 最近在学习<第一行android代码>和<疯狂android讲义>,我的感触是Android应用的本质其实就是数据的处理,包括数据的接收,存储,处理以及显示,我想针对这几环分别写一篇博客,记得我的学习心得,也希望跟各位新手同学相互努力促进.今天这篇博客,我想介绍一下数据的存储,因为数据的接收,存储,处理以及显示这几环环环相扣,而数据的存储直接关系到数据的处理和显示,所以显得尤为重要. 所以本文针对数据存储的常见方案和其使用进行了归纳.分为程序内存储和程序间数据访问,程序内存储

数据存储方案评估标准RDBMS or KV

作者:zhanhailiang 日期:2014-12-11 本文主要介绍常见的数据存储方案及相应选型的评估标准的介绍. Guideline:针对不同应用场景,针对性选择存储方式. 1. 数据存储方案 SQL: MySQL 5.5/5.6/MariaDB(对于Dev绝大多数场景下透明): Oracle|MS SQL暂不考虑: NoSQL: Memcached 1.4.21: Redis 2.8: MongoDB 2.6.6: Hbase 0.96/0.98: 2. 评估标准 RDBMS:(MySQ

大规模IM在线用户的计算和数据存储方案

简单的计算模型 1.如果一秒钟处理1000笔请求(每条都进行存储),那么一天的数据量是:24*60*60*1000=8640万:如果每秒1万笔的话,数据大概是8.64亿 2.行业里一般的统计方法是峰值是日活量的五分之一,日活是总用户的8%.按照,按照峰值1万来进行计算的话,总的用户数是: 1万*5/0.08=62.5万,另外付费用户占总用户一般在5%左右,具体看运营情况. 3.日活跃用户产生峰值的计算:一般的消息类的,大概能到0.5%到1%就不错(一秒钟同时发出,网络游戏可能有点不一样,会高一点

BLOB数据存储方案

BLOB 数据存储方案 介绍 本文旨在介绍在SQL Server中用于存储BLOB(Binary Large Object)数据的类型和方法,例如图像.声音和视频等.从SQL Server 2000的类型和方法一直到SQL Server 2012的FileTable类型. 什么是BLOB 在实际应用中,如Web站点中展示的产品图片,客户端软件中展示的一些电子文档如PDF.Power Point.甚至一些声音和视频.换句话说,不是文本.一种处理这些电子文档的方式是将它们上传到一个文件服务器,创建目

Sqlserver 高并发和大数据存储方案

随着用户的日益递增,日活和峰值的暴涨,数据库处理性能面临着巨大的挑战.下面分享下对实际10万+峰值的平台的数据库优化方案.与大家一起讨论,互相学习提高!  案例:游戏平台. 1.解决高并发 当客户端连接数达到峰值的时候,服务端对连接的维护与处理这里暂时不做讨论.当多个写请求到数据库的时候,这时候需要对多张表进行插入,尤其一些表 达到每天千万+的存储,随着时间的积累,传统的同步写入数据的方式显然不可取,经过试验,通过异步插入的方式改善了许多,但与此同时,对读取数据的实时性也需要做一定的牺牲. 异步

Android--SharedPreferences数据存储方案

SharedPreferences是使用键值对的形式存储的,并且支持多种不同的数据类型,存的是String,取得值也是String. 使用SharedPreferences有三种方法: 1:    Context类中的getSharedPreferences()方法 这个方法需要两个参数,第一个参数用于指定SharedPreferences文件名称,如果指定的文件不存在则会创建一个,第二个参数用于指定操作模式,目前只有MODE_PRIVATE这一种模式可以选择,表示只有当前程序才可以对这个Sha

HTML5数据存储方案data与jQuery数据存储方案$.data()的区别

我们先看下$.fn.data()的使用,这个和$.data()是不一样的,前者是和某个jquery对象相关,后者则是全局方法.主要有data()和removeData()这2个实例方法.通过下面的例子和执行结果可以看到:$.fn.data()和$.fn.removeData()跟$.data的使用方式没有什么差别. // 支持任何数据类型 2. $( "body" ).data( "name", "xx" ); 3. $( "body&

2015年全国谷歌卫星地图离线数据存储方案

一.概述 随着地理信息数字化的发展,大数据时代的到来.海量数据的传输和安全性给我们带来巨大的困难.海量数据的传输受到互联网技术和硬件的限制,占用着较多的在线资源和线下存储空间,产生了能源.空间.人力的成本浪费,而在传输数据和存储过程中,不规范的操作造成的数据泄露,更是数据安全更须要保证或要解决的问题. 离线数据的应用,不仅避免了大传输数据带来的弊端,更保证了大数据在应用过程中的安全性.为本地可视化管理.分析.建模.开发等一站式服务提供有力保证. 笔者以2015年全国谷歌卫星地图(下面简称卫片)的