服务客户的过程中，OceanBase为何执着磁盘IO隔离？

近几年，在服务客户的道路上，OceanBase的步伐越来越稳健。然而，在取得了具备CPU、内存等资源的隔离能力一系列成就的基础上，OceanBase仍然不满足于现状，转而将注意力聚焦在强化了磁盘IO的隔离能力上。

一段时间以来，OceanBase通过多种手段在“磁盘IO的隔离”这个层面持续深耕，面对成果，仍然有不少用户对此表示疑惑。执着于磁盘IO隔离的OceanBase，出发点到底是什么？又给客户带来了哪些益处？对此，我们展开全方位的解读。

OceanBase磁盘IO隔离的必要性

资源隔离是一种能力，基于它可以生长出HTAP、多租户、PayasYouGo等许多有意思的场景，而磁盘IO隔离又是资源隔离至关重要的组成部分，实现磁盘IO隔离可以带给用户更完整的资源管控能力。

较之于多租户运用不同机器的物理隔离方式，磁盘IO隔离可以打破其固有的局限，尤其是降低成本。具体来说，如果A、B两个租户分别处理国际与国内业务，由于时差问题，这两个租户的负载基本互补，这两个租户固然可以分别独占机器，但这样会浪费一半的资源。

而对于磁盘IO资源而言，数据紧耦合的负载并不容易拆分机器。比如数据库中的备份、迁移、重整等操作，都强依赖于数据的大量读写。如果没有磁盘IO隔离，这些任务很可能影响业务的吞吐量和响应时间。

此外，基于内存空间等资源属于刚性资源这一特质，存在着“一块内存被A占用，就不能再分配给B使用”的天然短板。作为柔性资源磁盘IO就能轻松化解这一难题，它不仅能将A、B负载同时读写磁盘，而且还允许负载之间可以互相挤占，就像一条小河同时灌溉A、B两块农田，当A农田的水流调小时，B农田水流可以自然调大。

OceanBase磁盘IO隔离的可行性

基于用户的实际需求对应的reservation,limitation,proportion（保留、限制、比例）三种隔离语义，OceanBase磁盘IO隔离展开了具体举措。

通过在unitconfig中指定一个租户的MIN_IOPS,MAX_IOPS，以及IOPS_WEIGHT，契合上述三种不同的隔离需求。而对租户内具体负载的磁盘IO隔离的配置，OceanBase考虑到兼容用户已有的使用习惯，选择了扩展Oracle的ResourceManager包。其具体操作流程如下。

首先，定义一个资源管理计划htap_plan和两个资源消费组tp_group和ap_group；其次，将tp_group和ap_group绑定到htap_plan并分配资源，并且为tp_group分配更多资源，为ap_group分配更少资源，其中MIN_IOPS，MAX_IOPS，WEIGHT_IOPS均为占用租户unit的百分比；最后，设置负载到资源消费组的映射规则，这里举例是按照用户名映射，例如trade用户的负载全部使用tp_group的资源。

如此一来，不仅可以实现资源消费组的映射规则支持函数名和列名，还能通过函数名的映射，让后台任务也通过ResourceManager控制资源用量，通过列名的映射，甚至可以将资源隔离粒度控制到SQL语句级别。

OceanBase磁盘IO隔离的实用性

通过验证磁盘IO隔离能力的仿真实验发现，设置的4个租户，每个租户启动64个线程发送IO请求，IO请求固定为16KB随机读，租户1、2、4的负载持续20秒，租户3的负载从第10秒开始，持续10秒。实验磁盘IOPS上限大概在6w，如果不加限制，任意一个租户单独都可以打满磁盘。

另外在验证租户内负载的隔离实验中，对租户2内设置了4个类别的负载，从各负载的配置和实验结果来看，B负载稳定在近2000IOPS，哪怕其权重为0，因为B负载通过MIN_PERCENT预留了租户MIN_IOPS97%的资源；A负载稳定在1000IOPS左右，因为其MAX_PERCENT为1，最多只能使用租户MAX_IOPS1%的资源；C、D负载的IOPS比例始终保持大约2:1，因为其权重为50:25。

由此可见，OceanBase在支持租户间磁盘IO隔离的同时，还支持租户内负载间的磁盘IO隔离，且都满足reservation，limitation，proportion三种隔离语义。

此外，还有实验进一步证明OceanBase支持实时调整配置。对准备好的大表使用并行查询做全表扫描，在扫描的同时，管理员去不断修改租户的MAX_IOPS，可以看到，操作系统监控中IOPS将随着管理员的修改不断变化。

值得一提的是，在OceanBase4.x的资源隔离能力切实帮助用户灵活控制不同负载的资源分配的基础上，OceanBase仍然没有停下持续探索的步伐，聚焦用户关注的更多问题，力争给大家呈现更好的资源隔离能力和使用体验。这对于所有用户来说，又是值得期待的未来。