【问题标题】:Multitenancy: Single database or database per tenant? [closed]多租户:单个数据库或每个租户的数据库? [关闭]
【发布时间】:2015-04-14 08:55:45
【问题描述】:

我们正处于一个新的多租户 SaaS 应用程序的规划阶段,并且已经达到了一个决定点。在设计多租户应用程序时,是选择一个包含所有客户数据的单一数据库(使用“customer_id”列)更好,还是每个客户都有一个独立的数据库更好?无论数据库决策如何,所有租户都将使用相同的代码库。

在我看来,拥有单独的数据库可以使备份/恢复更容易,但代价是增加了开发和升级的复杂性(升级 1 个数据库比 500 个更容易)。如果情况需要转移,也更容易/可能将单个客户拆分到单独的专用服务器。同时,在尝试全面了解客户如何使用该软件时,聚合数据变得更加困难。

我们预计在推出后至少一年内,客户数量将少于 250 人,但他们将成为大客户,之后还会有更多客户。

由于这是我们进入 SaaS 的第一次飞跃,我们肯定希望从一开始就做到这一点。

【问题讨论】:

标签: mysql database multi-tenant


【解决方案1】:

评论有点长。

在大多数情况下,您希望一个数据库在相应的表中具有单独的客户 ID 列。这使得维护应用程序变得更加容易。例如,替换一个数据库中的存储过程比替换 250 个数据库中的存储过程要容易得多。

在可扩展性方面,可能没有问题。如果您真的愿意,您可以按客户端对表进行分区。

出于某些原因,您希望每个客户端都有一个单独的数据库:

  • 访问控制:在数据库级别维护访问控制比在行级别更容易。
  • 定制:如果您可以在单一环境中工作,那么为客户定制软件会容易得多。
  • 性能瓶颈:如果数据非常大和/或系统上的事务非常多,将数据库分布在不同的服务器上可能比维护一个庞大的数据库更简单(也更便宜)。

但是,出于可维护性和一致性的考虑,我认为默认应该是一个数据库。

顺便说一下,关于备份和恢复。如果客户端需要此功能,您可能仍想编写自定义脚本。虽然您可以使用数据库级备份和恢复,但您可能有一些特殊需求,例如保持与未存储在数据库中的数据的一致性。

【讨论】:

  • 我赞成这个答案,因为它确实概述了两个用例之间的差异。我个人会选择一个数据库解决方案,纯粹是因为涉及多个数据库的管理方面。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-08-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-11-01
相关资源
最近更新 更多