资源隔离的效果

CPU 隔离效果

我们观察到，很多客户的跑批业务会安排在业务低峰期，如午夜或者凌晨，此时不用过于担心 OLAP 会影响到 OLTP 类业务，我们可以把集群绝大部分资源分配给 OLAP 类业务，给 OLTP 留下最小资源保证即可。在白天的业务高峰期，通过调整资源隔离方案，可以确保 OLTP 业务资源充足，同时按照预设资源满足基本的 AP 类查询。

在用户使用 OceanBase 的过程中，一般只需要预设两套资源管理计划，白天激活 DAYTIME 计划，夜间激活 NIGHT 计划，就可以实现满足基本的隔离需求的同时实现资源利用率的最大化。

例如我们可以用以下语法定义一个白天资源使用计划（resource plan),并且制定了此计划下 OLTP (interactive_group）和 OLAP (batch_group) 的资源百分比。80% 的资源用于 TP，剩下 20% 资源用于 AP。

DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN    => 'DAYTIME',
   COMMENT => 'More resources for OLTP applications');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'interactive_group',
   COMMENT          => 'OLTP group',
   MGMT_P1          => 80,
   UTILIZATION_LIMIT => 100);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'batch_group',
   COMMENT          => 'OLAP group',
   MGMT_P1          => 20,
   UTILIZATION_LIMIT => 20);

-- 定义好资源使用计划后，用以下方式激活：
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME';

按照类似的方式，可以定义夜晚的资源使用计划，并在业务低峰期激活它。

OceanBase 还提供了按登录用户对 SQL 分类的方法，客户可以创建一个新用户用于执行 AP 分析型 SQL，只要是该用户发起的 SQL，都会被判定为是 AP 负载，这样分类方式让资源隔离的粒度更细，也更简单有效。同时，OceanBase 会把执行时间超过 5s（时间可配置）的请求识别为当作大查询，大查询会被降低优先级。

我们刚刚提到可以建一个特殊用户专门来服务 AP 业务，那么我们先创建两个测试用户：AP 和 TP。我们把 AP 任务绑定到 AP_GROUP，TP 任务绑定到 TP_GROUP。假设这个业务白天的时候 TP 负载高，AP 集中在晚上。因此我们为白天和晚上设置两个不同的资源使用计划，白天的时候我们希望 80% 的资源用于 TP，剩下 20% 资源用于 AP，夜晚的时候希望 50% 的资源用于 TP，剩下 50% 资源用于 TP。

从下图测试结果可以看出来，切换为夜晚计划后，AP 的 CPU 资源占比变大后，AP 的 QPS 明显变高，TP 的 QPS 有一些降低。下图中 AP 和 TP QPS 发送变化的点就是切换资源使用计划的时间。