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

时间:2008-09-16 03:18:10

标签: database-design architecture database-schema multi-tenant saas

我见过SaaS应用程序以多种不同的方式托管。跨多个数据库拆分功能和模块是一个好主意吗?例如,将User表放在一个DB上,将功能/ app特定表放在另一个DB上,也可能放在另一个DB中的其他常用共享表中?

10 个答案:

答案 0 :(得分:32)

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

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

  • 单个数据库不起作用
  • 无法实现参照完整性
  • 任何数据丢失都是一个问题
  • 即使适度有效,缓存仍然很好
  • 永远不要低估增长轨迹

来源:

LinkedIn architecture

LinkedIn communication architecture

答案 1 :(得分:12)

High Scalability是一个用于扩展SaaS应用程序的好博客。如前所述,按照您的建议在数据库之间拆分表通常是个坏主意。但是类似的概念是分片,您可以保持相同(或类似)架构,但在多个服务器上分割数据。例如,用户1-5000在server1上,用户5000-10000在server2上。根据您的应用程序使用的查询,它可能是一种有效的扩展方式。

答案 2 :(得分:8)

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

这是我在SaaS应用程序设计中看到的最常见的模型。将为添加到应用程序的每个租户复制基础架构。

答案 3 :(得分:3)

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

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

答案 4 :(得分:3)

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

答案 5 :(得分:1)

有多种方法可以实现它,但多租户问题比数据模型更深入。我讨厌插入产品,但请查看我工作的公司SaaSGrid Apprenda。我们是一个云操作系统,允许您编写单租户SOA应用程序(随意使用) NHibernate用于数据访问),可自动将多租户注入您的应用程序。当您发布应用程序时,您可以执行诸如选择数据模型(隔离数据库或共享)之类的操作,SaaSGrid将相应地进行部署,您的应用程序将在没有任何代码更改的情况下运行 - 只需编写代码就像单个租户一样!

答案 6 :(得分:1)

为什么要使用数据库?

我认为使用分布式存储系统是个好主意,例如Hadoop,Voldemort(由LinkedIn开发和使用的project-voldemort.com)。

我认为数据库对于钱操作这样的敏感数据很有用,但对于其他一切你可以使用分布式存储。

答案 7 :(得分:0)

问问自己:将所有内容移到单独的数据库中会得到什么?

管理方面的许多痛苦都是我的猜测。我个人更热衷于将所有内容都放在一个数据库中,如果遇到以后无法通过单个数据库解决的问题,那么请将数据迁移到多个数据库中。

答案 8 :(得分:0)

保持自然设计(根据需要进行非规范化,根据需要进行标准化)。将数据库模型拆分为其模块,并通过使用服务(拥有数据)前端数据来记住面向服务的原则。

答案 9 :(得分:0)

看看Azure SQL的多租户SaaS数据库租用模式,其中详细介绍了解决方案和决策标准的列表。

https://docs.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-app-design-patterns

下一个讨论将包括许多来此的开发人员的反馈。通常的共识是,如果可以并避免自动执行仅租户查询,则避免使用多个数据库。 SQL Azure提供行级安全性来协助完成此任务。也可以在应用程序级别完成。

https://www.indiehackers.com/post/should-i-keep-only-one-database-for-each-customer-in-a-saas-product-2af0af42f4

一个最后的想法..从一开始就选择单个数据库,这并不排除您以后再按每个租户使用数据库。您甚至可以稍后在一个数据库中为许多较小的客户提供支持,而大型或高级付费客户则拥有自己的数据库。但是,从每个租户开始使用数据库意味着如果您以后再切换回每个数据库多个租户,则将需要大量的迁移成本。