多租户与多数据库

9
我正在开发一款定制的CRM解决方案,将通过Web/SaaS模式销售。我预计会有数十个或数百个客户使用此解决方案。我将使用MS SQL作为数据库引擎。
选项1是使用单个数据库,在表上包含一个TenantId列、适当的索引和在每个数据库访问中使用'where tenantId={...}'。
选项2是为每个客户创建独立的数据库,避免了需要使用TenantId和where子句。
我预计每个客户将有数十万条记录,而不是数百万条。
就我所知,无论我选择哪个选项,都将有总数据页数。决策似乎集中在SQL是否更擅长管理多个数据库,还是单个带有TenantId和索引的数据库。最初该解决方案将在单个数据库服务器上运行,但最终将迁移到SAN。
有人对此有什么看法吗?

1
你最终采用了哪种方法,为什么? - Petrus Theron
2个回答

4

有一篇有趣的MSDN文章,题为多租户数据架构,你可能想要查看。作者对某种方法何时比另一种方法更适用进行了简要分析:

你期望服务的租户数量、性质和需求都会以不同的方式影响到数据架构决策。以下问题中的一些可能会让你倾向于采用更加隔离的方法,而另一些可能会让你倾向于采用更加共享的方法。
- 你期望有多少潜在租户是你的目标?你可能无法准确估计潜在使用量,但可以从数量级上考虑:你是要为数百个租户构建应用程序吗?数千个?数万个?还是更多?你期望的租户基数越大,就越有可能考虑采用更加共享的方法。 - 你期望每个租户的数据占用多少存储空间?如果你期望一些或所有租户存储非常大量的数据,则最好采用分离的数据库方法。(实际上,数据存储要求可能会迫使你采用分离的数据库模型。如果是这样,从一开始就以这种方式设计应用程序要比后来转移到分离的数据库方法容易得多。) - 你期望每个租户支持多少并发终端用户?终端用户需求越高,采用更加隔离的方法就越合适。 - 你是否打算提供任何针对每个租户的增值服务,例如每个租户的备份和恢复能力?采用更加隔离的方法更容易提供此类服务。
请注意,“共享方法”是选项1,“隔离方法”是选项2,在您的情况下。当涉及前两个点时,您没有任何偏见,因此我认为我会基于最后两个点来做出决定。

0

如果您不需要在租户之间链接数据,最好使用多个数据库。这样维护更容易,设置更简单,性能也会更好。如果将多个租户的数据放在一个表中,则表锁定和对大表进行搜索查询可能会拖慢您的解决方案。

我唯一能想到共享一个数据库的原因是如果您有很多客户,每个客户的行数非常少。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接