编者按：好未来作为国内领先的教育科技企业，旗下业务众多、数据海量，底层数据系统涉猎MySQL、Redis、MongoDB、Pika、RDS、PolarDB、CDB、TDSQL-C等，以及采用阿里云、腾讯云、百度云等多云架构。迫于分库分表的困境，以及资源隔离与资源碎片等痛点，新增OceanBase技术栈以解决问题。部分业务试点OceanBase后，提升了可用性与资源利用率，降低了运维复杂度并带来额外的成本效益（自建服务降本50%、云上服务降本40%）。好未来数据库专家王新然分享了这一过程中的经验和思考。
业务背景：为何考虑选型OceanBase
好未来是一家以内容能力与科技能力为基础，以科教、科创、科普为战略方向的教育科技集团，使命是通过爱和科技助力人的终身成长，愿景是成为持续创新的组织。公司旗下有学而思素养、学而思网校等传统的教培品牌，推出了科学、人文、科技智造等丰富的素质类课程，同时，通过科学创新研发了一系列智能硬件与软件产品，如学习机和智能教辅等。此外，公司也在AI领域不断深耕，于今年推出了自研的数据领域大模型MathGPT，欢迎大家使用。
由于集团业务线丰富，每个业务线会根据自己的实际业务场景做数据库选型，因此集团的数据库服务是以混合云的模式对内部业务提供的。我们既在IDC内自建了大量的数据库服务，也使用了多家云厂商提供的各类数据库产品，涉猎的数据库种类还是比较广泛的。
在使用了如此多的数据库产品之后，我们为什么还会继续考虑选型OceanBase？
有三方面原因：
第一，自建服务中有大量的MySQL服务，MySQL作为传统的单机数据库，它的性能和容量很容易达到瓶颈。同时传统的基于中间件的分库分表解决方案对分布式事务的支持不友好，同时还会增加运维侧的复杂度。
第二，传统的数据库都是通过单机多实例方式部署的，缺少资源的隔离能力，会为线上业务的稳定运行埋下隐患。同时由于管控面对的是非常零散的物理机资源，且对资源的申请和回收只是在元信息层面修改，势必会产生大量的资源碎片。
第三，目前的资源部署模式不具备可弹扩能力，资源在分配时都会留有较大的冗余，导致整体数据库服务资源利用率比较低，资源浪费严重。
那么， OceanBase能够全面帮助我们解决这些痛点吗？
数据库选型：OceanBase方案探索及验证
选型一个新的数据库时，我们主要关注以下四个方面的能力：
- 架构设计，这决定着数据库的性能和容灾能力。
- 多租户，帮助我们实现资源隔离及资源弹扩。
- 数据压缩，帮助我们获得额外的成本收益。
- 生态工具，帮助我们以最小的成本构建新的数据库运维体系。
1、架构设计。
这是OceanBase4.0之后的架构图，具备以下特点。
1）多副本：一般部署为三/五个 Zone，每个 Zone 由多个服务器节点（OBServer）组成。
2）对等节点：每个节点均有自己的 SQL 引擎和存储引擎，自主管理各自承载的数据分区，TCP/IP 互通，协同服务。
3）无需存储设备共享：数据分布在各个节点上，不基于任何设备级共享存储技术，不需要SAN 网络。
4）分区级可用性：分区是可靠性与扩展性的基本单元，自动实现访问路由、策略驱动负载均衡、自主故障恢复。
5）高可用 + 强一致：多副本 + Paxos 分布式协议的高效高可靠工程实现， 确保数据（日志）持久化在多数派节点成功。
OceanBase的单机分布式一体化架构，能够让业务的大部分请求在本地作为单机事务来执行，避免了分布式事务带来的消耗。同时。如果对可用区或zone设置优先级，甚至能让一个租户所有的请求都转变为单机事务在本地执行。这种性能上的优势对于业务来说，非常有吸引力。
2、多租户能力。
OceanBase提供了原生的多租户能力。支持租户单独配置数据副本数量、副本类型、存储位置及计算资源等；支持单个租户的动态扩缩容，在线扩展，在线调整配置。集群内部提供自动化的运维手段。这样保证了租户之间的资源完全隔离，同时租户之间数据也是相对安全的，能够帮助我们解决线上资源混合的风险。
3、数据压缩能力。
OceanBase提供了非常高级的数据压缩技术，让我们在选择OceanBase时，除了能够解决性能和可用性的相关问题，还能获得不错的成本效益。这主要得益于以下三个关键技术。
1）基于数据变长-定长的存储压缩技术：通过使用压缩率较高且解压缩较快的压缩算法对数据进行压缩，提高数据压缩倍率，减少数据的存储成本。同时由于 LSM-Tree 的结构特性，采用读写分离设计和行级细粒度记录更新，变更数据保存在内存中，并批量写入磁盘。因此能达到内存数据库级写入性能和磁盘数据库的存储成本，并消除了传统 B+Tree 的磁盘随机写瓶颈和存储空间碎片化问题，使得数据写入性能比传统的实时更新数据块的方式更高。
2）基于数据编码的存储压缩技术：采用行列混合存储格式，磁盘数据块按列组织，自研一套对数据库进行行列混存编码的压缩方法（encoding），使用行列的字典、差值、前缀等编码算法，在通用压缩算法之前对数据做了编码压缩，从而带来更大的压缩率。
3）基于数据日志分离的低成本存储技术：传统的 Paxos 协议中，系统需要三个副本（或五副本），OceanBase 数据库将用户数据和日志数据分离，比如日志数据基于 Paxos 协议使用三副本（或五副本）存储， 而用户数据本身可以使用两副本（或三副本、四副本） 进行存储。在保障相同可用性前提下， 数据日志分离可节省 20%-40% 的用户数据存储成本。
此外，OceanBase还具备以下优秀特性：动态修改写内存、静态数据无修改、支持高压缩数据的批量写、数据强一致性校验、对 SSD 十分友好的无随机写等。
4、生态工具。
除了内核能力十分强悍外，OceanBase还提供了非常丰富的生态工具，涵盖了服务运维的全生命周期，比如评估改造、实时迁移、开发管理、生产运维、复制订阅、安全管控、诊断自治。借助这些强大的工具，可以让我们以非常低的成本完成OceanBase运维体系的搭建。
其中，我们使用最多的工具是OCP（OceanBase Cloud Platform）。通过OCP，我们日常运维的大部分操作能够实现白屏化，比如创建集群、新增可用区、新增租户等操作，只需在OCP的页面上通过点击按钮即可完成，整个过程十分简便且可靠。同时，OCP还提供了监控报警、性能分析以及数据备份等功能，使得OceanBase的运维可以变成一件简单而愉快的事情。
此外，我们也关注到OceanBase对MySQL生态也提供了良好的支持，在MySQL 兼容模式下，通过Binlog Service可以将 OceanBase 的日志转换成 MySQL Binlog 的格式，实现对 MySQL Binlog 协议的全面兼容。业务可以继续使用MySQL生态下的数据同步工具完成相关数据的订阅任务，极大降低了业务的改造成本。
经验总结：OceanBase使用感受及建议
介绍完OceanBase特性后，现在看一下OceanBase在实际生产过程中的表现如何。
我们对比了OceanBase（3个 Zone，每个 Zone 为 4C+16G）和目前已使用的某云原生数据库（1主2从，每个实例 4C+16G），经过测试发现：
- 在数据压缩方面，我们将云原生数据库迁移到OceanBase后，数据由4.2T压缩到了1.9T，压缩比达到了10:4.5。
- 在性能方面，在4C16G并发数比较小的情况下，OceanBase未体现性能优势，但随着并发数的增加，尤其是超过56个线程后，OceanBase性能优势体现了出来。
我们又将OceanBase（3个zone，每个zone为24C+96G）和MySQL服务（1主2从，每个实例24C+ 96G）进行了对比：
- 数据压缩方面，OceanBase将MySQL 413GB的数据压缩到了125GB，压缩比达到10:3。
- 性能方面，在并发数比较少的场景下，OceanBase和MySQL的性能基本持平，当并发数超过40，OceanBase性能优势显著。
目前，我们已完成OceanBase在部分业务线的试点工作。在自建服务方面，我们用OceanBase的社区版替换了原来使用的云原生数据库，实现50%的存储成本节省；在公有云方面，将原业务下分散的RDS实例以租户的方式合并到一个大的OceanBase集群，同时将磁盘使用量特别大的云数据库实例迁移到了OceanBase。通过实例合并和数据压缩，实现40%云上的成本的节省。
此外，在好未来升级至 OceanBase 的过程中，也有几点关于集群部署的建议供参考：
建议一：使用OCP部署线上环境。我们最开始部署时使用了ocp-express，它能让我们快速部署OceanBase集群，但它缺少了一些管控能力，因此不能满足线上运维的需求。如果这时再想把集群从ocp-express转移到OCP托管，过程比较复杂。
建议二：OCP 使用的 OceanBase 集群要单独部署，因为OCP本身有数据存储需求，如果OCP和业务使用一个OceanBase，那么当业务OceanBase出现问题，想通过OCP做止损操作时，会发现OCP也无法登录。
建议三：部署集群时要手动设定以下参数的值： log_disk_size、datafile_size 及 memory。否则OCP会使用默认值做分配，基本会占用整机90%的资源。如果整个集群上还有别的服务在运行，就非常容易出现内存或磁盘打满的问题。
后续规划：探索OceanBase HTAP能力
以上就是好未来对OceanBase从调研到上线整个过程中的经验和思考。总体而言，OceanBase不仅解决了存储和性能的瓶颈问题、资源的隔离和弹扩问题，还带来额外的成本收益，并降低了运维的复杂度。未来我们将持续扩大OceanBase在各业务的应用范围。
在自建服务方面，目前我们已将OceanBase做为新的分布式数据库选型，并打算在核心业务中进行推广，希望借助OceanBase的多租户能力解决业务以往的可用性问题。同时，积极探索OceanBase的HTAP能力，希望借助OceanBase的OLAP的能力解决单份数据多处存储的成本浪费。
在公有云服务方面，我们将继续推进零散的RDS合并至 OceanBase的工作，同时将云上大体量的数据库迁移到OceanBase，通过对资源的合并和超卖，以及对存储的高度压缩，进一步节省云上成本。
