使用具有每个客户的单独数据库模式的多租户体系结构有哪些优点？

Question

我有一个客户端希望我用多租户架构构建一个SaaS应用程序，不同的客户端将在同一个db服务器上构建一个单独的模式。我以前见过这种架构，但从未真正使用过，所以我对这个概念非常陌生。

我强烈反对这样做，因为我认为这会增加应用程序的复杂性。他们最关心的是安全问题。

通过使用这一点，我能看到的唯一安全改进是保护用户不受开发人员错误的影响：

• SQL注入
• SQL查询上的客户筛选器无效或丢失。

现代开发框架很好地处理了这两个问题(我计划使用Django)。除此之外，我看不出有什么好处。

Answer 1

“我认为这会给应用程序增加一定程度的复杂性”

..。反对什么-只对所有租户使用一种模式？

通常情况下，情况正好相反。在一个模式中实现多租户会增加数据可能属于不同租户的每个表的复杂性，这意味着这种复杂性也会进入您的应用程序。特别是当有很多表时，单独的模式实际上降低了应用程序的复杂性。让模式成为一个运行时可配置的参数，然后您几乎可以开发您的应用程序，就好像只有一个租户。

此外，它还使单个管理任务(如每个租户的单独备份/还原)变得非常容易。您甚至可以允许不同的租户同时在生产中使用不同版本的模式。

只有当模式中的大部分数据对所有租户都是相同的，并且数据不是由租户单独管理时，为所有租户创建一个模式才是有益的。

当然，在多模式方法中应该避免的是针对单个租户的不同模式自定义--这确实会增加某种您想要避免的复杂性。确保架构更改始终由版本化脚本(而不是“动态”)实现，这样就可以根据所有模式自动运行这些脚本(即使在使用单个模式时也需要这些脚本，因为您通常至少有一个dev数据库、一个测试数据库和一个要管理的生产数据库)。

根据DBMS的不同，您还可以考虑使用不同的数据库实例，这可能会给您提供更好的扩展体验。对于Oracle这样的系统来说，由于管理不同DB实例的管理开销，不同的模式可能是更好的选择。对于像MySql这样的系统，不同的数据库实例可能是有效的，也许是更好的方法(取决于您的情况)。

Answer 2

多租户体系结构具有可扩展性和安全性的优点。当您在一个表中拥有所有客户端数据时，所有客户都可以访问所有客户数据，而不是计算您为限制此访问而编写的代码。在多租户体系结构中，可以在db中设置不同的用户，并对身份验证过程进行简单得多的设计。

从规模化的角度来看，您不再需要庞大的索引来搜索，这会减缓查询的速度。数据与客户无关，至少与客户无关，因为它们属于不同的客户。出于这个原因，分离数据是有意义的。

如果您也在不同的实例中设置了体系结构，那么您可以在需要的地方分配资源，以及增加一个安全级别。

使用不同的实例可以非常好，也可以根据应用程序的特性使事情复杂化。

我不同意这种架构会增加应用程序的复杂性。如果有的话，它应该简化。