MySQL 多租户应用程序 - 表太多和性能问题答案

【问题标题】：MySQL Multi Tenant Application - Too Many Tables & Performance IssuesMySQL 多租户应用程序 - 表太多和性能问题
【发布时间】：2018-08-24 00:43:49
【问题描述】：

我正在开发一个多租户应用程序，我为每个租户在 LAMP 环境中的单个 MySQL 数据库中创建单独的 50 个表集。

除了大约 10 个大小在 50 到 200MB 之间的表之外，每个集合的平均表大小为 10 MB。

MySQL InnoDB 为每个表创建 2 个文件（.frm & .ibd）。

对于 100 个租户，将有 100 x 50 = 5000 个表 x 2 个文件 = 10,000 个文件

对我来说它看起来太高了。我是在以错误的方式做这件事，还是在这种情况下很常见。我还应该考虑哪些其他选择？

我也是read this question，但这个问题已被版主关闭，因此没有引起太多思考。

【问题讨论】：

标签： mysql database database-design multi-tenant

【解决方案1】：

每个租户拥有一个数据库。那将是 100 个目录，每个目录有 2*50 = 100 个文件。 100是合理的；在大多数操作系统中，一个目录中的 10,000 个项目是危险的。

附录

如果您有 15 个表供所有租户使用，请将它们放在一个额外的数据库中。如果您将该数据库称为 Common，请考虑以下代码片段：

USE Tenant;    -- Customer starts in his own db
SELECT ... FROM table1 ...;   -- Accesses `table1` for that tenant
SELECT a.this, b.blah
    FROM table1 AS a             -- tenant's table
    JOIN Common.foo AS b  ON ... -- common table

关于赠款的说明...

GRANT ALL PRIVILEGES ON Tenant_123.* TO tenant_123@'%' IDENTIFIED BY ...;
GRANT SELECT ON Common.* TO tenant_123@'%';

也就是说，将所有内容“授予”他自己的数据库可能是可以的。但是他展示了对Common数据的访问非常有限。

相反，如果您管理登录并且所有访问都通过 PHP API，那么您可能只有一个 mysql“用户”用于所有访问。在这种情况下，我上面关于GRANTs 的注释不相关。

不要让租户可以访问所有内容。您的整个系统将很快被黑客入侵并可能被破坏。

【讨论】：

如果 MySQL 必须管理多个数据库而不是一个数据库，那么它会增加额外的开销吗？此外，所有租户共享大约 15 个公用表，因此如果我们为每个租户提供单独的数据库，则总体文件数量也会增加。

【解决方案2】：

通常情况下，这与采用哪种方式与您基本上向客户推销的方式无关，或者在某些情况下由于数据类型而别无选择。

例如，您的应用程序是否有定义隔离用户生成数据的政策或类似政策？您的应用程序是否存储 HIPAA 或 PCI 类型数据？如果是这样，您甚至可能别无选择，并且如果客户期望这种隐私，由于创建分离的潜在开销，这通常会带来溢价。

如果不需要分离/隔离数据，那么从性能角度来看，向表中添加一个字段来指示哪个应用程序拥有数据是最理想的，您只需更新查询以基于此进行过滤。

【讨论】：

【解决方案3】：

使用 MySQL 或 MariaDB 我更喜欢为所有租户使用单个数据库，并通过为每个租户使用不同的数据库用户来限制对数据的访问，该用户只对其数据具有权限。

您可以使用一个tenant_id 列来存储拥有数据的租户的数据库用户名。添加新行时，我使用触发器自动填充此列。然后我使用 Views 来过滤tenant_id = current_database_user 的表。然后我限制租户数据库用户只能访问视图，而不是真正的表。

我能够在一个周末使用这种技术将大型单租户应用程序转换为多租户应用程序，因为我只需要修改数据库和我的数据库连接代码。

我已经写了一篇博文，全面描述了这种方法。 https://opensource.io/it/mysql-multi-tenant/

【讨论】：