多租户应用程序：一个数据库或同一数据库的多个副本

Question

这是一个更具架构性的问题。创建多租户应用的最佳做法是什么？对所有租户使用单个数据库，还是为每个租户使用单独的模式/数据库实例？

Answer 1

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

• 应用程序逻辑级别：不需要单独的架构/数据库，可以有更好的性能，可以带来更好的资源优化，可以帮助实现交叉激活逻辑（如果有的话）但是提供最少隔离：一次激活可能会影响（因为错误的行为加上限制不足或仅仅是因为错误）所有其他激活的数据，性能和可用性服务水平。
• 架构级别：如上所述，但激活几乎不可能影响其他激活的数据服务级别，而且应用程序逻辑问题也难以实现。
• 数据库级别：如上所述但更强;从这一点开始，备份数据开始变得更加复杂。
• 数据库服务流程级别：如上所述，但即使应用程序影响交叉激活数据服务级别，也几乎不可能。此外，在操作系统级别可以进行性能分离的更多性能调整，但计算和I / O资源仍然是共享的，因此也不可能进行可用性隔离。
• 数据库虚拟实例（=虚拟服务器）级别：如上所述，但不太可能存在交叉激活性能和可用性问题，但是当虚拟服务器位于同一物理硬件上时仍然不是不可能。
• 数据库物理实例（=物理服务器）级别：如上所述，但实际上不可能出现交叉激活性能和可用性问题。

上述推理仅涉及DB层，通常是最底层的，但类似的推理也可以应用于任何其他层。

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

Answer 2

有关故事的更多信息。该公司要求我对多租户的输入是使用共享主机启动 - 因此他们可以使用的数据库实例数量有限。

以下是我对请求者的提议： 使用单一数据库解决方案，因为这不需要额外费用

为了满足租户数据隔离的要求，我建议使用Views而不是Tables解决方案。 视图而不是表： 1.目前用户直接从表中选择数据 2.在将来的状态中，DB中的表将隐藏在视图中。该视图将使用当前登录的DB User作为选择标准。这样就实现了虚拟租户数据隔离。