如何使用共享表结构创建多租户数据库？

Question

我们的软件目前在MySQL上运行.所有租户的数据都存储在同一架构中.由于我们使用Ruby on Rails,我们可以轻松确定哪些数据属于哪个租户.然而,有些公司当然担心他们的数据可能会受到损害,因此我们正在评估其他解决方案.

到目前为止,我已经看到三个选项:

• 多数据库(每个租户都有自己的 - 几乎与每个客户的1个服务器相同)
• 多模式(MySQL中不可用,每个租户在共享数据库中获取自己的模式)
• 共享架构(我们当前的方法,可能在每列上有额外的识别记录)

Multi-Schema是我最喜欢的(考虑成本).但是,创建一个新帐户并进行迁移似乎非常痛苦,因为我必须迭代所有模式并更改其表/列/定义.

问:多架构似乎被设计为每个租户的表格略有不同 - 我不希望这样.是否有任何RDBMS允许我使用多模式多租户解决方案,其中表结构在所有租户之间共享？

PS通过multi我的意思是像超多(10.000+租户).

Answer 1

然而,有些公司当然担心他们的数据可能会受到损害,因此我们正在评估其他解决方案.

这是不幸的,因为客户有时会误以为只有物理隔离才能提供足够的安全性.

有一篇有趣的MSDN文章,标题为多租户数据架构,您可能需要检查.这就是作者如何解决对共享方法的误解:

一种常见的误解认为只有物理隔离才能提供适当的安全级别.事实上,使用共享方法存储的数据也可以提供强大的数据安全性,但需要使用更复杂的设计模式.

至于技术和业务方面的考虑,本文简要分析了某种方法可能比另一种方法更合适的地方:

您希望服务的租户的数量,性质和需求都会以不同的方式影响您的数据架构决策.以下某些问题可能会使您偏向于更加孤立的方法,而其他问题可能会使您偏向更为共享的方法.

• 您期望有多少潜在租户？您可能无法估计有权使用的预期用途,但请考虑数量级:您是否正在为数百个租户构建应用程序？成千上万的？成千上万？更多？您希望租户基数越大,您就越有可能考虑采用更加共享的方法.

• 您希望平均租户的数据占用多少存储空间？如果您希望部分或全部租户存储大量数据,则单独数据库方法可能是最佳方法.(实际上,数据存储要求可能会迫使您采用单独的数据库模型.如果是这样,从一开始就设计应用程序要比以后转移到单独的数据库方法要容易得多.)

• 您希望普通租户支持多少并发最终用户？数字越大,更孤立的方法越适合满足最终用户的要求.

• 您是否希望提供任何每租户增值服务,例如每租户备份和恢复功能？通过更加孤立的方法更容易提供此类服务.

更新:进一步更新预计的租户数量.

对于大多数情况(即使不是所有情况),预期的租户数量(10k)应排除多数据库方法.我不认为你会想到维护10,000个数据库实例,并且每天必须创建数百个新数据库实例.

仅从该参数看,共享数据库,单模式方法看起来最合适.事实上,您将为每个租户存储大约50Mb,并且不存在每个租户附加组件,这使得这种方法更加合适.

上面引用的MSDN文章提到了三种安全模式,它们解决了共享数据库方法的安全性问题:

• 可信数据库连接
• 租户视图过滤器
• 租户数据加密

当您对应用程序的数据安全措施有信心时,您将能够为您的客户提供服务级别协议,以提供强大的数据安全保障.在您的SLA中,除了保证之外,您还可以描述您将采取的措施,以确保数据不会受到损害.

更新2:显然,微软的家伙移动/做出关于这一主题的新文章,原链接消失了,这是新的:多租户SaaS的数据库租赁模式(荣誉给晒Kerer)

Answer 2

我的经验(尽管是SQL Server)是多数据库的方法,每个客户端都有自己的数据库.因此,尽管我没有mySQL或Ruby On Rails体验,但我希望我的输入可能会增加一些价值.

原因包括:

1. 数据安全/灾难恢复.每个公司的数据是从别人给予减少数据的风险完全存储分别被泄露(思考的东西一样,如果你介绍的一个代码错误,这意味着什么错误着眼于其他客户的数据时,它不应该),潜在损失减少到一个客户端,如果一个特定的数据库被破坏等.客户感知到的安全性好处甚至更大(增加额外的副作用!)
2. 可扩展性.基本上,您需要将数据分区以实现更高的可伸缩性 - 例如,可以将数据库放在不同的磁盘上,您可以将多个数据库服务器联机,并且可以更轻松地移动数据库以分散负载.
3. 性能调整.假设你有一个非常大的客户端和一个非常小的客户端.使用模式,数据量等可能会有很大差异.如果需要,您可以更轻松地为每个客户调整/优化.

我希望这确实提供了一些有用的输入!还有更多原因,但我的想法一片空白.如果它重新开始,我会更新:)

编辑:
自从我发布这个答案后,现在很清楚我们正在谈论10,000多个租户.我的经验是在数百个大型数据库中 - 我不认为10,000个单独的数据库对于您的方案来说太容易管理,所以我现在不喜欢您的方案的多数据库方法.特别是现在很清楚,你正在谈论每个租户的小数据量!

无论如何在这里保留我的答案,因为它可能对类似船上的其他人有一些用处(租户较少)

Answer 3

以下是Salesforce.com上有关如何实施多租户的白皮书的链接:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

他们有1个巨大的表w/500字符串列(Value0,Value1,... Value500).日期和数字以一种格式存储为字符串,以便它们可以在数据库级别转换为其本机类型.有一些元数据表定义了数据模型的形状,每个租户可以是唯一的.还有其他表用于索引,关系,唯一值等.

为什么麻烦？

每个租户都可以在运行时自定义自己的数据模式,而无需在数据库级别(alter table等)进行更改.这绝对是做这样的事情的艰难方法,但非常灵活.

Answer 4

正如您所提到的,每个租户的一个数据库是一个选项,并且与它有一些更大的权衡.它可以在较小的规模下很好地工作,例如单个数字或低10个租户,但除此之外,它变得更难管理.这两者都只是迁移,但也只是保持数据库的正常运行.

每个模式模型不仅对每个模式的唯一模式都有用,尽管仍然在所有租户中运行的迁移变得困难,并且在1000个模式下Postgres可能开始出现问题.

更具可扩展性的方法绝对是让租户随机分布,存储在同一个数据库中,但是跨越不同的逻辑分片(或表).根据您的语言,有许多库可以帮助解决这个问题.如果您正在使用Rails,那么可以使用一个库来管理租赁acts_as_tenant,这有助于确保您的租户查询仅撤回该数据.还有一个gem apartment- 虽然它使用模式模型,但它确实有助于跨所有模式的迁移.如果您正在使用Django,那么有一个数字,但其中一个更受欢迎的似乎是跨模式.所有这些在应用程序级别提供更多帮助.如果您正在直接在数据库级别寻找更多内容,Citus专注于为Postgres提供更多开箱即用的多租户工作类型的分片.