前言
有一天，偶然间听到用户说：“ OceanBase 产品最近都有哪些功能，不知道我之前提的功能带没带上”，一时间好几个用户都表示赞同，表明大家都想知道 OceanBase 当前的产品功能和未来的产品规划。基于此，我们邀请部分用户参与 OceanBase 产品 Roadmap 线上交流会，与开源负责人纪君祥纪老师聊聊 OceanBase 产品规划。本次交流一方面介绍当前 OceanBase 的产品规划以及重大版本的功能点；另外一方面听听大家对 OceanBase 产品的诉求以及需求，使得 OceanBase 能更好的解决业务痛点的同时在使用上更加简单易上手。本文基于 2022.3.17 交流记录整理而成。
产品 roadmap 介绍
3.1.3 功能特性
内核侧
- ARM 支持: OBServer/OBProxy/OBD 支持 ARM 系统, 但工具还没有完成适配, 进度已经完成了, 银联已经在提前试用. 需求方: 银联, 民生银行, 中国联通等超过10人+
- JSon 支持: 支持 JSon, 去年9月份开始研发, 当前研发已经完成, 当前还在测试中, 如果通过测试就会按计划发版, 否则往后推一个版本. 需求方: 民生银行, 携程, 阳光保险等
- HBase api 支持: 将内部大面积使用的 HBase api 开源出来, 当前进度已经完成. 需求方: 贝壳, 小米, CeresDB 等. 性能想较默认的 hbase 2.4.6 的 sync 方式 有不少提高, scan 性能2.42倍, insert 1.7倍
- Table api 异步支持: 从去年9月份开始实现, 底层线程池来异步响应用户的请求, 主要提升table api 的吞吐量.在batch api下, 性能提升300% ~ 500%.
- 回收站恢复 Tenant & Database & Table & Index: flashback 恢复回收站对象.
- 小规格优化 2c8g, 2c8g docker 运行 OceanBase
- 默认创建 local 索引 : 已经完成
- information_schema.TABLES 增加 ENGINE 值: 需求来自58 同城
自研生态工具
OCP 社区版(3.3.0-ce) 4月30日 release
- 开放备份恢复功能: 未来无需敲命令进行恢复
- 接管 OBD 部署集群功能
- 接管 OBProxy 集群功能
- 安装简化
- 增加检查功能, 接管集群时, 添加主机时, 增加部分检查, 避免安装过程中报错
OMS 社区版( oms 3.2.2-ce-bp2) 3月30日 release
- 社区版 CDC 支持持久化: 移植商业版功能, 需求来自浦发银行, 这个功能当前进度, 已经完成开发, 但将 liboblog 改名为 libobcdc , 涉及大量上下游协同改动, 因此有可能会延后一个版本
- 解决超大事务 OOM 风险
- 提取拉取速度, 降低 限速阀值, 防止历史 clog 日志太久没有消费, 而被覆盖掉
OMS 社区版(3.3.0-ce) 5月9日 release
- 支持 OceanBase 到 OceanBase 数据迁移和同步
- 支持 OceanBase 到 kafka & rocketmq 数据迁移和同步
安装易用性改进
OBDeployer (1.3.0) 3月30日
- ARM 支持
- OBD 在出错的场景下打屏输出帮助链接地址
开发者中心 ODC
- OceanBase 在线体验站 play.oceanbase.com 切到社区版
ob-admin 工具
- 提供不打印数据的 clog 解析工具
驱动
- python 驱动已经完成验证
- python 3.X pyMySQL
- python 2.X MySQL-python
- golang Go-SQL-Driver/MySQL
- Unix ODBC
sql plan monitor
- 可视化展示 SQL Plan , 开源流程中, 预估在下个月会开放出来
生态合作
- CloudCanal 合作
- 已经完成 MySQL --> OceanBase
- OceanBase --> MySQL 正在研发, 预估 下个月完成
- 通过 Flink CDC 全量及增量同步 对接 Flink CDC
- 通过 otter 双向实时同步 对接 otter 广州智通人才
- 对接南京基石数据智能运维平台 D-smart 大师问诊软件
3.1.4 功能特性
内核
- data file 按需申请大小
- ObServer 内核原生支持 Prometheus 监控数据输出
- 扩所容时, unit 进度可查询
- Golang 支持 PS
- 多模数据库ttl 过期数据自动删除
- data_dir参数值不准确
OCP (3.4.0-ce)
- 白屏化安装所有工具
- OB-operator 能够支持修改 OceanBase 配置
OBDeployer
- 能否在安装时启用 playground 方式
- 一键运行 TPCC 测试
sql-diagnoser
- 诊断工具的敏捷版
- 可疑 SQL 诊断
- 一键收集和系统诊断相关 metrics
- 一键手机诊断日志和元数据
生态合作
- 2022/4 通过 Chunjun(原 flinkx) 对接 Chunjun
- 计划每月完成一家公司对接
详细信息参考：https://github.com/OceanBase/OceanBase/discussions/838
QA 部分
关于合库合表
Q1：我们现在有一个场景，在 MySQL 里面是一个分库分表，比如说订单分了32个数据库，每个数据库里面又分了32张表，相当于1024张表。如果迁移到 OceanBase 上面，是需要将这些表聚合到一张表里。现在有工具支持这个功能吗？
A：目前商业版工具 OMS 天然有这个功能的，社区版也是可以实现。
关于字符集
Q2：今天装了一个 OceanBase 环境，然后把 MySQL 里面的数据往 OceanBase 里面导，发现 OceanBase 支持的字符集很有限，当前 MySQL 字符集是 UTF8 ，OceanBase 现在还不支持？。
A： OceanBas 当前支持 utf8mb4, 另外 OceanBase 支持 UTF8 一些列字符集的需求已经在我们4.0的计划里面。比较急的话，我们可以把这个需求往前排。
Q3：OceanBase 支持拉丁字符集吗？拉丁字符集的表迁移到 OceanBase 可以吗？
A：现在还不支持，因为我们要绕过整个 MySQL，自己重写比较耗时间。如果是逻辑迁移的话，正常情况下在迁移时转换过来就可以了。开源版下一步会支持 UTF8 系列，目前只支持 UTF8mb4 字符集。如果遇到报错了，我们可以看一下。
关于 php 语言兼容性
Q4：如果开发语言使用 php，使用 OceanBase 的话，兼容性怎么样？CDC 数据同步的性能怎么样？
A：理论上如果能连上MySQL 5.6，应该就可以连上 OceanBase。之前有用户吐槽过一次php有点问题，我们回去再自己测一下。第二个问题是 CDC 的性能，浦发银行上次做过一次压测，大概 QPS 超过3万的时候，CDC 触发了限流。后面 CDC 持久化功能（正在做）有了之后， 性能会有提升。
关于冷热数据分离
Q5：想问一下 OceanBase 会不会支持冷热数据自动分离功能？我看同类其他产品已经支持冷热数据分离功能了。
A：冷热数据分离这个需求，我们有计划支持这个功能。其实像底层存储使用 LSM-Tree，理论上更容易支持。
关于误删除数据找回
Q6：刚才讲到 4.0的时候有个 FlashBack 功能。这个其实是回到过去一个物理表的一个时间点的一个快照吧？OceanBase 能支持提取某段时间的一些 SQL 语句吗？比如说一张表其实是多业务在使用，如果返回到某个时间点，一个业务操作会影响到全部业务。可能是部分业务的数据修改错了，可能需要找出这段时间是做了哪些修改，SQL 审计数据是不全的。现在 OBadmin 里面有一个可以返回 SQL 语句的功能，能不能做一个增强功能，返回一个时间段 SQL 语句？比如近一个小时修改了某些数据，OBadmin 返回这段时间的一个DDL & DML 操作的 SQL 语句。拿到语句之后，可能要反向把数据写回去，比如这个语句是 delete 的操作，通过 OBadmin 解析出来的时候就变成一个 Insert 的操作反向回去。在实际的业务运维过程中会经常碰到业务代码的一个 bug，导致数据被误修改。
A：第一个问题应该是可以的。
第二个问题：这是一个功能，目前 obadmin 提供这个能力，但是他现在是数字的，类似 CSV，然后这个变成 SQL 的话，我觉得可以做个需求。另外可以用 OceanBase的flashback query 功能，这个和 oracle 很像 ，可以查到这一行数据的过去的一个轨迹，知道这个轨迹以后，可以用 flashback query 功能 Insert 上到另外一张表里，然后再用 insert 之后的那张表。这样就不需要解析 binary log，会更简单一点。
Q7：实际运维过程中开发可能不清楚具体修改了什么数据，想导出所有这些修改的数据，然后去决定返回哪些数据。比如说表名作为关键字查询，把这段时间的所有的必要操作的语句反解析出来，然后开发去决定筛选哪些数据去执行。
A：这个可以的。他解析 binary log 的其实是 clog 里面的内容，和 MySQL 的原理是一样的。另一个也可以做，用 flashback query。他可以让您针对任意一张表 flashback query，因为这个数据在 OceanBase 里存储的时候，它是一个有 version 的。比如说您指定了一张表，这张表在昨天的4点到5点之间的所有的修改，把它查询出来，然后就可以把4点到5点的这个数据打到一张视图里的，一般传统像 oracle 这样玩的会比较多。然后在 MySQL 里一般都是用解析 binary log 的这种方式。这个功能在 3.0 的 OB-admin 工具就有了，不过日志输出格式不是特别精细，这个需求我们记录下。
关于单副本恢复
Q8：分布式数据库可能涉及到很多的组件，它的复杂度会比单机数据库复杂。对于运维方来讲，一个新的分布式数据库产品，需要有一种能力能够快速恢复业务。OceanBase 能不能有一种能力，比如说去降级？先恢复业务，而不是等待开 case 排查这种一个相对时间较长的方式去解决问题。对于老板来讲，要求是在几分钟内能够暂时把业务恢复。
A：类似相当于两个副本挂了，整个集群是一个单副本的，希望能够把其他的业务全部给扛起来对吧。OceanBase 是有这个功能，不过操作起来挺危险的，我们自己操作的时候都需要比较资深的人去操作这件事情。另外这其实是一个理念的问题，它破坏了很多内部状态，会丢数据，然后修复起来比较麻烦，所以一般我们会把这个问题分类，是硬件的问题？是容灾的问题？还是 query 的问题？比如说可能遇到的一些 bug 或者 memory 这方面的一些问题。针对这些不同的问题，我们在 OceanBase 里面做了很多管理的命令，帮大家可以用这些管理命令来去解决这些问题。然后另外一个方向就是 OceanBase 的备库，它会支持一个 Slave ，这个 Slave 和 Master 是两个集群。如果一定要做这件事的话，其实一个比较简单的方式是再做一个 Slave 的 Master，如果这个主挂了，就切到 Slave 的 Master 上 。举个简单的例子，现在遇到了一个场景，这个场景里业务写了一个 query ，然后把数据库给打爆了，普通租户连接三个 zone 都连不进去了。OceanBase 设计的 sys 租户从内存到线程到 CPU 都是隔离的，避免业务租户不能登进去的时候，sys 租户可以登进去去处理问题 SQL。同时还可以用 OceanBase 的一些其他能力，比如说 SPM ，对单条 SQL 做限流，或者是这个单条 SQL 里，比如有些用户是热点，拿用户来做限流这种方式去解决这个问题。对比 MySQL，它的登录的线程和用户用的线程都是一样的，当用户的线程把这个 MySQL 环境干趴的时候，业务是很难登上去。
Q9：我理解有些管理命令可以去做这个事情对吧？比较担心的是这个分布式系统在开源上面，不知道是网络还是整个基础设施，或者是软件的问题，导致整个分布式不工作。对官方来讲，产品是内部研发出来的，有现场解决问题的能力。但对外部用户来讲，如果走开 case 流程，时间就过了30分钟或者是40分钟。其实老板是不允许的，我们的一个要求是在3到5分钟就必须要马上恢复起来，我们不可能束手待命的，降级实际上是有损数据，大家都清楚， 但是这个会造成什么问题需要讲清楚，对用户来讲，至少需要把部分业务先恢复起来，不能让整体业务无法访问。
A：MySQL 很难找到官方的任何 support, 但 MySQL 已经广泛的被使用起来, 核心就是提供一个稳定可靠的高可用方案, OceanBase 如果 paxos 的3节点还不能满足用户的高可用的需求, 还可以利用 OceanBase 提供了 Slave 的服务，实际上多加一个节点，这个节点你可以认为他和这个 Master 是独立的，他所有的原始数据和管理都是分开的。通过 binary log，可以指定来做同步或者是异步复制，这是一个比较完善的产品方案。
Q10：整个 OceanBase 架构比较庞大, 不仅有1：1：1（一个 zone 一个OceanBaseserver，默认三个zone），可能有很多 zone，同时可能有十几台 server，按照主备架构的介绍，其实是多了一个 zone，成本又增加了很多。
A：我们其实有个参照。OceanBase 支持 log 副本，也支持全功能的副本，可以放三份全功能副本，或者是放两份全功能副本加一个 log 副本，然后把另外一份全功能副本做成 Slave ，这其实是一种方式。另外 OceanBase 是 压缩存储，开源的 OceanBase 在每次合并的时候会做一些压缩。理论上空间占用比 MySQL 省很多的。有个真实数据大家可以参考下：企业版 OceanBase 三个副本的存储空间量大概是 MySQL 2个副本空间量的三分之一。
关于合并与性能影响
Q11：还有一个合并的问题，蚂蚁内部对合并是怎么做优化的？比如每日凌晨的大合并是怎么做的？轮转合并业务是受损的吗？当前的长连接会被强制中断吗？
A：首先在蚂蚁的话，现在基本上所有的业务都是轮转合并，因为轮转比较快，其次在切主的这个过程中，我们做了一些优化，保证事务不会kill掉。但这个在3.X之前有个限制。假设你的事务超过两三百毫秒，这个事务有可能会被kill 。但是如果没有超过两三百毫秒的话，在切主过程中，事务是不会被影响的。在4.0里面，不管这个事务有多长，在切主的时候会把事务状态转移到另外的机器上，切主的时候都不会影响。
Q12：实际上我们运维过程中会碰到一些正式的数据往TP 数据库去导，对业务来讲是单个连接，持续时间可能是以分钟为计算的长事务。目前我现在版本（3.x），如果不停的进行轮转合并，数据的同步是会受影响？
A：OceanBase 在合并那一刹那，有两种合并，一种叫 minor compaction，整一个叫 major compaction。在 OceanBase 一直都有一个很深入的理念，我们需要让数据一定是对的。所以在 3.X 之前，我们为了保证数据对的，把所有的数据在合并的时候都打上一个版本，方便我们做每日合并的时候做整个数据库的 check sum 的校验。所以在 3.X 之前，在 major freeze 的时候，需要所有的集群的所有节点都在同一时刻冻结起来。就这一刹那，超过200毫秒的时候会被kill 掉。每天只会有一次，这个冻结可能会杀掉这个事务，正常他会有一个 major compaction，当内存里的数据装不下了就会把这个内存里的数据刷到磁盘上，这个操作是不会 kill 事务。
Q13：接之前的合并的问题，比如在归档数据的时候，一些表和数据可能是超过一定时限的，比如是从生产上直接归档到备份库里面，在做这个事情的时候，我们发现在 delete 的时候，根据主键去删除，或批量删除的时候，会越删越慢。可能是因为版本太多了，导致了性能下降？
A：这个东西就是 Tombstone ，它是在 LSM Tree 这种架构下一种比较常见的一些东西，我们传统的基于 B Tree 的这些数据库，比如说 oracle 和 MySQL ，删了一行数据以后有可能很快就把这个数据从那个 block 上去掉了。像现在的这些数据库，基本上它都是在 compaction 时候做的，这些数据虽然被删除了，但是其实还在内存里占了一些空间。刚才提到的问题，猜测是 delete 语句 后面可能有个 limit ，可能没有什么 where 条件。这类情况可以这样做：假设一张表有100万行数据，在 delete 的时候，where 后面有个条件，那个条件比如说开始是零，然后到1000 ，然后接下来从1001 ，然后到2000，根据主键切分。
Q14：下一个问题是轮转合并的问题。大合并做轮转合并的时候，是一个一个zone做吗？如果我的那个数据是分区的，打散在各个 zone 上面，这样就可能会导致切三次主，对吗？如果是哈希分区的话，他肯定是每个副本上都有的。我了解到的是，大合并的时候，他对大事务应该等待，等待这个大事务完成以后，才去做大合并，而不是把它kill掉，想确认一下是不是这样。
A：我理解这个不全是。因为大合并的时候，有一个瞬间是要把 memtab 给冻结掉，冻结可能是要切主。如果这时做切主，事务没有在比较短的一个间隔内给提交掉，那这个时候可能是会被杀掉，现在的时间里面是这个样子的。
这一块也有一个优化如果是 OceanBase 感知到是一个主动发起大合并，并且其他的 follower 没有异常，我们会先把没有做完的事务的数据先持久化下去，之后就可以同步到别的机器，然后在另一台机器上去把这个事务状态再恢复出来，可以尽量的避免杀事务，甚至有可能做到完全不杀事务。这个正在做，目前的话应该还是会杀掉部分事务的。有的事务可能会耗时特别长，所以我们只是选了一个时间间隔，在这个比较小的间隔之内是不受影响的。如果依然没有做完，那可能就是会杀掉的。
关于 SQL audit
Q15：我们的 sql audit 数据现在是放在表里面，同时有内存限制大小的。OceanBase 是否可以像日志或者监控数据一样，从 prometheus 的端口吐出来，这样的话能保证在高并发情况下数据的完整性，不会有丢失的风险。
A：我们可以提个需求看看怎么做。现在 OCP 里面会定时的采集。定时采集它其实并不一定能保证完整的一个输出。如果要保证完整的话，要对一下这个怎么去实现。这个在 Oracle 里有一个功能，那个功能它可以把这个sql audit 写入到一张实体表里面，但是可能会比较占空间。写到实体表之后，就可以用来做审计，包括一些更详细的性能分析。在蚂蚁是这样做的：每一台机器上会有一个 agent ，不停的 pulling sql audit 信息，实际业务中可以根据 workload 去评估一下。内部做的 agent 支持一些简单的 filter ，还有一些聚合类的东西，在大部分场景下够用。
关于 agent 数据采集
Q16：咨询个问题，agent 本身去连 OceanBase 的时候是不是也是一个连接？如果是这样的话，那么故障发生的时候，有可能是 CPU 打满或者是线程打满，进程堆积了，可能连接数已经连不进去了。这个 agent 是不是无法连接了？
A：我们有个系统租户，他是 specialize 的 thread pool ，它的线程池和用户的线程是隔开的，所以肯定是可以连上去的。这是一个专门的 admin 租户（需要再去 check 一下）。我们现在在做一个更高阶的 feature ，这个feature 会在 server 上跑一段 lua 。跑完这一段 lua，可以把需要的 states 收集下来。比如说当需要执行 SQL ，当前需要知道 schema ，还需要做权限的认证，再拿到 schema ，再构建一大堆的内存，然后再去查。这个当中任意一个环节，如果有问题可能都会失败。我们在里面集成了一个 lua 语言的引擎，这个引擎它可以把内存 memory 里的这些数据，直接 dump 出来到一个位置，所以无论如何这个监控都是可以拿到的。这个有点像Oracle，他的那个 monitor 的很多信息是写在 memory 的固定的位置，市面上有很多商业的工具，他就是直接去读那些 memory ，然后把这些 states 拿出来。我们其实有这种机制，但是我不确定开源版是不是放出来了。但是我理解这种机制应该会慢慢的 patch 到我们开源版本上。
关于 OMS 依赖
Q17：OMS 这个组件现在是强绑定 OCP 的，携程这边最初开始的时候是 OMS & OCP，这个强绑定问题能不能解决？
A：这个需求很多人提过，58同城也提了这个需求，是一个共性的需求，这个已经在考虑做了，会把 config server 剥离出来，争取在6月份做完。
关于空间申请与 IO 影响
Q18：下个版本, 提供动态按需申请空间的功能, 当前版本是直接划了数据块。想问一下在 datafile 申请空间的时候，比如写到一定程度，再去升级空间，这时会不会影响 IO 的性能?原来用 SQL server 的时候, data file 的大小，设置好了以后，如果触发了这个升级空间， IO 会很重，这个时候会影响 IO 的。
A：不会的。当然也要文件系统支持，如果文件系统支持调用 fallocate 这个函数的话，我们这边会调这个 fallocate 的。它其实文件系统只是把空间预留出来，并不会有真正的操作，所以是不影响 IO 的。
关于 OceanBase 之间同步
Q19：刚才还说到了一个主备集群，主备集群现在开源版是支持的吗？因为备库一个是比较浪费资源。另外其实我们如果是 OMS 能支持的话，这个数据同步也不是个问题。比如在单 zone 下从业务角度来讲，可能是需要这样一个保底的东西。
A：主备库开源版现在是不支持的，后面可以用 OMS 来做 OceanBase 到 OceanBase 的同步。
关于社区版与企业版差异
Q20：企业版和开源版，有哪些功能差异是比较大一些的？
A：
1、差异大的主要是 MySQL 模式，社区版是没有 oracle 模式的。
2、企业版会有一个向量化引擎，它在做复杂查询的时候能力会强很多。
3、有一些安全的功能，社区版是没有的。
4、存储过程，存储过程比较复杂，oracle 上的存储过程特别多，这一块也没有开源。
关于 AP 能力
Q21：引擎的现状，今天介绍的是开源版本的，它有没有一个 AP 引擎偏 AP 类的。那么现在开源版本是轻微AP，重 AP 支持不了吗？还是说这个功能没有好一些？
A：OB 的 AP 性能是大幅领先 MySQL, 只不过比商业版是要慢一些，因为 OceanBase 本身是行列混存的，它其实对 AP 的能力天生就有一定的支持能力。二是 OceanBase 是分布式的，分布式对 AP 也是有一定的支持能力，相当于传统的集中式的数据库，这个 AP 能力支持也还可以。
关于异地双活
Q22：OceanBase 和 MySQL 之间的数据双向同步或者双活怎么实现？比如迁移的时候，可能是通过 OMS 去迁移的。迁移之后如果回退，可能想 OceanBase 接一份流量，然后 MySQL 接一份流量。
A：OceanBase 和 MySQL 的双向同步或者双活功能已经开发完，很快就可以对外使用。
关于压测性能
Q23：前段时间我们开发给了个语句，用 MySQL 做压测的时候发现数据量上2亿以上就会很慢很卡。这种情况用 OceanBase 的话会提升多少？
A ：跑一下数据试试，两亿的数据量在 OceanBase 里面算是一个比较小的。OceanBase 有几个能力可能会帮助比较大，一个是分布式的，可以利用多台机器的计算能力。而且在单机上面，你可以通过加的 hint 方式来开启并行执行。也会把单机能力也尽量用起来，比较大的查询会有提升。
关于硬件配置
Q24：关于硬件配置，因为客户可能会选择云主机或者物理机，涉及到不同的芯片、内存或磁盘，希望给一个基准的配置和它对应的测试指标，比如什么业务场景适合用什么样的硬件去支撑？像 TPC 应该有个什么样的标准测试。
我们现在客户选用的是云主机，底层存储是用的是 sata，结果这个写入的性能不是很理想，导致这个体验不是很好，客户想知道到底用什么样的硬件能够达到业务场景的目标，未来怎么去设计？硬件怎么去采购？
A：需求安排上。
关于 TP 与 AP 场景自动调优
Q25：有些场景是TP 和 AP 的混合场景，有些参数还是不一样，我看文档上面有推荐配置，如果说每一个系统都要去调，每个指标都要去调，其实还是蛮专业的。希望有个一键切换，切换成 AP 模式者 TP 模式，会更好用一点？
A：需求安排上, 后续可以在 OCP 里面做模版。
关于多盘挂载问题
Q26：多盘符挂载的问题，客户有的时候会有多个盘，磁盘扩容或是多个盘这种情况，有没有可能支持多盘符？有些盘是 SSD 的，有些盘是 HDD 的，混用在一起，主要是 AP 场景，不知道 TP 会不会遇到，但在 AP 场景就会遇到这种情况，些地方可能磁盘容量大，但这个速度不一定快。有些盘是我们来加速的。当然得基于 OceanBase 的规划，看内核这一块有没有这种考虑。
A：需求评估中。
关于跨租户查询分析
Q27：有这么一个 AP 场景，在 OceanBase 里面数据分散在不同的库或者租户下，但是分析的时候牵扯到数据的聚合，这块有没有好的办法实现？
A：有个办法可以在租户里面用 DB link ，然后去查另外一个租户，可以这么干。
Q28：这么做之后 OceanBase 对多库或者不同实例联邦查询有没有优化，比如很多时候连接管理会牵扯到一些账户体系，包括像PG，PG有1个 FDW 的套路，可以进入 FDW 串其他的库，比如串个 SQL server，串个 oracle，串一块儿这种场景。而且理论上是不是也会有类似优化，下推。类似于 principle 一个产品引擎特别像那种套路。
A：可以提个需求。
Q29：4.0版本发布，可以租户级别的合并吗？因为现在多租户部署，触发合并是所有租户都会受影响。
A：需求已经在计划中。
关于 AES 加密函数
Q30：AES 函数支持吗？我们有个需求，像身份证、手机号一些关键的信息要
脱敏，脱敏保存有加密函数，不允许明文弄了存在数据库，目前 OceanBase 有没有这
一块的功能？因为做密码这一块，一个就是用炼石这种去脱敏，在传输过程加密。另一个就是用 MySQL 自带的函数去进行脱敏，函数是一方面，我们也有应用层
面的一个脱敏，给用户显示的是脱敏字段
A：商业版支持，社区版没有。提个需求, 这个函数其实比较容易。
思考
当前我们在做 OceanBase 4.0 ，会支持很小的使用规格，非常接近 MySQL ，可以是单机版，可以是主备的。换个角度，大家在 MySQL 这种小实例上有没有什么具体的问题或者具体的痛点？然后我们可以在 OceanBase4.0 里把这些东西做进开源版本里，让大家用的爽一点。比如说会把 online DDL 给放进去，会提供一些比较强的 AP 上的查询能力，会不会对大家的业务上会有一些帮助？欢迎大家留言讨论。
感谢所有参会老师（排名不分先后）：毋庸、3陈奕凝爸爸、卓望安全齐先生、Richie、Roy、3fong、138****6649、hindley、typhoon、蒋力、李炳通、刘启武、罗呈祥、饶辉、童小军、筱虫、肖赞、陈晓松、黄罕栋、荣锋亮、陈尧、蒋军云、陈阳、王武功
