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

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

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

• 单个数据库不工作
• 引用完整性是不可能的
• 任何数据丢失都是一个问题
• 缓存很好,即使它的效率很低
• 不要低估增长轨迹

来源:

LinkedIn architecture

LinkedIn communication architecture

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

对于SaaS应用程序,您可以为多个租户使用多个数据库,但通常不会将其模块化。

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

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

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

按特性分割数据库可能不是一个好主意,除非您看到强有力的证据表明需要。通常,您可能需要将两个数据库作为单个事务的一部分进行更新,而分布式事务更难处理。此外,如果需要拆分数据库,则可以使用切分。

实现它的方法有很多种,但是多租户的问题要比数据模型的问题更深。我不想插拔产品,但是看看 SaaSGrid 在我的公司工作, Apprenda 。我们是一个云操作系统,允许您编写单租户SOA应用程序(随意使用nhibernate进行数据访问),自动将多租户注入您的应用程序。当你发布你的应用时,你可以做一些事情,比如选择一个数据模型(独立的数据库或共享的),SaaSgrid将相应地部署,你的应用运行时不会发生任何代码更改-只需编写代码,就好像它是为一个租户编写的一样!

为什么要使用数据库?

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

我认为DB对于像货币操作这样的敏感数据很好,但是对于其他任何东西,您都可以使用分布式存储。

问问你自己:把所有的东西都转移到不同的数据库中会得到什么?

我想在管理方面会有很多痛苦。我个人更希望把所有的东西都放在一个数据库中,如果您遇到了以后单个数据库无法解决的问题,那么就将数据迁移到多个数据库中。

保持它的自然设计(根据需要反规范化,根据需要标准化更少)。将DB模型拆分为其模块,并通过将数据与服务(拥有数据)放在一起来记住面向服务的原则。