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

时间:2021-02-10 14:58:17

标签: database multi-tenant saas infrastructure

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

将这两种方法结合起来是闻所未闻的吗?通过这种方式,每个租户的数据库可以加快上市时间,同时逐步进行支持多租户数据库的开发更改。一旦这两种方法都是具有特别繁重的工作负载或安全限制的运营客户,就可以拥有自己的隔离数据库,但默认情况下将使用共享的公共数据库(出于成本/效率原因)。有没有人有在现实世界中使用/看到这种方法组合的经验?

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

1 个答案:

答案 0 :(得分:0)

横向扩展租户时存在复杂性,即将租户数据从共享数据库移动到独立数据库的数据。

由于实体表、映射表的识别和这些步骤的排序才能成功处理迁移,因此此过程的自动化需要付出努力和测试。此过程还需要考虑用于数据库的策略,如 <ul> <li class="hover">Item</li> <li class="hover">Item</li> <li class="hover">Item</li> <li class="hover">Item</li> </ul> <span class="navbar-top-border">Item 1</span> <span class="navbar-top-border">Item 2</span> <span class="navbar-top-border">Item 3</span> <span class="navbar-top-border">Item 4</span>ORM

与按行 ADO.NET 相比,如果我们可以在同一个数据库中为每个租户使用一个架构,那么执行这种迁移会更容易。

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