MultiTenant与多个DB

Question

我正在开发一个定制的CRM解决方案,它将通过Web/SaaS模型销售.我预计有数百或数百个客户使用此解决方案.我将使用MS SQL作为数据库引擎.

选项1是拥有一个DB,并在表上包含一个TenantId列,一个合适的索引,并在每个数据库访问中使用'where tenantId = {...}'.

选项2是为每个客户端提供一个单独的DB,从而避免使用TenantId和where子句.

我预计每个客户将拥有数十万条记录,而不是数百万条记录.

在我看来,无论我选择哪种选项,都会有一定数量的数据页面.这个决定似乎集中在SQL是否更好地管理多个DB,或者是一个具有TenantId和索引的DB.最初,该解决方案将在单个数据库服务器上运行,但最终将转移到SAN.

有没有人对此有任何意见？

Answer 1

有一篇有趣的 MSDN 文章，标题为“多租户数据架构”，您可能想查看一下。作者对某种方法可能比另一种方法更合适的情况进行了简要分析：

您期望服务的租户的数量、性质和需求都会以不同的方式影响您的数据架构决策。以下一些问题可能会让您偏向于更加孤立的方法，而另一些问题可能会让您偏向于更加共享的方法。

• 您预计有多少潜在租户？您可能远无法权威地估计预期使用情况，但请从数量级角度思考：您是否正在为数百个租户构建应用程序？数千？成千上万？更多的？您期望租户基础越大，您就越有可能考虑采用更加共享的方法。

• 您预计租户的数据平均占用多少存储空间？如果您希望部分或所有租户存储大量数据，那么单独数据库方法可能是最好的。（事实上​​，数据存储要求可能会迫使您采用单独的数据库模型。如果是这样，从一开始就以这种方式设计应用程序比稍后转向单独的数据库方法要容易得多。）

• 您期望租户平均支持多少个并发最终用户？数字越大，越适合采用更独立的方法来满足最终用户的要求。

• 您是否期望提供任何每租户增值服务，例如每租户备份和恢复功能？通过更加孤立的方法更容易提供此类服务。

请注意，根据您的情况，“共享方法”是选项 1，“隔离方法”是选项 2。对于前两点，你们都没有偏见，所以我想我会根据后两点做出决定。