多租户应用:一个数据库或同一个数据库的多个副本 [英] Multi-tenancy application: one database or multiple copies of same database

问题描述

更多的架构问题.创建多租户应用程序的最佳实践是什么?为所有租户使用单个数据库还是为每个租户使用单独的架构/数据库实例?

It more architectural question. What is best practice creating multi-tenancy applicaton? Use single database for all tenants or use separate schema/database instance for each tenant?

推荐答案

这里真正的问题是整体客户(或者更确切地说是激活)服务隔离，可以在数据库层的不同资源共享级别考虑:

The real issue here is overall customer (or rather activation) service segregation, which can be thought of at different levels of resource sharing for the DB tier:

>

• 应用逻辑层:不需要单独的架构/数据库，可以有更好的性能，可以带来更好的资源优化，可以帮助实现交叉激活逻辑(如果有)，但提供最少的隔离:一次激活可能会影响(由于错误行为加上限制不足或仅仅因为错误)其他激活的所有数据、性能和可用性服务级别.
• 架构级别:同上，但激活几乎不可能影响其他激活的数据服务级别，应用逻辑问题更难做到这一点.
• 数据库级别:同上但更强；从这一点开始，备份数据开始变得越来越复杂.
• 数据库服务流程级别:如上所述，但即使是应用程序也几乎不可能影响交叉激活数据服务级别.此外，可以在操作系统级别对性能隔离进行更多的性能调整，但计算和 I/O 资源仍是共享的，因此也不可能进行可用性隔离.
• 数据库虚拟实例(= 虚拟服务器)级别:如上所述，但不太可能存在交叉激活性能和可用性问题，尽管当虚拟服务器位于相同的物理硬件上时，仍然不是不可能.
• 数据库物理实例(= 物理服务器)级别:如上所述，但实际上不可能存在交叉激活性能和可用性问题.
• Application logic level: doesn't require separate schema/database, can have better performance, can lead to better resources optimization, can help implementing cross-activation logic (if any) but offers least segregation: one activation can impact (because of wrong behaviour combined with insufficient restrictions or simply because of bugs) all of data, performance and availability service levels of other activations.
• Schema level: as above but it is almost impossible for activations to impact data service levels of other activations and much more difficult for application logic issues to do so.
• Database level: as above but stronger; from this point down backing up data starts becoming more involved.
• Database service process level: as above but it's almost impossible even for applications to impact cross-activations data service levels. Furthermore, more performance tuning for performance segregation becomes possible at OS-level but the computational and I/O resources are still shared, so no availability segregation is possible either.
• Database virtual instance (= virtual server) level: as above but it is unlikely to have cross-activations performance and availability issues, still not impossible though when virtual servers are on the same physical hardware.
• Database physical instance (= physical server) level: as above but practically impossible to have cross-activations performance and availability issues.

以上推理仅针对 DB 层，它通常是最下面的一层，但类似的推理也适用于任何其他层.

The above reasoning is only about the DB tier, which is normally the downmost one, but similar reasoning can be applied to any other tier as well.

也就是说，为了在所有方面(I/O、网络、计算、可用性等)实现真正全面的客户服务级别隔离，您必须完全放弃多租户和任何形式的资源共享.在极端情况下，这种推理意味着您需要一个单独的物理 IDC，每次激活都具有专用连接.

That is, in order to have real full-blown customer service level segregation in all concerns (I/O, network, computation, availability ecc.) you have to give up multi-tenancy and any form of resource sharing altogether. At its extreme, this reasoning means you'd need a separate physical IDC with dedicated connectivity per activation.

这篇关于多租户应用:一个数据库或同一个数据库的多个副本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！