共计 7780 个字符，预计需要花费 20 分钟才能阅读完成。
此前，通过《向量化引擎对 HTAP 的价值与技术思考》一文，咱们分享了 OceanBase 怎么对待向量化引擎技术，并介绍了用它解决简单查问场景的技术思路。
HTAP 的本意是把 OLTP（事务处理）和 OLAP（剖析解决）放在一个零碎上更好地运行，帮忙客户发展实时业务决策，升高经营老本并晋升翻新效率。因为 OLTP、OLAP 应用资源（CPU、内存、IO 等）的形式不同，同时运行时容易产生资源烦扰。如何将二者的相互影响降到最小，成为实现 HTAP 的要害，也是本篇文章中资源隔离技术要解决的问题。
对于作者
席华锋
OceanBase 技术专家，11 年来继续专一数据库的高可用和扩展性，曾负责 Paxos 协定在 OceanBase 的落地，是 OceanBase TPC- C 攻坚我的项目组成员。目前在 OceanBase 零碎组，负责打造 HTAP 的基础设施，包含如何解决 AP 和 TP 的资源隔离问题。
咱们认为真正的 HTAP 须要齐备的资源隔离，数据库须要提供逻辑隔离能力，与物理资源隔离造成互补，帮忙用户依据理论业务场景进行调整。 须要极致隔离的外围业务采纳物理资源隔离，对老本敏感的长尾业务采纳逻辑资源隔离。 本篇文章将分享 OceanBase 对资源隔离技术的思考，论述为什么资源隔离技术是实现 HTAP 的必要前提，以及咱们如何应答资源隔离的施行挑战等：
- HTAP 为什么须要资源隔离；
- 如何实现适宜 HTAP 的资源隔离；
- OceanBase 资源隔离的实现成果。
HTAP 为什么须要资源隔离？
资源隔离是 HTAP 的立足基本
为了阐明资源隔离的重要性，咱们能够把数据库与操作系统进行比拟：这两者的共同点是复杂性，而复杂性来源于两方面：一是性能的凋谢，二是对性价比的极致谋求。性能的凋谢意味着负载不可控，如一个用户过程能够做任何事，一条 SQL 也能够做任何事；谋求性价比则是因为根底软件用户量大，优化节俭每一点资源都有重要意义。 而谋求性价比有很多办法，其中最间接的就是资源隔离技术。
通过数十年的倒退，以后的操作系统都已具备反对多用户，反对 Docker（虚拟化利用容器）的能力，基于 Docker 的 Kubernetes 曾经成为业务部署的事实标准。而数据库也有多租户和混合负载的场景需要，比方很多业务把历史库和在线库离开，在历史库上执行剖析，不仅减少了运维复杂性，也导致 AP 的实时性不够，无奈在无限的硬件资源下实现 TP 和 AP 的动态平衡，将来随着数据库的部署实例持续减少，解决这一问题的价值收益会越来越显著。
资源隔离的需要实质来自于负载的差别分组，只有能分组，天然就产生了某种隔离的需要。 负载的分组：如备份工作和前台 SQL 工作，两者存在时效性的差别，OLTP 和 OLAP 对资源的应用形式不同，也会产生分组。只有一个软件系统要对服务的对象作区别对待，那就天然会产生分组和 QoS（Quality of Service，服务质量）的概念，也就有了资源隔离的需要。
资源隔离对数据库稳固运行至关重要。这有两种典型状况： 一是为数据库外部重要的工作预留资源，避免出现用户负载高导致数据库本身垮掉的状况；另一种是用户原来就有 QoS 要求不同的业务混在一个库里， 比方实时性高的 OLTP 业务，加上大量的重要性低一些的后台任务，如果用户违心把这些信息通知 DB，数据库就能够更稳固地运行。
第二种状况的典型例子就是 OLAP 和 OLTP 两种负载的隔离。传统数据库为了防止 OLTP 和 OLAP 业务间产生烦扰，须要配置较多硬件资源调配给不同业务，这样就会呈现资源利用率低的景象。咱们能够通过引入 consolidation（数据整合）的概念来解决这一问题，consolidation 通过把原有的多套数据库聚合到一个物理库，能够在缩小硬件老本的同时升高运维复杂性。
从 OLTP 和 OLAP 两个库进化到 HTAP 一个库，这一进化过程就能够了解为 consolidation。咱们晓得操作系统早已实现多用户和 Docker 的能力，数据库是否也会随着技术倒退呈现共享物力资源的需要呢？咱们认为，随着技术提高和数据库部署规模持续变大，逻辑资源隔离的利用场景会越来越多。同时，事实中本来就有不少用户在一个库中既服务 OLTP 负载，也执行一些简略的 OLAP，只是受限于 OLAP 和资源隔离的的能力，限度较多。
比方一个电商的老板想晓得当天卖得最好的商品是什么。那就须要在在线库上执行剖析，但支流数据库短少资源隔离能力，剖析类 SQL 可能影响在线交易，为了保障在线交易的稳定性，就须要对数据库扩容，用更多的物理资源换业务稳定性，即便这样，也须要对剖析类 SQL 做严格 review，避免这些 SQL 无限度占用资源。
物理 & 逻辑隔离，哪个是更优抉择？
资源隔离并不是一个新概念，传统形式下不共享物理资源，能够了解为物理资源隔离计划。这种计划下不同租户或同一租户内 OLAP 和 OLTP 应用不同的正本，行存正本服务 OLTP，列存正本服务 OLAP，两种业务不共享物理资源。如果不思考老本，物理资源隔离无疑是更好的抉择。
但事实中，大部分客户都会思考硬件老本及其资源利用率。一方面，数据库硬件的购买和保护老本昂扬，而所有硬件都须要定期换新；另一方面，数据库硬件在进行单项业务解决时，均匀占用率程度较低。如果不能充分利用硬件资源，无疑会造成微小的资源节约。
而要充分利用硬件资源，不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离计划，天然怀才不遇。 同时咱们认为，物理资源隔离和逻辑资源隔离不是二选一，而是互为补充的关系。但考量到资源共享可能呈现的烦扰问题，一些人认为资源共享会导致 QoS 无奈保障，因而对用户价值不大；另一些人也会关注完满的资源隔离是否能实现，如果实现计划过于简单是否会得失相当等问题。
面对上述问题，咱们认为一方面要放弃完美主义，意识到根底的资源隔离能力对客户的显著价值；另一方面要用倒退的眼光看问题，理解到逻辑资源隔离技术在继续提高。
因而，适宜 HTAP 的资源隔离并不是物理资源隔离或逻辑资源隔离中二选一，现实的资源隔离计划是在齐全物理隔离和齐全共享中找到平衡点。 根底软件应该给用户更多自在，帮忙用户在面对各类场景下都能够做出最合适的抉择，数据库产品有必要同时提供物理隔离、逻辑隔离各级别的资源隔离能力。
如何实现适宜 HTAP 的资源隔离？
咱们在施行资源隔离前，要先解决两个问题：
定义资源组，以及资源组的 QoS，对数据库来说租户就是最常见的资源组，另外 AP 和 TP 也能够是两个不同的资源组；
按定义好的 QoS 制订施行资源隔离的策略。
咱们先看 DBA（数据库管理员）的管制接口，而后再剖析要对哪些资源做隔离（个别抉择对业务影响最大的资源），最初会以 CPU 工夫、IOPS 和网络带宽为例讲述 OceanBase 的隔离计划。
定义资源组，做好 OLTP 和 OLAP 的资源布局
OceanBase 的指标是实现在不同租户间的资源隔离，以及租户内 OLTP 和 OLAP 业务的资源隔离。
怎么形容租户的资源要求？OceanBase 外部是通过 unit config 实现的，比方创立一个租户之前要创立 resource pool（资源池）、resource pool 的规格形容里就指定了各种资源的限度。对这个概念不太理解的能够参考 OceanBase 的 DBA 手册集群和多租户治理这一章。
create resource unit box1 max_cpu 4, max_memory 21474836480, max_iops 128, max_disk_size '5G', max_session_num 64, min_cpu=4, min_memory=21474836480, min_iops=128;
怎么形容租户内 OLTP 和 OLAP 须要的资源规格？OceanBase 参考了 Oracle 经典的 Resource Manager 零碎包提供的治理接口。咱们察看到，很多客户的跑批业务会安顿在业务低峰期，如午夜或者凌晨，此时不必过于放心 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 分类的办法，客户能够创立一个新用户用于执行 剖析 SQL，只有是该用户发动的 SQL，都会被断定为是 AP 负载，这样分类简略无效。同时，OceanBase 会把执行工夫超过 5s 的申请辨认为当作大查问，大查问会被升高优先级。
min, max, weight，满足 QoS 基本诉求的三重定义
QoS（Quality of Service，服务质量）作为一种平安机制，能够在资源过载时保障要害过程的安稳运行。以下咱们通过权重调配、资源下限和保留资源来形容 QoS。
在不同的时间段，业务的流量会有稳定，所以 QoS 形容须要有肯定的弹性，如果像私有云上的 ECS 一样指定一个固定的 CPU 核数和 IO 带宽，在业务顶峰的时候容易呈现数据库容量不够而导致的故障。
咱们假如这样一个场景：总带宽是 100M，由租户 A 和租户 B 独特应用，基于资源的闲时共享和忙时隔离准则，咱们尝试让租户 A 和租户 B 互不烦扰地独特应用总带宽。
如果两者的重要水平不同，怎么保障重要过程的优先运行？此时咱们能够每个租户的重要水平调配应用资源的比例，如给租户 A 和租户 B 调配 1:3 的权重比，当这两个租户都须要 CPU 时，A 将失去 1 份 CPU 工夫，B 将失去 3 份 CPU 工夫。这一操作咱们称为权重调配，或 <weight>。
有时候物理资源较为富余，低权重租户可能会占用大量并不需要的资源，如何限度它的应用呢？咱们能够在权重调配的根底上给不同的租户定义资源下限 <max>，如租户 A 依照权重比 1/4 时，能应用的带宽最多为 25M，当给它设置资源下限参数 20M 后，它最多能应用 20M 的带宽。
租户数量增减会引发权重配比扭转，如何直观判断各租户最低资源需要的满足状况？此时咱们能够给各租户设置保留资源 <min>，这样不仅能够保障所有租户基本功能的运行，也能直观清晰地形容 QoS。
咱们心愿把更完满的资源隔离，做进 OceanBase 数据库
资源依照应用状况有刚性和弹性的区别，资源隔离的对象通常是弹性资源。刚性资源是保障程序实现性能必须的资源，一旦被占用，短时间内也难以开释。刚性资源的典型是磁盘空间和内存空间，连接数等，这类资源做好动态布局后，每个组能够应用的资源数量就会固定下来。弹性资源是指和程序性能无关，然而和性能无关的资源，比方 IOPS、CPU 工夫、网络带宽等，这类资源个别能够抢占或被迅速开释，因而资源调度策略能够染指，实现闲时共享，忙时隔离。咱们须要关注的正是弹性资源的共享机制。
刚性资源比拟重要的是内存和磁盘空间，弹性资源比拟重要的是 CPU 工夫，IOPS 和网络带宽，OceanBase 会优先把这些资源的隔离做好。
CPU 隔离
OceanBase 目前已实现 CPU 工夫的隔离，将来会退出 CPU cache 的隔离。CPU 隔离有一个特点，那就是只有在内核态能力做得比拟实时，因为一个资源要能调度，前提是要能切分成很多小片，网络 IO 人造就是一个一个的 packet，磁盘 IO 也相似。CPU 工夫被操作系统切分成了很多片，然而这个工夫片对用户态是通明的，用户态无奈染指工夫片调度。用户态要调度，那就须要在代码中插入很多检查点，通过检查点把用户线程的 CPU 工夫切分成很多段，同时在检查点执行调度策略。用户态插入检查点切分成果无奈保障，如何在一个动态库函数里插入检查点呢？
OceanBase 抉择了内核态解决方案，即 cgroup 的 cpu controller，cgroup 目前能反对 <max,weight>，但不反对 min。这对咱们来说不形成问题，因为 CPU 总工夫不会稳定，依照 weight 调配就能够保障每个组的保留工夫片的要求。
CPU 隔离不仅能够隔离用户负载，也能够隔离零碎外部的不同工作。比方对 OBServer 来说，多正本的 leader 选举是一个高优先级工作，咱们不心愿用户 SQL 把 CPU 打满最初影响到选举。咱们在 cgroup 的顶层把选举和用户 SQL 分到两个目录，在用户 SQL 的目录进一步分目录，对应租户和租户内的用户。
IOPS 隔离
对于 SSD 磁盘，带宽能够通过 IOPS 来等价形容（bandwidth = size * iops）。其次不同大小的 IO，咱们依据教训公式能够归一化，咱们设定一次 IO 的规范大小是 16K，那么一次 2M 的 IO 就能够等价为屡次 16K 的 IO。IOPS 隔离要辨别设施，然而把设施裸露进去会让配置比较复杂，所以大部分状况下能够让多个设施共用一套配置。
OceanBase 从 VMware 用于隔离虚拟机 IO 的一篇论文《mClock: Handling Throughput Variability for Hypervisor IO Scheduling》中取得启发。
在私有云上部署的时候，咱们发现云盘的 IO 能力是会有稳定的，OceanBase 能够疾速适应云盘 IO 能力的降落，保障最重要的 TP 业务不受损。同时 OceanBase 的 IO 隔离会和数据库的块缓存一起联动，OceanBase 不仅会限度 AP 的 IO 带宽，还会限度 AP 的缓存应用，这样就能防止 AP 净化块缓存，最终保障 TP 的低提早。
网络带宽隔离
咱们能够把 OBServer 之间的 RPC 分为机房内通信和机房间通信：前者次要是 SQL 分布式执行以及两阶段提交引起的，后者次要是为了高可用而做的日志复制和数据备份。不同于机房内通信，对于机房间通信的来说，一个机器到不同的机房的提早和可用带宽都是不一样的，通常机房间带宽是共享资源，所以带宽的调配和限度需全局思考才有意义。关键问题就在于全局的范畴是什么？比方有多套 OceanBase 集群，是否要协同思考；就算只有一套 OceanBase 集群，如果呈现网络分区怎么办？咱们怎么能力确保拿到全局视图？
OceanBase 从 3.2 版本开始反对 region 级别的带宽管制，接下来，咱们的思路是多套 OceanBase 集群之间不做协调，须要 DBA 动态划分资源，也就是要给每个集群设置机房和机房间的可用带宽，OceanBase 在集群外部把带宽动静分到每个 OBServer，每个 OBServer 内进一步把带宽按优先级分给不同的组。
对大部分业务来说，机房内的网络带宽调配更为要害，带宽的隔离和 IOPS 隔离是十分像的。不过因为通信目标端泛滥，个别不区别通信目标端，算法施行的时候把网卡当作一个 IO 设施，而不是把通信目标端当作一个设施。
网络带宽隔离问题能够合成为两局部：首先要对流量分组，或者说打标签；其次要按设定的要求对打好标签的流量做隔离。其中第一步只能由应用逻辑提供，第二步能够在应用层解决，或者在内核层面解决。因为 linux 下 tc 提供了十分丰盛的限速和优先级策略，所以 OceanBase 抉择应用层打标，内核态限速的计划。复用内核的能力，同时也是在复用内核的生态，用户不再须要学习一套新的限速机制。
OceanBase 资源隔离的实现成果
OceanBase 目前实现了内存隔离、磁盘空间隔离、CPU 隔离以及 IOPS 隔离，将来还将反对网络带宽隔离，下文咱们会以 CPU 隔离为例，对 OceanBase 资源隔离实现成果进行测试。
在介绍定义资源组的办法时，咱们提到能够建一个非凡用户专门来服务 AP。在本次试验中，先创立两个测试用户：AP@ORACLE 和 TP@ORACLE。咱们把 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 发送变动的点就是切换资源应用打算的工夫。
看起来 TP 的 QPS 升高比拟少，和 AP 的 QPS 变动比起来不显著。这里要留神，按现实状况来算，TP 的 QPS 变动原本就要比 AP 的变动小，因为 AP 是从 0.3 到 0.5，减少了 66.7%, TP 从 0.7 到 0.5，降了 28.5%，而后理论算一下，TP 降落了 24.7%(19000 到 14300)，和现实值的差距不算特地大。
CPU 隔离是否起到现实作用，和负载类型有很大关系，如果网络成为瓶颈，那就必须要加上网络带宽隔离能力起效。 这个试验目标也不是为了表明 CPU 隔离就很牛，能解决很多问题，然而它表明了对 CPU bound 的负载，简略的 CPU 隔离成果还不错，比方目前咱们还没有思考 CPU cache 的隔离。隔离能力的建设是个渐进的过程，单纯的 CPU 隔离对 TP 加简略 AP，或者 TP 和 TP 之间的隔离就能间接起效；适当的 IOPS 隔离和网络带宽隔离加上之后，适应范畴就足够广了。
写在最初
本文介绍了 OceanBase 对资源隔离技术的思考和实现计划。HTAP 数据库要实现不同租户间、以及同一租户内 OLTP 和 OLAP 业务的硬件资源共享，对资源隔离提出了很高的要求，咱们认为更适宜 HTAP 数据库的资源隔离计划是物理隔离、逻辑隔离两者互补的计划。展望未来，OceanBase 的资源隔离技术也会一直演进和欠缺，更好地满足用户对资源隔离的需要。