SaaS database design - Multiple Databases? Split?我已经看到以许多不同的方式托管SaaS应用程序。 在多个数据库之间拆分功能和模块是一个好主意吗？ 例如，将诸如User表之类放在一个DB上，将特定于功能/应用程序的表放在另一个DB上，也许将其他常见的共享表放在另一个DB中？ 从一个数据库开始。在项目需要时拆分数据/功能。 这是我们可以从LinkedIn获得的知识：
资源： LinkedIn架构 LinkedIn通讯架构 高可伸缩性是用于扩展SaaS应用程序的好博客。如前所述，按照您的建议在数据库之间拆分表通常不是一个好主意。但是类似的概念是分片，即您保留相同(或相似)架构，但将数据拆分到多个服务器上。例如，用户1-5000在服务器1上，用户5000-10000在服务器2上。根据您的应用程序使用的查询，这可能是一种有效的扩展方式。 对于SaaS应用程序，您将多个数据库用于多个租户，但通常不按模块拆分它。 这是我在SaaS应用程序设计中看到的最常见的模型。将为您添加到应用程序中的每个租户复制基本架构。 拥有单个数据库最有利于数据完整性，因为这样便可以使用外键。如果将数据拆分到多个数据库中，则无法拥有这种内置的数据完整性。如果您的数据不相关，这不是问题，但是如果相关，则您的一个数据库可能包含与另一个数据库不一致的数据。在这种情况下，您将需要编写一些代码来定期扫描数据库中的不一致数据，以便您可以适当地处理它。 但是，如果您需要站点/应用程序具有高度可扩展性(例如，互联网规模)，则可能需要多个数据库。例如，您可以将每个数据库托管在不同的物理服务器上。 除非您看到有力的证据表明有必要，否则按功能拆分数据库可能不是一个好主意。通常，您可能需要在单个事务中更新两个数据库-分布式事务更难处理。此外，如果需要拆分数据库，则可以使用分片。 为什么要使用数据库？ 我认为使用像Hadoop，Voldemort(由LinkedIn开发和使用的project-voldemort.com)这样的分布式存储系统是个好主意。 我认为db适用于诸如money操作之类的敏感数据，但是对于其他所有内容，您都可以使用分布式存储。 有多种方法可以实现它，但是多租户问题比数据模型更深。我不喜欢插入产品，但是请到我所在的公司Apprenda来查看SaaSGrid。我们是一个云操作系统，允许您编写单个租户SOA应用程序(随意使用NHibernate进行数据访问)并自动注入多租户进入您的应用。发布应用程序时，您可以执行诸如选择数据模型(隔离数据库或共享数据库)之类的操作，并且SaaSGrid将进行相应部署，并且您的应用程序将运行而无需任何代码更改-就像编写单个租户一样编写代码！ 问自己：将所有内容移到单独的数据库中会得到什么？ 我的猜测是管理方面的很多痛苦。我个人更希望将所有内容都放在一个数据库中，如果您遇到无法由单个数据库解决的问题，则可以将数据迁移到多个数据库中。 保持其自然的设计(根据需要尽可能多地进行规格化，而根据需要减少规格化)。将数据库模型分成其模块，并通过在数据前面拥有服务(拥有数据)来牢记面向服务的原则。 |
