从Oracle PDB到OB多租户窥探国产数据库的核心特性之路

在过去曾经做产品经理的日子里，我在设计一个新功能或者新特性的时候，往往会既参考成熟的数据库产品，也会参考国产数据库的排头兵。主要基于两方面的考虑，一方面成熟产品的设计，往往要和现有的成熟体系兼容，让功能和原有的使用保持一致，另一方面国产数据库去观察它功能迭代的过程，去思考为什么会调整，这背后有什么逻辑，避免自己去踩坑。

经过数年的打磨，实际上很多国产数据库的功能已经日趋完善，这些都是需要建立在不断思考不断迭代的基础上，如果总寄希望于精密的计算来让你的产品逆天改命，那么命运一定会从其他地方找回场子。

接下来，我会从实际场景出发，来聊聊成熟的数据库产品、优秀的国产数据库以及我个人设计的心路历程，来聊聊国产数据库的特性设计。

多租户的强需求

多租户这个需求，其实早就有了，只是以前没有那么叫。无论在生产还是测试，我们都会遇到一些对资源需求更灵活的场景，而单独给一台服务器又觉得浪费。往往这时候，会在数据库服务器中创建不同的账号，在逻辑上隔离开。Oracle11g以及之前的版本，往往是不同的表空间不同的用户做好隔离。

但是这个方案却有一个很大的问题，虽然能够通过表空间文件来控制存储资源，没有办法精准控制每个用户的计算资源。比如A业务和B业务都在一台服务器，每年A业务线给了我1万块预算，B业务给了我3万块预算，那么理论上B业务应该享用75%的计算资源。然而使用一个实例的时候，是没法精准控制好的。

如果拆分成不同实例，实例A分配20%资源，实例B分配60%资源，也是可行的，但是在管理以及迁移上又麻烦很多。一旦这台服务器上要再增加一个C实例，也许是新实例也许是克隆一份A或者B实例，就得调整A和B两个实例的资源分配。

到了Oracle12c开始，PDB的出现，让这个事情变得简单很多。放到一个实例里，用参数固定每个PDB的资源上限，同时也实现了权限的隔离。PDB可插拔的特性，让数据库的迁移、升级和参数维护都方便了很多。同一个实例，用不同的服务名区别开来。

而PDB是完美的吗？显然也不是，比如出现性能问题的时候，排查问题的难度也会有提升，需要监控的项目也更多。但是从过往的Oracle使用习惯来说，却没有比它更合适的。

多租户需求的提炼

那么，我来总结一下，作为一个曾经的国产数据库产品经理，在当时设计多租户体系时，我的需求都有哪些：

• 第一个，细粒度的资源隔离。

这里的细粒度资源隔离，分为三个，一个是存一个算最后一个是权限。再展开说，租户分为超级租户和普通租户，超级租户只负责管理，普通租户提供给业务系统。每个租户的物理文件要隔离开，同时还能够保证资源上限；计算资源的CPU和内存上限，我需要圈定这些资源具体的数值，一旦租户到达这歌上限就再也无法继续获取更多；以及权限，不同租户之间的权限是必须严格隔离的，超级租户只能管理租户的用户，不能访问租户的数据。

• 第二个，更便捷的运维管理。

普通租户可以随时启停，而不会影响到超级租户或者其他普通租户的服务。普通租户可以通过物理手段或者逻辑手段，能够实现单独的备份、恢复、迁移与克隆，这样可以让用户更加便捷地对租户进行管理。租户内的存和算资源，都可以动态分配，而不影响当前实例的状态，即不需要重启就可以完成。这样能够实现对资源的灵活管理，对DBA的工作是一个很好的减负。

• 第三个，更好的可观测性。

在实现了前两个之后，在日常上生产的运维监控中，我希望能够更好地了解每个租户当前的资源使用率，高资源消耗SQL，历史用户和对象的资源使用情况，还有作为一个成熟的商业数据库，必备的功能——审计。在Oracle当中，这些东西都基本实现了，而作为国产数据库的产品经理，我也希望能够实现。

但是我也很清楚，这些实现也不是Oracle在一两天做完的，是以年为单位逐步实现完善，因此我能够接受研发同事先实现一个雏形，再不断迭代最终实现这些功能。

国产数据库的多租户

除了Oracle，其他常见的成熟数据库有原生多租户吗？MySQL和PG可以做到权限和物理文件隔离，但是计算资源没法隔离。这就和Oracle11g以及之前的版本没有本质区别。而在做国产数据库的多租户设计时，我参考最多的是Oceanbase。

在拆解Oceanbase的多租户功能之前，我先声明，我对Oceanbase的产品很认可，仅仅是从技术层面的拆解，并不存在踩和捧。

• 第一个需求，细粒度的资源隔离。

OB的多租户模式，分为系统租户、用户租户和Meta租户，其中Meta租户是系统自管理，实际DBA平时操作的还是系统租户与用户租户。而系统租户和Oracle的rootdb十分接近，用户租户和pdb也非常相似，实际上可以实现存和算的分离。在权限层面，确实也实现了不同租户之间的权限严格隔离。这里我要补充一句，Oracle并不是严格的权限隔离，存在着可以一个账号在多个pdb之间访问的情况。这一点上，OB反而做的更严格。

• 第二个需求，更便捷的运维管理。

OB有一点我很喜欢，就是创建了一个Unit的概念，每个Unit分配多少资源是固定的，在扩容缩容的时候，直接控制Unit就是一个很不错的方式。这一点上甚至超过了Oracle。而且也确实实现了资源的弹性扩缩容而不会停机。再就是租户的克隆、备份、恢复等等，都具备了实际生产可用的能力。后面我会用具体实操的文章，用来对比Oracle的RMAN。

• 第三个需求，匹配租户的可观测性。

这个Oracle实在做的太好了，无论是各种性能视图，还是AWR报告，还是自带的OEM监控，其实都遥遥领先。这些也容易理解，过去40年客户积累所带来的优势，不是国产数据库短短几年就能追平的。回到需求本身，通过OB的官方工具，能够观测到的资源使用情况已经基本覆盖了我的需求，而类似AWR的性能视图以及审计功能，已经尽可能去追Oracle的对应功能，考虑到没有在生产使用过，我在实操篇争取详细比对。

三个核心需求，以OB做为尺度，大部分已经做的很完善，在我设计多租户需求时，也参考了OB，然而在实际操作过程中，遇到的问题却远远多于我的预测。

多租户的从设计到实现

即便是参考了Oracle与OB的功能，也仅仅是停留在理论层面，想要在代码级别实现，研发和测试同事所付出的努力和遇到的困难，其实都远远超过了我的预测。

• 第一个需求，资源隔离。

因为存储引擎当初设计的差异，使得存的分离就变得有些棘手。怎么样让不同租户保存在不同的文件中，又怎么样严格限制租户存储上限，这两个难题就需要重构部分存储引擎的代码设计。牵一发而动全身，表面上是增加的功能，要牵连的过往功能更多。而且还要给后面的备份恢复、租户克隆等功能做准备，一直到我离职，存储隔离都没能实现。

而计算资源的隔离呢？同样很难，比如租户的内存限制，想要从代码级别去实现，当时负责内存管理的研发同事直接跟我说，短期内做不了。折中妥协的方案是，使用容器来跑计算节点，通过限制计算节点的CPU与内存上限，来控制计算资源的隔离。

反倒是权限隔离相对最容易，但是当时和同事设计的RBAC实在过于复杂，再加上各种环形授权，这部分跟研发同事足足讨论了一周。

• 第二个需求，便捷的运维管理。

在租户资源隔离实现不了的情况下，很多依赖条件就无法满足。比如前面提到的通过容器的方式来运行计算节点，扩容的时候我多启动一个pod，但是缩容就会出现各种问题，比如计算节点崩溃、容器可能要重启、会话断开等问题，这些都是使用容器带来的问题，如果不使用容器，这些可能都不是问题。

而基于租户的备份恢复迁移等等，同样需要底层存储引擎的支持，而且工作量远超研发同事们的预估。想法总是很美好，实际落到开发的时候，却总是一声叹息。

• 第三个需求，可观测性。

这一项同样很麻烦，比如我想查看历史SQL，在最早设计这部分的时候，就是把所有历史SQL都放到一张表，不同的租户通过过滤条件来看到各自的执行历史。那么问题就来了，租户越多，堆积的历史SQL越多，实际查询的性能就越差。必须把它们写入到不同表里单独管理，而这又涉及到了元数据层面的重新设计和代码重构。

而真正深入到元数据层，才发现更多的难点还在后面，有些东西深不见底，越挖越深。可观测性这个大坑，需要以年为单位才能填上。

不算总结的总结

最后来对三个产品的多租户能力做一个总结：

以多租户这一个场景，一下子写出去2000多字。通过这些死去的记忆，不断在告诉我一件事情，数据库功能和特性的开发，远远比我们想象的要难得多得多。而国产数据库想要去开发一个核心的特性，显然不是短期内就能做出来的，不要总是妄想着三年追平Oracle，五年江湖第一。

作为一个自认为失败的数据库产品经理，我也想给同行们斗胆提一些建议：

• 第一，复杂的功能分期完成。比如多租户这个复杂的功能，和研发把功能的依赖关系搞清楚，根据每个迭代时间评估，做好多期完成的准备。也许前两三期，都拿不出能用的东西给用户，但是这不重要，打好基础，等待破笋。
• 第二，做好代码的顶层设计。之所以之前我所在的项目每次开发新功能都寸步难行，根本原因在于顶层的代码设计没有做。大家都是自下而上开发，等到各自的代码进入集成调试的时候，各种问题各种各种冲突就都出来了。
• 第三，不要闭门造车。数据库功能存在着最大公约数，这是行业共识，也是大家探索出来的最佳实践。每个人固然都有自己的想法，但是没有谁有这个能力可以凌驾于全行业之上，最终还是要脚踏实地一步一脚印，多看看多思考。
• 第四，吃下去的最重要消化转换为自己的，我们不是星之卡比吃进去秒变身，需要将行业内成熟顶尖的产品与中国国产数据的需求以及现状结合起来，立足于现实让自己的东西真正可行可用，而不是空中楼阁。

在此，感谢各位国产数据库同行抽时间看完这3000多字，让我们实操篇再见。

本文为墨天轮社区特约作者 多明戈教你玩狼人杀 独家供稿，内容原创，仅代表作者个人观点，欢迎大家交流、讨论。本文现已收录至合辑《墨天轮专家邀稿合辑：论道数据库 解读新发展》，如需转载请联系作者或墨天轮官方。