建议采用哪种多租户方法

Question

根据多租户数据架构帖子，有三种实现多租户的方式

1. 单独的数据库

2. 共享数据库，独立架构

3. 共享数据库，共享架构

我有以下详细信息：

1. 用户应该能够备份和恢复他们的数据。

2. 租户人数：3人（约）

3. 每个租户可能属于不同的域名（网址）。

4. 所有租户都有一些共同的表格。

5. 每个租户中没有表：10（初始）

我想知道哪种方法更适合我？

Answer 1

我认为选项2是最好的选项，但是仍然存在需求问题1.每个架构都不提供备份和还原。您需要使用导入数据或任何自定义工具来处理此问题。公用表将具有单独的模式。

在选项1中，您需要处理要求4，将在所有数据库之间复制公用表。

Answer 2

所有5个条件中最重要的条件是条件4 - 它表示一些表在所有租户中都很常见。如果某些表是常见的，那么独立数据库（即选项1）将被排除。

您可以继续使用选项2，共享数据库和单独的架构，但租户数量相当少（在您的情况下为3）。在这种情况下，增加维护单独模式的开销是应该避免的开销。因此，我们也可以跳过选项2，直到我们评估选项3。

选项3 - 具有共享模式的共享数据库对您来说是最有效的选择。它避免了维护单独模式的开销，并允许租户之间的公共表。在共享模式中，通常在表之间使用租户标识符。 Hibernate已经支持这样的租户标识符（以防您将使用Java-J2EE实现）。 唯一的问题可能是性能，因为将所有三个租户的数据放在同一个表中将导致较低的数据库访问\搜索性能，您将不得不反规范化和索引。

我建议继续使用选项3。

Answer 3

对于我们来说，我们已经开发了人力资源ERP，大约有40个客户和数千名用户使用;用于多租户的方法是第三种方法。

此外，使用的技术分离表之一是遗产。

Answer 4

我的系统中遇到了同样的问题。我们有一个广告网络系统，随着时间的推移变得相当大，所以我考虑过每个发布商迁移到多租户架构。

选项3 并不相关，因为有些发布商有特殊要求（额外的列/程序，我们不支持分区）。由于我们在客户之间存在并发和负载问题，选项2 并不相关。为了实现高性能，计划向上扩展到1000个发布者，具有20个小部件和高并发性，我们唯一的解决方案是选项1 - 单独的数据库。

我们已经迁移到此模式，我们运行了10个数据库，其中包含用于配置和广告的共享数据库。从性能来看，它很棒。从高可用性来看，它也非常好，因为每个发布者流量都不会影响所有其他流量。添加新的发布者对我们来说是一个简单的步骤，因为我们有模板环境。我们唯一的问题是维护。

最近我一直在阅读PartitionDB，它看起来非常简单，因为您可以拥有一个门数据库来执行所有维护工作，包括升级和顶级查询。它支持公共共享数据库（我们已经相同），我现在正在尝试了解如何使用stand alone database。