通过 Catalog 实现 MariaDB Server 中的多租户

假设您是一家云服务提供商，拥有众多客户，每个客户都有许多 MariaDB Server 用户和数据库。如果几个这样的客户可以共享一个 MariaDB Server 实例呢？这就是我们所说的 catalog 特性，如果实现，它有可能在许多高端用例中显著节省资源（从而降低成本！）。

这个想法是如何诞生的

在三月法兰克福附近的 CloudFest 2023 上，我们与一些 MariaDB Server 的重度用户进行了深入交流——他们最恰当的描述是云服务提供商（CSP）。在 MariaDB Server 的语境下，他们出售运行中的 MariaDB Server 实例。结果发现，许多用户——特别是运行 WordPress 博客的用户——对 MariaDB 的使用非常轻量，这不禁让人质疑他们是否一开始就需要拥有自己的服务器实例。他们难道不能共享吗？这样就不受限于每个客户只能拥有一个数据库模式（schema）的限制了。

共享 MariaDB Server 实例并非易事

当然，一个 MariaDB Server 实例可以有许多用户，并且用户可以对该实例处理的各种数据库（也称为模式）拥有不同的权限。这很简单。但是，如果您考虑到 CSP 客户的概念，您可能希望将该客户的所有用户的使用和账单捆绑在一起。并且客户需要一个root 用户，负责管理该客户的所有用户权限。

这已经很复杂了。没有 catalogs，用户和数据库不会被分组在一个 MariaDB Server 实例中。设置访问权限是出了名的困难且容易出错；客户 A 的用户如果拥有访问所有数据库的权限，就会看到客户 B 的所有数据库。这不太好。违背了隔离客户的目的。

引入 Catalogs：捆绑用户和数据库

Catalogs 的想法是引入一个在 MariaDB Server 实例和单个数据库（包括包含用户的系统数据库）之间的新抽象层。这个新的 catalog 概念在实践中将与 CSP 客户有一对一的关系。

假设 mercedes 和 bmw 都是 IONOS（一个随机选择的 CSP，碰巧是 MariaDB Foundation 的赞助商，所以我突然想到了它）的客户。那么他们都可以拥有一个名为 cars 的数据库。连接时，Mercedes 会在连接数据库的 API 调用中提供 mercedes，而 BMW 会提供 bmw。

此外，系统变量通常是 catalog 特定的。因此，各个客户可以单独配置和监控。

同样酷的是，如果 CSP 使用 catalogs，客户端本地使用的数据库模式可以一对一地映射到云端的 catalog。无需基于“每个客户一个模式”这样人为的限制来更改模式，因为一个 catalog 可以有许多数据库（这对于 MariaDB Server 来说与模式同义）。

为什么这能节省资源？

MariaDB Server 在内存设置和其他参数方面以其高度可配置性而自豪。尽管如此，仍然存在 InnoDB Buffer Pool 和其他内存区域，它们必须存在于 MariaDB Server 实例级别。如果每个 CSP 客户都获得自己的 MariaDB Server 实例，那么这些内存在调用之间会闲置，并且设置它们也需要资源。

节省这些内存区域正是 MariaDB Server 的大型用户每年可能节省数百万美元成本的原因，而且无论如何都要远高于该功能的开发成本。

“多租户”指的是什么？

第一次听到“多租户”（multi-tenant）这个词时，我得查字典。为了让我的非英语母语同胞们不必再去翻书架或 Google Translate，让我告诉您，“tenant”（租户）是“land-lord”（房东）的反义词。租户从房东那里租一套公寓。因此，“多租户”在云语境下指的是用户以某种方式共享资源，无论是计算机、虚拟机，还是（在我们的例子中）数据库服务器实例。

有缺点吗？有，但很小

一旦实现，catalog 特性几乎没有缺点。一个缺点是它是一个需要实现的新功能，需要在 cPanel、Plesk 以及 CSP 客户访问 MariaDB Server 所使用的任何周边软件中实现。

另一个缺点是不同的客户仍然可能略微相互干扰。在不太可能发生的情况下，如果 Mercedes 的 MariaDB Server 实例崩溃了，那么对于 BMW 来说它也会崩溃，因为它们共享同一个实例。这很明显。但是服务器崩溃本身也不是那么常见。

但我听到有人使用“catalog”表示不同的意思？

我还有另一个需要警告的地方，那就是“catalog”这个词不像“table”或“view”那样是行业标准术语。在撰写这篇博客文章的过程中，我搜索了“catalogs”，发现不同的数据库管理系统使用这个术语表示不同的目的。

那我们为什么选择了“catalog”呢？因为我们没有找到其他更常用的词。而且因为在协议中已经将“catalog”这个词用于此目的，只是尚未在服务器中实现。最后，我们对“catalog”的使用不一定与 Oracle Database 或 Postgres 的用法不同。

无论如何，这篇博客文章的读者都知道我们所说的 catalogs 是什么意思。我相信这是一个有用的功能。

行动号召：早期采用者

如果您同意这是一个有用的功能，并希望参与规范、开发和测试阶段，请告诉我们。Catalogs 是一个需要相当多编码的功能，MariaDB Foundation 缺乏这方面的开发资源。因此，该功能的开发取决于能否找到资金或“功能赞助商”（如果您愿意这样称呼）。为了使这项功能满足主要用户的需求，我们希望在规范、开发和测试方面与早期采用者更紧密地合作。

但请放心。显然，catalog 将在适当的时候成为 MariaDB Server 的一个正常功能。我们看到的兴趣越多，它开发得就越快。