电子商务 SaaS 的 Postgres 共享模式多租户设置答案

【问题标题】：Postgres shared schema multi-tenant setup for e-commerce SaaS电子商务 SaaS 的 Postgres 共享模式多租户设置
【发布时间】：2016-07-01 08:49:25
【问题描述】：

我针对电子商务项目的最佳多租户设置进行了大量研究，但找不到合适的答案。我倾向于使用 MySQL 或 PostgreSQL 的共享数据库单独模式设置。所有租户的表结构都相同。我真的很喜欢这种设置，应用程序代码不需要为每个查询提供额外的 WHERE 子句，因此它对开发人员非常友好！

现在您还拥有共享架构方法，这就是我目前正在使用的方法，但我觉得这不利于安全和隔离目的。我想换一种解决方案。

今年该应用程序将被 +- 100 家网上商店（一个租户）使用，我预计它会增长到数千家。网上商店的范围从小到大，因此我以后可以挑选出特定的商店数据并将其放入自己的数据库服务器中，这一点很重要。

由于我对单独的架构设置没有任何经验，我想知道这是否对我有益。走那条路时我可能会遇到什么问题？尤其是随着表格结构的变化，这是最困扰我的。在使用 PostgreSQL 的单独模式方法中使用模式的限制是什么（我将有 100-1000 个模式），否则管理起来会很痛苦？

【问题讨论】：

【解决方案1】：

以下是我的看法

块引用

当为所有租户使用带有同一张表的 SharedDatabase 时，tenantid 列的隔离很容易，因为您总是添加一个过滤器，上面写着tenantid = LoggedInTenantId [LoggedInTenantId => 在登录期间设置]。如果您的 ORM 中有一个基本方法，例如 EF [我来自 .Net]，这将自动附加到任何超出代码的查询。
当您选择共享架构时，如果存在租户 [网上商店] 之间共享数据之类的用例，则不可行。否则，如果您的会计师想要审核租户的集合并想要仪表板来查看 a/c 统计信息等，那将变得不可能
从扩展的角度来看，如果单个租户或它们的集合想要扩展，您最好为每个租户使用单独的数据库。这将比管理架构更好。

考虑您可能拥有的产品用例并在此处分享，以便我们继续讨论。

HTH

【讨论】：

感谢您对此的意见！对于仪表板统计，我使用的是 ElasticSearch，因此部分数据（产品、订单、客户）也存储在那里，因此我跨租户收集统计数据并非不可能。我更想知道管理一千个不同的模式有多糟糕。对于性能，我认为单独的模式也更好，因为每个租户的持久数据都会被分开。不确定如何在共享模式中也实现这样的性能？此外，使用分离的架构设置，备份或将租户移动到自己更大的数据库似乎更容易。
嗨@Steffen Brem，请注意，我认为订单表可以扩展到单独的数据库，从缓存中更改客户资料最少，使用redis缓存，我们可以通过代码和允许缓存和扩展数据库以默认方式工作。请分享您对此的想法。