亚马逊云科技助力 OceanBase 打造云上 DBaaS 形态的数据库产品

<a name="Uh3QT"></a> # 背景 &emsp;&emsp;SaaS（Software-as-a-service，软件即服务）是基于互联网提供软件服务的软件应用模式。近些年大量的 SaaS 服务商利用三方独立软件为客户提供软件服务的模式，开始逐步出现从线下机房朝着公有云进行转变的趋势。SaaS 在数据库领域就是 DBaaS（Database as a service），数据库即服务。是指客户直接通过 SaaS 服务模式来采购方式采购数据库云服务。数据库云服务商拥有所有的资源，包括底层的 IAAS 和数据库软件，客户对于底层资源不感知，由数据库云服务商负责运维整个数据库产品。 <br />&emsp;&emsp;OceanBase 入驻到 AWS 的云市场后，OceanBase 提供数据库软件以及运维服务，AWS Marketplace 为 OceanBase 公有云服务提供了 IAAS 资源（网络/存储/计算）和计费能力。OceanBase 和 AWS 共同为用户提供了一款基于 OceanBase 数据库的 DBaaS 产品。<br />  <a name="EYWYe"></a> # OceanBase SaaS 资源整合解决方案 &emsp;&emsp;云上的 SaaS 服务商，往往提供的是多租户的服务。多个业务租户的数据库如果在一个单机数据库中做逻辑名字空间隔离，大小租户之间互相影响。如果每个业务租户使用一个独立的数据库，成本高，几十到上百套分散数据库环境，运维工作复杂，同时扩展性受限。使用 OceanBase 数据库内原生多租户，能更好地平衡隔离性和成本，而且大小租户可以独立扩缩容。 <a name="PixVG"></a> ## 行业现状与挑战 - 实例碎片化：企业内部多个不同业务应用，或 SaaS 企业面向不同客户的资源隔离需求，会导致需要部署大量的数据库实例，造成严重的碎片化，在某个关键业务或关键客户需求激增时，难以灵活的弹性扩展，性能和可用性难以保证。 - 资源浪费：由于数据库资源的碎片化部署，单个实例为了保证一定的性能弹性空间，往往会多划出一部分容量作为短时间内请求增长的预备资源。这种资源预留在整体业务视角来看实际上造成了巨大的资源浪费，抬高了企业资源成本。 - 管理复杂：大量的数据库实例同时带来的还有管理效率的降低， 数据库相关团队难以对成百甚至上千的实例进行精细化管理， 出现故障、抖动等事件时恢复时效差，对整体资源水位的把控难以全局掌控，抬高了企业的人力管理成本。 <a name="sVNwL"></a> ## 解决方案 &emsp;&emsp;基于 OceanBase 的多租户架构，帮助企业将多个不同业务的数据库实例集中整合，提升资源利用率，同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。<br />&emsp;&emsp;既适用于中大型企业内部大量不同业务链路的资源池化，也适用于各个行业 SaaS 服务商，为不同客户提供不同规格的实例，保证资源隔离性的同时降低成本。<br />  <a name="R7EIX"></a> ## 方案优势 - 多租户池化： OceanBase 集群原生实现了多租户下的资源隔离和虚拟化，一个集群中可以部署上百个数据库实例，每个实例数据和资源隔离，计算资源原地升配秒级生效。 - 多维度弹性：基于 OceanBase 的多节点分布式架构，用户可以实现单机原地升配、多机弹性扩展，多机流量均衡多个维度的扩容操作，并且扩容对上层应用透明。对于涉及数据迁移的扩展无需人工值守，OceanBase 自动完成迁移以及多维度数据校验。 - 统一管理：将多个零散的实例统一部署在 OceanBase 后，运维管理的复杂度大大降低，DBA 从之前管理几百个分散实例，到目前管理几个 OceanBase 集群，负载、告警、调优全部统一至集群级别，常规故障能够自动恢复，大幅提升业务支撑效率和应急响应能力。 - 降本增效：不但通过多租户实现计算资源池化，提高总体利用率，OceanBase 的高级压缩能力使得存储成本仅为原来传统数据库的 1/3。经过大量的客户反馈和广泛案例实践统计，OceanBase 的资源整合方案能够帮助中型及以上企业降低 TCO 约 30%-50%。 <a name="Pk6Zw"></a> # OceanBase 多租户特性介绍 <a name="zQQQN"></a> ## 多租户概述 &emsp;&emsp;在 OceanBase 数据库中，租户是一个逻辑概念，是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的 “实例” 概念，例如一个 OceanBase MySQL 模式的租户，对应一个 MySQL 的示例，一个 Oracle 模式的租户，就对应一个 Oracle 的示例。并且租户之间的数据是完全隔离的。<br />&emsp;&emsp;在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。在资源使用方面，OceanBase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。<br />&emsp;&emsp;OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性，配合 OceanBase 数据库强大的可扩展性，能够提供安全、灵活的 DBaaS 服务。<br />&emsp;&emsp;OceanBase 数据库采用了单集群多租户设计，天然支持云数据库架构，支持公有云、私有云、混合云等多种部署形式。<br />  <a name="pk08H"></a> ## 租户和资源池 &emsp;&emsp;租户是集群之上的递进概念，OceanBase 数据库采用了多租户架构。多租户架构适用于资源整合（Resource Consolidation）、SaaS 服务等场景，同时也降低了运维复杂度。<br />&emsp;&emsp;集群偏向于部署层面的物理概念，是 Zone 和节点的集合，Zone 和节点具有部署地域（称为 Region）等属性；而租户则偏向于资源层面的逻辑概念，是在物理节点上划分的资源单元，可以指定其资源规格，包括 CPU、内存、日志盘空间、IOPS 等。<br />&emsp;&emsp;租户类似于传统数据库的数据库实例，租户通过资源池与资源关联，从而独占一定的资源配额，可以动态调整资源配额。在租户下可以创建 Database、表、用户等数据库对象。<br />&emsp;&emsp;资源规格资源规格定义了常见物理资源项的大小，包括 CPU、内存、磁盘空间、IOPS 等。创建资源池时指定其资源规格，从而根据定义创建资源单元。<br />&emsp;&emsp;资源单元（Unit）Unit 是租户管理中非常重要的概念。OceanBase 按照 Unit 来管理物理资源，是 CPU、内存、存储空间、IOPS 等物理资源的集合。Unit 也是资源调度的基本单位，其具有节点、Zone、Region 等位置属性，节点是服务器的抽象，Zone 是机房的抽象，Region 是地域的抽象，通过调整 Unit 的位置属性从而调整租户的部署方式。<br />&emsp;&emsp;资源池每个 Unit 都归属于一个资源池，每个资源池由若干个 Unit 组成，资源池是资源分配的基本单位，同一个资源池内的各个 Unit 具有相同的资源规格，即该资源池内 Unit 的物理资源大小都相同。如下图，展示了一个由 6 个 Unit 组成的资源池 a_pool：<br />  <br />&emsp;&emsp;通过 Unit 的概念，我们将 OceanBase 数据库的物理概念和逻辑概念进行了关联。每个租户有若干 Unit ，分布于若干 Zone 的若干节点上。而每个节点上分布有若干个 Unit ，这些 Unit 归属于不同租户。概括的讲：集群由节点组成，节点是 Unit 的容器。租户由 Unit 组成，Unit 是数据库对象的容器。<br />&emsp;&emsp;创建租户时通过设置 RESOURCE_POOL_LIST，可以指定该租户关联到的资源池，从而该租户拥有指定资源池的 Unit。例如：设置租户 a 的 RESOURCE_POOL_LIST = ('a_pool')，其租户的资源部署就如下图所示：<br />  <br />&emsp;&emsp;该租户部署于 3 个 Zone，每个 Zone 有 2 个 Unit，可以通过调整特定的参数，来动态调整租户的物理资源。 <br />&emsp;&emsp;还可以通过调整 Unit 在同一个 Zone 内不同节点的分布（称为 Unit 迁移），从而达到 Zone 内不同节点间的负载均衡。节点故障时通过将其上的 Unit 迁移到同 Zone 内其他节点上，从而达到自动容灾恢复的目的。通过调整 Unit 在不同 Zone 的分布（变更租户的 Locality 属性），从而调整租户的部署模式，例如 “同城三中心”、“两地三中心”、“三地五中心” 等，从而具备不同的容灾等级。 <a name="gOQkW"></a> ## 租户间的数据隔离和资源隔离 &emsp;&emsp;很多朋友好奇 Oceanbase 怎么实现多租户之间的隔离。其实租户就像一个容器，这套容器里包含了 table，database，user 等逻辑对象；也包含了分给这个租户的内存，cpu，磁盘空间等物理资源。 <a name="dqkIW"></a> ### 逻辑对象隔离 &emsp;&emsp;不同租户的逻辑对象一定要处在不同的名字空间。逻辑对象实际是记录在内部表中的数据，为了保证名字空间独立，OceanBase 的每个租户都有自己一套完整的内部表，用于记录租户内逻辑对象的元数据信息，以此保证逻辑对象的隔离性。<br />  <a name="rhjZz"></a> ### 物理资源隔离 &emsp;&emsp;物理资源可以分为两类：一类是弹性资源，比如CPU，磁盘带宽等；另一类是刚性资源，比如内存，磁盘空间等。弹性资源是可以抢占的，刚性资源一旦被占用，除非占有者主动释放，否则是无法抢占的。<br />&emsp;&emsp;从定义上来说，刚性资源无法超卖，必须要强隔离；弹性资源可以一定程度上超卖。无论是刚性资源还是弹性资源，在observer里都有租户级别的记账，通过视图可以方便地查看。 ```bash select * from DBA_OB_UNIT_CONFIGS; +----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+ | unit_config_id | NAME | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT | +----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+ | 1 | sys_unit_config | 1 | 1 | 1073741824 | 2684354560 | 10000 | 10000 | 1 | | 1001 | 1c1g | 1 | 1 | 1073741824 | 3221225472 | 10000 | 10000 | 1 | | 1002 | 1c2g | 1 | 1 | 2147483648 | 6442450944 | 10000 | 10000 | 1 | | 1003 | 2c2g | 2 | 2 | 2147483648 | 6442450944 | 20000 | 20000 | 2 | | 1004 | 2c4g | 2 | 2 | 4294967296 | 12884901888 | 20000 | 20000 | 2 | +----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+ ``` <a name="yPRui"></a> #### 内存和磁盘空间隔离 &emsp;&emsp;内存和磁盘空间的隔离机制比较简单，一旦超过配额，后续的资源申请就会失败。为了降低资源耗尽的情况，observer 内部会根据内存和磁盘空间的消耗情况控制写入的速度。 <a name="QxT3k"></a> #### CPU 隔离 &emsp;&emsp;observer 最基础的 CPU 隔离是通过用户态调度，控制活跃线程数来实现的。每个租户有独立的线程池，线程池的规格是由租户规格和一些配置参数来决定的。<br />  <br />&emsp;&emsp;同时，observer 也支持配置 cgroup，来实现 CPU 的隔离优化。cgroup 能对线程的 CPU 使用率进行精准的限制，达到租户之间 CPU 强隔离的效果。<br />  <br />&emsp;&emsp;如果大家对 OceanBase 租户间的 CPU 隔离能力感兴趣，推荐阅读 OceanBase 社区里的这篇博客[《为什么资源隔离对 HTAP 至关重要》](https://open.oceanbase.com/blog/10900412?_gl=1*5e9nw*_ga*MTk2NDc5MjkwMS4xNjc2ODgyMjQw*_ga_T35KTM57DZ*MTY5MjI0MDM3MC40NC4xLjE2OTIyNDE5MzAuNC4wLjA.)中 “OceanBase 资源隔离的实现效果” 部分。 <a name="bFxiW"></a> #### 磁盘 I/O 资源隔离 &emsp;&emsp;observer 内所有的 IO 都是异步 IO，并且是绕过 OS 的 direct IO，磁盘带宽的隔离是通过控制 observer 提交异步 IO 的时间间隔来实现的。具体的控制策略比较复杂，这里不作详述。如果大家对 OceanBase 中如何实现磁盘 IO 的隔离能力感兴趣，推荐阅读 OceanBase 社区里的这篇博客[《OceanBase 4.1 解读：给用户足够灵活简单的 IO 隔离体验》](https://open.oceanbase.com/blog/3105048832?_gl=1*l1fhnb*_ga*MTk2NDc5MjkwMS4xNjc2ODgyMjQw*_ga_T35KTM57DZ*MTY5MjI0MDM3MC40NC4xLjE2OTIyNDE5MjQuMTAuMC4w)。 <a name="Kntah"></a> # OB Cloud 产品形态 &emsp;&emsp;OceanBase 在 AWS 云市场中提供的云数据库服不仅有适合 SaaS 服务的 Serverless 版本，同时也提供集群版本。<br />&emsp;&emsp;Serverless 版本会基于租户模式提供的 OceanBase 云服务，支持租户规格的自动扩缩容，每次扩缩容的步长为 0.5 个 OCU（OceanBase Capacity Unit），1 个 OCU 等于 1C2G 的资源。<br />&emsp;&emsp;集群版本提供的是集群模式的 OceanBase 云数据库服务，规格支持 4C/8C/14C/24C/30C/62C，默认为 3 副本方式（包括 3F 和 2F1L），支持 MySQL 和 Oracle 模式。<br />  <br />&emsp;&emsp;OB Cloud 不仅可以保障性能、显著降低成本，同时用户也无需关心底层云基础资源的管理和运维。OB Cloud 云数据库会为用户提供从基础云资源到数据库云服务的一站式解决方案。<br />&emsp;&emsp;国内企业大规模跨境出海，但海外基础设施合规、周边生态对接成为制约企业信息化业务的主要迁移难点。OB Cloud 云数据库通过与 AWS 周边生态的对接，合规安全的认证，完备的服务体系，为中资企业跨境出海提供有力的技术支持。<br />&emsp;&emsp;从 2022 年 OceanBase 入驻到 AWS 的云市场开始，例如海底捞等诸多 OB Cloud 用户，均通过 OceanBase 实现了降本增效，大大增强了企业的数字竞争力。正如海底捞项目的架构师所说：“当客流高峰过后，在 AWS Marketplace 上购买的 OB Cloud 服务的存储和算力都会自动 “收缩”，在保证服务质量的同时，还能够进一步降低企业的运营成本。”<br />&emsp;&emsp;如果大家对 OB Cloud 感兴趣，欢迎前往 [https://www.oceanbase.com/product/cloud](https://www.oceanbase.com/product/cloud) 或 [https://awsmarketplace.amazonaws.cn/marketplace/pp/prodview-w7oujzpio5jeg](https://awsmarketplace.amazonaws.cn/marketplace/pp/prodview-w7oujzpio5jeg)，以云服务的方式采购 OceanBase 云服务。或者前往 [https://www.oceanbase.com/docs/oceanbase-cloud](https://www.oceanbase.com/docs/oceanbase-cloud)，对 OB Cloud 继续进行更深入的了解。 <a name="w8pDh"></a> # OceanBase 开源社区 &emsp;&emsp;从 2021 年 OceanBase 开源以来，越来越多的开发者加入到 OceanBase 开源社区中。在社区中，除了可以为 OceanBase 贡献代码外，还能够畅所欲言，实现信息共享。 <br />&emsp;&emsp;欢迎大家关注 GitHub 上的 OceanBase 开源项目：[https://github.com/oceanbase/oceanbase](https://github.com/oceanbase/oceanbase)，OceanBase 会在这里为大家答疑解惑。如果大家对 OceanBase 有任何疑问，欢迎在 GitHub上提出你的 Issues。同时也欢迎大家成为 Contributor，参与到社区建设中来！