SaaS 数据库设计 - 多个数据库？分裂？

Question

我见过以多种不同方式托管的 SaaS 应用程序。将功能和模块拆分到多个数据库是一个好主意吗？例如，将用户表等内容放在一个数据库上，将功能/应用程序特定表放在另一个数据库上，也许将其他常用共享表放在另一个数据库上？

Answer 1

从一个数据库开始。当项目需要时拆分数据/功能。

以下是我们可以从 LinkedIn 学到的东西：

• 单一数据库不行
• 引用完整性将不可能实现
• 任何数据丢失都是一个问题
• 缓存虽然效率不高，但还是很好的
• 永远不要低估增长轨迹

来源：

领英架构

LinkedIn 通信架构

Answer 2

高扩展性 是一个关于扩展 SaaS 应用程序的好博客。如前所述，按照您的建议跨数据库拆分表通常是一个坏主意。但类似的概念是分片，即保留相同（或相似）的模式，但将数据拆分到多个服务器上。例如，用户 1-5000 在 server1 上，用户 5000-10000 在 server2 上。根据您的应用程序使用的查询，它可能是一种有效的扩展方式。

Answer 3

对于 SaaS 应用程序，您可以为多个租户使用多个数据库，但通常不会按模块进行拆分。

这是我在 SaaS 应用程序设计中见过的最常见的模型。您的基本架构会为您添加到应用程序的每个租户进行复制。

Answer 4

拥有单个数据库最有利于数据完整性，因为这样您就可以使用外键。如果将数据拆分到多个数据库中，则无法获得这种内置数据完整性。如果您的数据不相关，这不是问题，但如果相关，您的一个数据库可能包含与另一数据库不一致的数据。在这种情况下，您需要编写一些代码来定期扫描数据库以查找不一致的数据，以便您可以适当地处理它。

但是，如果您需要站点/应用程序具有高度可扩展性（例如，互联网规模）。例如，您可以将每个数据库托管在不同的物理服务器上。

Answer 5

按功能拆分数据库可能不是一个好主意，除非您看到强有力的证据表明有必要。通常，您可能需要更新两个数据库作为单个事务的一部分 - 而分布式事务则更难使用。此外，如果数据库需要拆分，您也许可以采用分片。

Answer 6

有多种方法可以实现这一目标，但多租户的问题比数据模型更深入。我讨厌堵塞产品，但看看 SaaS网格 通过我工作的公司， 阿普伦达我们是一个云操作系统，允许您编写单租户 SOA 应用程序（可以随意使用 NHibernate 进行数据访问），并自动将多租户注入到您的应用程序中。当您发布应用程序时，您可以执行诸如选择数据模型（隔离数据库或共享）之类的操作，SaaSGrid 将进行相应部署，并且您的应用程序将无需任何代码更改即可运行 - 只需像为单个租户编写代码一样！

Answer 7

为什么要使用数据库？

我认为使用 Hadoop、Voldemort（由 LinkedIn 开发和使用的项目-voldemort.com）等分布式存储系统是个好主意。

我认为 db 对于金钱操作等敏感数据很有用，但对于其他一切，你可以使用分布式存储。

Answer 8

问你自己：将所有内容移至单独的数据库中可以获得什么？

我猜管理方面会有很多痛苦。我个人更愿意将所有内容都放在一个数据库中，如果稍后遇到单个数据库无法解决的问题，则将数据迁移到多个数据库中。

Answer 9

保持自然的设计（根据需要尽可能多地反规范化，根据需要尽可能少地规范化）。将数据库模型拆分为多个模块，并通过将数据置于服务（拥有数据）的前面，牢记面向服务的原则。