多租户应用程序：一个数据库或同一个数据库的多个副本 [英] 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?

推荐答案

在这里真正的问题是整体客户（或者更确切地说，激活）的服务隔离，这可以被认为是在不同层面为DB层资源共享：

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，网络，计算，可用性ECC），你不得不放弃了多租户和完全共享任何形式的资源。在极端情况下，这种推理意味着你需要一个单独的物理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屋！