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