我已经看到以许多不同方式托管SaaS应用程序。在多个数据库之间拆分功能和模块是一个好主意吗？例如，将诸如User表之类放在一个DB上，将特定于功能/应用程序的表放在另一个DB上，也许将其他常用的共享表放在另一个DB上？

解决方案

回答

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

我的猜测是管理方面的很多痛苦。我个人更希望将所有内容都放在一个数据库中，如果我们遇到无法由单个数据库解决的问题，则可以将数据迁移到多个数据库中。

回答

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

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

回答

除非我们看到有力的证据表明有必要，否则按功能拆分数据库可能不是一个好主意。通常，我们可能需要在单个事务中更新两个数据库，而分布式事务则更难处理。此外，如果需要拆分数据库，则可以使用分片。

回答

高可伸缩性是一个用于扩展SaaS应用程序的好博客。如前所述，按照建议在数据库之间拆分表通常不是一个好主意。但是类似的概念是分片，即我们保留相同(或者相似)架构，但将数据拆分到多台服务器上。例如，用户1-5000在server1上，用户5000-10000在server2上。根据应用程序使用的查询，这可能是一种有效的扩展方式。

回答

对于SaaS应用程序，我们将多个数据库用于多个租户，但通常不按模块拆分它。

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

回答

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

这是我们可以从LinkedIn获得的知识：

• 单个数据库不起作用
• 参照完整性将无法实现
• 任何数据丢失都是一个问题
• 即使效果适中，缓存还是不错的
• 永远不要低估增长轨迹

来源：

领英建筑

LinkedIn通讯架构

回答

保持其自然的设计(根据需要进行更多的归一化，而根据需要进行更少的归一化)。将数据库模型分成其模块，并通过在数据前面拥有服务(拥有数据)来牢记面向服务的原则。

回答

有多种方法可以实现它，但是多租户问题比数据模型更深。我不喜欢插入产品，但是请到我工作的公司Apprenda来查看SaaSGrid。我们是一个云操作系统，允许我们编写单个租户SOA应用程序(随意使用NHibernate进行数据访问)并自动注入多租户进入应用。发布应用程序时，我们可以执行诸如选择数据模型(隔离数据库或者共享数据库)之类的操作，并且SaaSGrid将进行相应部署，并且应用程序将运行而无需任何代码更改，只需编写代码就好像是为单个租户编写的一样！

回答

为什么要使用数据库？

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

我认为db对于诸如money操作之类的敏感数据很有用，但是对于其他所有内容，我们都可以使用分布式存储。