产品架构和特点 FAQ

我需要一个实例还是多个实例？

如果有多个子系统， 每个子系统在数据库层面没有交互，建议每个子系统使用不同的实例。

用户如何使用 OceanBase 数据库？

和传统数据库一样，OceanBase 数据库提供了 SQL 接口，用户可以通过 SQL 语言访问、操作数据库。

OceanBase 数据库与 JPA 冲突吗？

JPA（Java Persistence API）是 Java 标准中的一套 ORM 规范，借助 JPA 技术可以通过注解或者 XML 来描述对象与关系表之间的映射关系，并将实体对象持久化到数据库中（即完成 Object Model 与 Data Model 间的映射）。而 OceanBase 数据库是阿里巴巴和蚂蚁集团不基于任何开源产品，完全自研的原生分布式关系型数据库软件。两者不冲突。

数据文件对应哪个级别的数据库管理？

OceanBase 数据库中目前有两类数据文件，且两类数据文件均属于集群级别：

• Data 文件：保存各个分区的数据，包括各个分区的 Checkpoint 点。
• Clog 相关：包含 Clog（也称为 Redo Log 或 WAL 日志） 和它的索引文件。

OceanBase 数据库是如何支持 HTAP 的？

OceanBase 数据库自创的分布式计算引擎，能够让系统中多个计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用，真正实现了用一套计算引擎同时支持混合负载的能力，让用户通过一套系统解决 80% 的问题，充分利用用户的计算资源，节省用户购买额外的硬件资源、软件授权带来的成本。

什么是实例，什么是租户，它们的关系是什么？

OceanBase 数据库是一个多租户系统， 一个实例即 OceanBase 集群中的一个租户。 租户之间的数据不能互相访问。

OceanBase 数据库的性能和机器数量的关系是什么？

从 OceanBase 数据库的 TPC-C 报告中显示，相同场景下的基本都是线性扩展的。

使用 OceanBase 数据库在开发中要特别注意什么？

以下列出开发过程中的注意事项，仅供参考：

• 大数据量导入需要特别关注内存的使用情况。
• 索引生效时间较长，建议在建表时将索引语句一并纳入。
• 表建好后，主键不能更改。如果需要修改，只能删表重建。
• mysql-connector-java 的版本建议使用 5.1.30 及以上。
• 列类型修改有较大限制。Varchar 长度只能由短变长，不能由长变短。
• 如果一个连接超过 15 分钟空闲，服务端会主动断开，在使用连接池的时候需要设置一个连接最大的空闲时间。例如，Druid 的 minEvictableIdleTimeMillis 小于 15 分钟。

OceanBase 数据库是如何做到比传统数据库更省空间的？

OceanBase 数据库通过数据编码压缩技术实现高压缩。数据编码是基于数据库关系表中不同字段的值域和类型信息，所产生的一系列的编码方式，它比通用的压缩算法更懂数据，从而能够实现更高的压缩效率。

OceanBase 数据库做 AP 能力处理所需的数据量大概多少？

具体根据业务需求 100 G 到 PB 级不设限。AP 是 OceanBase 数据库提供的一个能力。数据量较小时，把并行设置小一些，用的计算资源就小；数据规模较大时，计算资源设置多一些。本质上并没有一个量的限制。AP 的能力，主要体现在把机器硬件资源充分调动起来的能力，以及生成高效的并行计划等方面的能力。

OceanBase 数据库最新版本中对标准 SQL 的支持度是多少？

在实际应用场景中，MySQL 模式的大部分业务均能够做到平滑迁移；Oracle 模式下基本的 Oracle 功能也都支持，只需要很少的改动就可以平滑地由 Oracle 数据库迁移到 OceanBase 数据库。

以前运行在 MySQL 上的业务，迁移到 OceanBase 数据库上的成本如何？

OceanBase 数据库兼容常用 MySQL 功能及 MySQL 前后台协议，业务零修改或少量修改即可从 MySQL 迁移至 OceanBase 数据库。

OceanBase 数据库作为一个以 TP 见长的数据库，AP 计算能力怎么样呢？

AP 主要采用行列混合存储、编译执行、向量引擎、基于代价的查询改写和优化等技术，再加上 OceanBase 数据库良好的可扩展性，OceanBase 数据库在 AP 领域里面的实时分析能力都是业界领先的。此外，对于离线大数据处理，Spark 等大数据方案也是更合适的选择。

OceanBase 数据库作为一款分布式数据库，业务 APP 连接数据库时和传统数据库是否有不同？

OceanBase 数据库作为分布式数据库，副本可能分布在不同的机器上，为了尽可能地减少跨机数据访问，OceanBase 数据库提供了 obproxy。obproxy 作为 OceanBase 分布式关系数据库专用反向代理服务器, 为前端用户请求提供了高性能、高准确率的路由转发服务, 为后端 Server 服务提供了高可用易扩展的容灾保障. 相对于其他数据库的代理服务器, obproxy 根据实际单机环境和 OceanBase 多集群部署的特点, 采用异步框架和流式转发的设计, 采用 FastParse 和 LockFree 的内存方案, 具备有限资源占用下百万 QPS 的能力和海量部署下丰富便捷的运维支持能力。

OceanBase 数据库的技术架构有哪些技术特点？

OceanBase 数据库作为一款原生的分布式数据库，有以下技术特点：

• 弹性扩展

  OceanBase 数据库支持在线弹性扩展，当集群存储容量或是处理能力不足时，可以随时加入新的 OBServer，系统自动进行数据迁移，根据机器的处理能力，将合适的数据分区迁移到新加入的机器上；同样在系统容量充足和处理能力富余时，也可以将机器下线，降低成本。比如在双 11 大促之类的活动中，可以提供良好的弹性伸缩能力。

• 负载均衡能力

  OceanBase 数据库管理着许多台 OBServer 节点形成一个 OBServer 集群为多个租户提供数据服务。 OceanBase 集群管控的所有 OBServer 节点可以被视为一个超级大的“资源蛋糕”，在分配资源时，按需分配给创建租户时申请的资源。 OceanBase 数据库的负载均衡能力能够保证多个租户在整个 OBServer 集群中申请的资源占用相对均衡，并且在动态场景下（比如添加删除 OBServer、 添加删除租户、增删过程中分区数据量发生倾斜等场景），负载均衡算法仍然能在已有的节点上平衡资源。

  OceanBase 数据库通过 Root Service 管理各个节点间的负载均衡。不同类型的副本需求的资源各不相同，Root Service 在执行分区管理操作时需要考虑的因素包括每台 OBServer 节点上的 CPU、磁盘使用量、内存使用量、IOPS 使用情况；避免同一张表格的分区全部落到少数几台 OBServer；让耗内存多的副本和耗内存少的副本位于同一台机器上；让占磁盘空间多的副本和占磁盘空间少的副本位于同一台机器上。经过负载均衡，最终会使得所有机器的各类型资源占用都处于一种比较均衡的状态，充分利用每台机器的所有资源。

• 分布式事务 ACID 能力

  OceanBase 数据库架构下事务的 ACID 的实现方式是：

  • Atomicity：使用两阶段提交保证快照事务原子性。
  • Consistency：保证事务的一致性。
  • Isolation：使用多版本机制进行并发控制。
  • Durability：事务日志使用 Paxos 协议做多副本同步。

• 高可用

  OceanBase 数据库中的每个分区都维护了多个副本，这些分区的多个副本之间通过 Paxos 协议进行日志同步。每个分区和它的副本构成一个独立的 Paxos 组，其中一个副本为主（Leader），其它副本为备（Follower）。每台 ObServer 服务的一部分分区为 Leader，一部分分区为 Follower。当 OBServer 节点出现故障时，Follower 分区不受影响，Leader 分区的写服务短时间内会受到影响，直到通过 Paxos 协议将该分区的某个 Follower 选为新的 Leader 为止，整个过程不超过 30s。通过引入 Paxos 协议，可以保证在数据强一致的情况下，具有极高的可用性及性能。

  同时 OceanBase 数据库也支持主备库架构。 OceanBase 集群的多副本机制可以提供丰富的容灾能力，在机器级、机房级、城市级故障情况下，可以实现自动切换，并且不丢数据（即 RPO = 0）。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间。

  OceanBase 数据库支持创建、维护、管理和监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将资源密集型的报表操作分配到备集群，以便提高系统的性能和资源利用率。

• 高效的存储引擎

  OceanBase 数据库的存储引擎基于 LSM-Tree 架构，数据被划分为MemTable（也称作 MemStore） 和 SSTable 两部分。其中 MemTable 提供读写，而 SSTable 是只读的。用户插入/删除/更新的数据先写入 MemTable，通过 Redo Log 来保证事务性，Redo Log 会在三副本间使用 Paxos 协议进行同步，当单台 Server 宕机时，通过 Paxos 协议保证数据的完整性，并通过较短的恢复时间来保证数据的高可用。 当 MemTable 的大小超过一定阈值时，就需要将 MemTable 中的数据转存到 SSTable 中以释放内存，我们将这一过程称之为转储；转储会生成新的 SSTable，当转储的次数超过一定阈值时，或者在每天的业务低峰期，存储引擎会将基线 SSTable 与之后转储的增量 SSTable 给合并为一个 SSTable，我们将这一过程称之为合并。OceanBas 数据库通过转储和合并的过程，优化了数据存储空间的基础，提供了高效的读写服务，保证事务性和数据的完整性。

• 多租户

  OceanBase 数据库是一个支持多租户的分布式数据库，一个集群支持多个业务系统，也就是通常所说的多租户特性。 多租户的架构优势在于可以充分利用系统资源，使得同样的资源可以服务更多的业务。通过将波峰、波谷期不同的业务系统部署到一个集群，以实现对系统资源最大限度的使用。在租户的应用方面，保证了租户之间的隔离性；在数据安全方面，不允许跨租户的数据访问，确保用户的数据资产没有泄露的风险；在资源使用方面，租户“独占”其资源配额，该租户对应的前端应用，无论是响应时间还是 TPS/QPS 都比较平稳，不会受到其他租户负载轻重的影响。

• Oracle 兼容和 MySQL 兼容

  OceanBase 数据库支持 Oracle 兼容模式和 MySQL 兼容模式，用户可以根据不同的需要选择不同的模式。

内存 FAQ

OceanBase 数据库有哪些内存区域？

OceanBase 数据库中主要有以下内存区域：

• kv cache：LSM-Tree 中 SSTable 及数据库表模式等的缓存。
• memory store：LSM-Tree 中的 MemStore 的内存。
• sql work area：租户执行 SQL 过程中各个 Operator 工作区占用的内存，超出部分通常会走落盘流程。
• system memory：预留给 Net IO、Disk IO、Election 与负载均衡等各种功能的内存。

OceanBase 数据库的资源在租户中哪些是共享的，哪些是不共享的？

对内存而言，sql work area、memory store 与 kv cache 等资源为租户独享；system memory 为多个租户共享。对线程而言，sql worker 为租户间隔离；Net IO、Disk IO 与 Clog Writer 等资源为租户间不隔离。

OceanBase 数据库的内存使用有什么特征？

OceanBase 数据库在启动时会需要加载大约几个 GB 的内存，在运行过程中会逐渐按需进一步申请内存直至 memory_limit。而一旦 OBServer 节点向 OS 进行了内存申请，通常是不会释放或者返回给 OS，而是会维护在内存管理的使用列表和 Free List 当中。这个是 OceanBase 数据库设计上所建立的内存管理机制。

运行一段时间后，OceanBase 数据库使用内存接近 memory_limit 是否正常？

在 OceanBase 数据库的集群运行一段时间以后，内存消耗接近于 memory_limit 水平位置，且不发生降低的现象是符合预期的。 有一个例外是若设置了参数 memory_chunk_cache_size，OBServer 节点会尝试将 Free List 超过 memory_chunk_cache_size 的内存块还给 OS，增大 Free List 在 OceanBase 数据库内部的复用率，减少 RPC 由于内存操作慢而导致超时的风险。通常情况是不需要配置 memory_chunk_cache_size 的，在特定的场景下需要与 OceanBase 数据库 支持进行场景分析确定是否需要动态调整 memory_chunk_cache_size。

OBServer 节点的内存上限是否可以动态调整？

OBServer 节点的内存上限可以通过调整 memory_limit 或 memory_limit_percentage 来动态实现。需要注意的是调整前要检查内存资源是否够用，OBServer 节点内存上限目标是否已经低于了所有租户以及 500 租户的内存分配（租户建立时分配）的总和。memory_limit 的单位是 MB，例如，如果需要通过调整 memory_limit 参数来调整 OBServer 节点内存上限为64G，可以通过语句 memory_limit ='64G' 或者通过 memory_limit = 65536 来指定。 另一方面，在使用 OBServer 节点的过程中，可能通过 memory_limit 来限制 OBServer 节点内存的生效参数。若将 memory_limit 设置为 0，还可以通过 memory_limit_percentage 以比例的形式更灵活地约束 OBServer 节点内存的使用情况。

在使用 OceanBase 数据库定义资源单元以及资源池时是否允许内存超卖？

在使用 OceanBase 数据库定义资源单元以及资源池时, Root Service 负责分配资源（Unit）。Root Service 在分配 Unit 的时候会根据 resource_hard_limit 来决定内存是否可以超卖 (resource_hard_limit 表示内存超卖的百分比，大于 100 表示允许超卖)，Root Service 再具体分配资源的时候还会按照 Unit 本身定义的资源单位来进行分配。 但是在通常情况下，如果资源相对来说比较紧张，系统不同的租户负载可以有控制地交错运行，配置租户时有可能会对 CPU 资源进行超卖。如果 CPU 超卖生效，OceanBase 集群在运行过程中会产生负载过载等情况，那么不同租户间会产生线程竞争 CPU 的现象，直接导致的结果是租户实际业务场景变慢。若是内存配置成超卖场景，虽然在创建租户时租户规格总和可以超过 memory_limit，但实际使用时 OceanBase 数据库的内存使用还是会受到 memory_limit 约束。比如在运行中的租户消耗的内存总和将要超过 memory_limit，租户会报内存超限问题甚至进程直接 OOM。

OceanBase 数据库进行一次内存分配会检查哪些限制？

OceanBase 数据库内核限制了单次的内存申请不能超过 4G，这个限制并非是对用户可见的。而是为了内存的优化使用和避免不合理的内存分配在内核中添加的限制。除此之外 OceanBase 数据库内核中每次进行内存申请还会进行如下检查，在出现相应的报错时，请根据对应的报错信息来具体分析：

OceanBase 数据库的 KVCache 有哪些，分别有什么作用？

对于 OceanBase 数据库的 KVCache 可以通过 GV$OB_KVCACHE 视图进行查询，大体上有一下几种：

• BloomFilter Cache：OceanBase 数据库的 BloomFilter 是构建在宏块上的，按需自动构建，当一个宏块上的空查次数超过某个阈值时，就会自动构建 BloomFilter，并将 BloomFilter 放入 Cache。
• Row Cache：缓存具体的数据行，在进行 Get/MultiGet 查询时，经常会将对应查到的数据行放入 Row Cache，这样在进行热点行的查询时，就能极大地提升查询性能。
• Block Index Cache：缓存微块的索引，类似于 Btree 的中间层，由于中间层通常不大，Block Index Cache 的命中率通常都比较高。
• Block Cache：OceanBase 数据库的 Buffer Cache，缓存具体的数据块，实际上 Block Cache 中缓存是解压后的微块。
• Partition Location Cache：用于缓存 Partition 的位置信息，来帮助对一个查询进行路由。
• Schema Cache：缓存数据表的元信息，用于执行计划的生成以及后续的查询。
• Clog Cache：缓存 clog 数据，用于加速某些情况下 Paxos 日志的拉取。

KV Cache 如何做到的动态伸缩，以及有什么样的淘汰规则？

可动态伸缩的内存主要部分是 KV Cache，而 OceanBase 数据库将绝大多数的 KV 格式的缓存统一在了 KV Cache 中进行管理。 KV Cache 一般不需要配置，特殊场景下可以通过参数控制各种 KV 的优先级，优先级高的 KV 类比优先级低的 KV 类更容易被保留在 Cache 中。若要调整默认的 KV Cache 相关优先级的默认配置，需要联系 OceanBase 数据库技术支持工程师。

OceanBase 数据库内存有哪些常见问题，可能导致的原因是什么？

OceanBase 数据库内存有如下常见问题：

• 工作区（work area）报内存不足

  工作区内存 limit = 租户内存 * ob_sql_work_area_percentage（默认5%），如果请求并发量较大，且每个请求占用的工作区内存比较多，可能出现工作区内存不足的报错。经常出现的场景有 union、sort、group by 等。 可以通过适当调大工作区系统变量来规避比如 set global ob_sql_work_area_percentage = 10。

• 租户内存不足

  客户端报错 "Over tenant memory limits"，错误码 4013，租户内存不足。通常需要进一步分析当前内存消耗的情况。 可以通过 GV$OB_MEMORY 视图，也可通过 observer.log 中的日志查看是哪个 mod 消耗的内存绝对占比比较大。

• MemStore 内存用尽

  写入的速度大于转储的速度，导致 MemStore 耗尽。比如大量高并发的数据导入，MemStore 的写操作过快，系统未能及时转储，MemStore 就被用完，返回用户报错 4030。 可以通过分析转储速度缓慢瓶颈、尝试提高转储速度，或者是减缓写入速度来减缓、解决这类问题。

• OBServer 节点整体内存使用超限

  OBServer 节点进程在启动过程中，会根据配置的参数来计算当前进程最大使用的物理内存上限。 如果 memory_limit 配置数值，那么 OBServer 节点的内存会直接取 memory_limit。如果 memory_limit 为 0，则会通过 物理内存 * memory_limit_percentage 来计算得到内存使用上限。 若观察到 OBServer 节点内存使用超限，可以查询 _all_virtual_server_stat 可以看到实际的 OBServer 节点内的 limit, 然后再次检查 memory_limit、memory_limit_percentage 这两个参数是否配置正确。 如果还存在内存超限且整体趋势持续增长的情况，那么有可能是遇到了内存泄露的场景，需要联系 OceanBase 数据库技术支持工程师来进行排查解决。

多租户线程 FAQ

OceanBase 数据库是如何管理线程的？

在 OceanBase 数据库中，OBServer 节点尽量避免动态创建线程，基本上所有线程在启动后就已经创建好，后续除非调整配置项，否则线程数基本不会再变化。 同时，某个租户在特定 OBServer 节点上的 sql worker 和 transaction worker 的线程数由租户的 Unit 规格决定，其它的线程由对应的配置项指定。

OceanBase 数据库中各线程资源分配的原理是什么？

OceanBase 数据库中各线程被分配的资源及其分配原理如下：

• 网络与 I/O 目前未进行控制。
• 内存：不同租户的内存是分开管理的，当前执行的 SQL 属于哪个租户，即使用该租户的内存分配器来分配内存。
• CPU：在任意时刻一个租户能同时活跃的线程是受限的。例如，某租户配置了 16 个 CPU，且配置项 cpu_quota_concurrency 的值设置为 2，那么该租户最多可以有 16 * 2 = 32 个活跃的 SQL 线程，而实际活跃线程数由 OBServer 节点的用户态线程调度器控制。

OceanBase 数据库在运行过程中是单进程还是多进程？

OceanBase 数据库是单进程数据库，运行过程中的主要线程如下：

• election worker：选举线程。
• net io：处理网络 I/O 的线程。
• disk io：处理磁盘 I/O 的线程。
• clog writer：写 Clog 的线程。
• misc timer：包括多个后台定时器线程，主要负责清理资源。
• compaction worker：处理 Minor Merge、Major Merge 的线程。
• sql worker 与 transaction worker：处理 SQL 和事务请求的线程。

OBServer 节点有哪些后台线程，主要是做什么用的？

在大部分场景下，用户无需关注后台线程实现细节。在 OBServer 节点版本迭代中，后台线程也会出现更新的情况。 如下列举出 OBServer 节点的部分常见后台线程，以及其相关功能介绍。

OBServer 节点的多租户架构中如何做到 CPU 资源的有效隔离？

在 OBServer 节点目前发布的版本中，OBServer 节点主要是依靠控制活跃线程数量（实际消耗 CPU 资源的线程）来控制 CPU 消耗的。OBServer 节点在创建租户的时候会指定租户资源池，资源池定义 max_cpu 可以限制的租户级别的最大活跃线程使用，从而做到租户间 CPU 使用的隔离。在 OBServer 节点的最新版本中，OBServer 节点内核实现了 cgroup 的隔离来对 CPU 内存和资源进行有效地控制和限制，这需要操作系统级别的配置搭配生效。目前 OceanBase 数据库正在将这个能力整合到工具平台中，使得未来部署的 OBServer 节点可以直接利用 cgroup 隔离实现资源的有效控制和限制。

如何读取 OBServer worker 线程的数量呢？OBServer 节点是否会在负载高的时候动态启动新的线程来执行负载呢？

在 observer.log 中以关键字 dump tenant info 为主的日志片段里，会描述现在 worker 线程的现有值以及最大值。具体为下：

tocken_count = 分配给该租户的 cpu_count (>min_cpu&&<max_cpu)  _cpu_quota_concurrency。

举例一个特定的场景， 一台装有 OceanBase 数据库的机器上租户 T1 配置了 unit_min_cpu = 2, unit_max_cpu=8, 但是在该台机器上配置的 CPU 资源存在超卖。分配给 T1 的实际 CPU 为 5。那么 token_count = 5_ cpu_quota_concurrency。

OBServer 节点是如何对租户活跃线程和线程总数进行控制的？

OBServer 节点根据租户的 cpu_count * cpu_quota_concurrency 计算活跃线程数，这些线程在租户创建的时候就会被创建好。比如线程 A 是个活跃线程，它因为执行大查询被挂起，这时活跃线程就少了一个，作为补充，这个租户会额外再创建一个活跃线程。但是一个租户能创建的线程总数也是有限制的，总数限制为 cpu_count * workers_per_cpu_quota。当租户线程数到达上限后，新创建线程会失败，线程 A 不会被挂起，以保持活跃线程数始终不变。 举个例子，假设一个租户配置了 16 个 CPU，集群的 cpu_quota_concurrency 设置为 2，那么这个租户最多会有 16 * 2 = 32 个活跃的 SQL 线程，控制活跃线程数是 OBServer 节点的用户态线程调度器实现的。

大查询 CPU 资源分配原则是什么？ OLAP 和 OLTP 同时存在的情况下会出现抢占 CPU 资源的情况么？

在使用 OceanBase 时，可以通过配置参数 large_query_threshold 来定义执行时间超过一定阈值的查询操作为大查询。如果系统中同时运行着大查询和小查询，OceanBase 数据库会将一部分 CPU 资源分配给大查询，并通过配置参数 large_query_worker_percentage （默认值为30%）来限制执行大查询最多可以使用的租户活跃工作线程数。 OceanBase 数据库通过限制大查询能使用的租户活跃工作线程数来约束大查询使用的 CPU 资源，以此来保证系统还会有足够的 CPU 资源来执行 OLTP（e.g.交易型的小事务）负载。通过这样的方式来保证对响应时间比较敏感的 OLTP 负载能够得到足够多的 CPU 资源尽快的被执行。此外需要注意的是，OceanBase 数据库可以做到大查询和 OLTP 资源的分配，large_query_threshold 参数也应设置在一个在合理的范围内，不应该设置成为一个过大的值。否则大查询很容易抢占掉系统的 CPU 资源而挤进而引发 OLTP 响应过慢甚至队列堆积的问题。