【发布时间】：2010-09-09 07:22:41
【问题描述】：
我见过以多种不同方式托管的 SaaS 应用程序。跨多个数据库拆分功能和模块是个好主意吗？例如，将 User 表放在一个 DB 上，将功能/应用特定的表放在另一个 DB 上，或者将其他常用共享表放在另一个 DB 上？
【问题讨论】：
标签： database-design architecture database-schema multi-tenant saas
【发布时间】：2010-09-09 07:22:41
【问题描述】：
从一个数据库开始。在项目需要时拆分数据/功能。
以下是我们可以从 LinkedIn 中学到的东西：
- 单个数据库不起作用
- 无法实现参照完整性
- 任何数据丢失都是一个问题
- 缓存效果不错，即使效果不大
- 永远不要低估增长轨迹
来源：
【讨论】：
High Scalability 是一个很好的扩展 SaaS 应用程序的博客。如前所述，按照您的建议跨数据库拆分表通常是一个坏主意。但是一个类似的概念是分片，您保持相同（或相似）的模式，但将数据拆分到多个服务器上。例如，用户 1-5000 在 server1 上，用户 5000-10000 在 server2 上。根据您的应用程序使用的查询，它可能是一种有效的扩展方式。
【讨论】：
对于 SaaS 应用程序，您为多个租户使用多个数据库，但通常不会按模块拆分。
这是我在 SaaS 应用程序设计中看到的最常见的模型。您添加到应用程序的每个租户都会复制您的基本架构。
【讨论】：
-
大多数 saas 应用都是 1 db，由 user_id 或 account_id 限定
拥有单个数据库最有利于数据完整性，因为这样您就可以使用外键。如果您将数据拆分到多个数据库中，则无法获得此内置数据完整性。如果您的数据不相关，这不是问题，但如果相关，您的一个数据库可能包含与另一个数据库不一致的数据。在这种情况下，您需要编写一些代码来定期扫描您的数据库中的不一致数据，以便您可以适当地处理它。
但是，如果您需要您的网站/应用程序具有高度可扩展性（例如互联网规模），则可能需要多个数据库。例如，您可以将每个数据库托管在不同的物理服务器上。
【讨论】：
-
如果我们将所有数据保存在一个地方，那么数据库大小会怎样呢？我相信我们有某种限制。
除非您看到强有力的证据表明需要，否则按功能拆分数据库可能不是一个好主意。通常，您可能需要更新两个数据库作为单个事务的一部分——分布式事务更难处理。此外，如果需要拆分数据库，您也许可以使用分片。
【讨论】：
问问自己：将所有内容转移到单独的数据库中可以获得什么？
我猜在管理方面会有很多痛苦。我个人更热衷于将所有内容都放在一个数据库中，如果您以后遇到单个数据库无法解决的问题，则将数据迁移到多个数据库中。
【讨论】：
查看 Azure SQL 的多租户 SaaS 数据库租户模式，其中详细列出了解决方案和决策标准。
https://docs.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-app-design-patterns
接下来的讨论中包含了很多来自曾经做过这件事的开发者的反馈。如果可以的话，一般的共识是避免使用多个数据库并自动强制执行仅租户查询。 SQL Azure 提供行级安全性来帮助实现这一点。它也可以在应用程序级别完成。
最后一个想法.. 一开始选择单个数据库，并不排除您以后使用每个租户的数据库。您甚至可以稍后在一个数据库中支持许多较小的客户，而大型或付费客户拥有自己的数据库。但是，从每个租户的数据库开始意味着如果您以后切换回每个数据库的多个租户，您将承担大量迁移成本。
【讨论】：
保持自然设计（尽可能多地去规范化，尽可能少地规范化）。将 DB 模型拆分为其模块，并通过将数据与服务（拥有数据）放在一起来牢记面向服务的原则。
【讨论】：
为什么要使用数据库？
我认为使用 Hadoop、Voldemort（LinkedIn 开发和使用的 project-voldemort.com）等分布式存储系统是个好主意。
我认为 db 适合用于货币操作等敏感数据，但对于其他所有内容，您都可以使用分布式存储。
【讨论】：