组合单租户和多租户基础架构

Question

我正在评估将我们当前的本地 Java Web 应用程序迁移到 SAAS 平台的最佳方法。应用程序多租户似乎很简单，但数据库就不那么简单了。在这一点上，我们可能都知道每租户数据库的优点：隔离、性能、降低的备份/恢复复杂性以及低得多的改造复杂性。当然，每租户行的方法也有其好处，其中一个主要优点是降低了基础设施成本。

将这两种方法结合起来是不是闻所未闻？这样一来，每租户数据库的上市时间更快，而支持多租户数据库的开发变化正在逐步进行。一旦这两种方法都投入使用，具有特别繁重的工作负载或安全限制的客户可以拥有自己的隔离数据库，但默认情况下将使用共享的公共数据库（出于成本/效率原因）。有没有人在现实世界中使用/看到过这种方法的组合？

无论请求是通过租户 ID 路由到数据源，还是租户 ID 是 SQL 查询的参数，主要区别应该包含在持久层/数据库中，这在一定程度上限制了组合这两种方法所增加的复杂性。

Answer 1

当我们横向扩展租户时存在复杂性，即将租户数据从共享数据库移动到隔离数据库的数据。

由于要识别实体表、映射表和这些步骤的顺序，才能成功处理迁移，因此该过程的自动化需要付出努力和测试。这个过程也需要考虑用于数据库的策略，如ORM 或ADO.NET。

与按行排列 tenantid 相比，如果我们可以在同一个数据库中为每个租户使用一个模式，则执行这种迁移会更容易。

我们最初确实尝试过，但由于存在框架数据和应用程序/业务数据，因此在较短的时间范围内解决自动发生的迁移并不困难，但是如果有正确的时间和计划，这可以实现。