上海芯赛云计算科技有限公司（以下简称芯赛云）成立于2021年，是一个成长初期的云计算公司，以公有云业务为使命，致力于“让用户像使用电一样便捷地使用云服务”。因此，在研发层面，我们专注于云计算、云存储和其他云产品的研发工作，数据中心设在上海、常州、广西这三地。
在这样的业务背景下，公司存在多个云产品线和研发环境，每个业务研发团队都申请专用的数据库服务器，还需要自己管理，导致没有统一的运维管理平台、数据库版本管理不一致，以及出现服务器资源占用多、资源浪费等问题。
为了节省资源成本，提升资源利用率，实现数据库版本的统一和运维管理，以及支持后续业务线上高并发场景的需求，我们开始了数据库选型。
分布式数据库选型及产品对比
在数据库选型中，我们考虑了传统的集中式数据库方案，但结合以下三点云计算平台特点，发现其扩展性、性能、运维等不足以支撑我们的业务。因此，我们将目标转向分库分表方案和已经趋于成熟与稳定的分布式数据库。
- 云产品众多，产品线不断扩展。
- 访问量大，海量数据增速快。
- 层级复杂，涉及多种逻辑和调度。
在云计算平台研发初期，我们基于MySQL数据库并考虑使用ShardingSphere-JDBC做分库分表方案。主要因为ShardingSphere-JDBC是一种轻量级Java框架，以jar包的形式提供，支持分库分表、读写分离、跨库Join/分页/排序、XA事务、柔性事务（最终一致性）等功能，是比较成熟方案。它的优势在于突破了单一数据库的负载上限，提高数据库的整体性能和扩展性（数据分散存储），但是，所有分库分表方案都有共同的缺点：
- 拆分后业务的清晰度降低，运维变得复杂。
- 需要考虑和维护分库分表的规则。
- 一般需要研发介入。
放弃集中式数据库方案和分库分表方案后，我们比较了国内较为前沿的几款分布式数据库产品，分别是TDSQL、TiDB 、OceanBase。测试其存储架构、数据结构、数据一致性、高可用和运维复杂性。
从对比结果来看：
- 在存储架构方面，TDSQL、TiDB 采用 KV 形式的底层存储引擎， OceanBase 是完全自研且具备行列混合存储模式和数据高压缩率。
- 在数据结构方面，OceanBase 和 TiDB 都采用了类似的 LSM Tree，而 TDSQL 采用了 B+Tree 加速模式。
- 三款数据库都支持强一致性，只是协议不同。但在多租户方面，OceanBase 更加方便使用和管理。
- 三款数据库都实现了高可用自愈功能，并且具有一定的兼容性。
最终，我们选择了 OceanBase ，这取决于以下五个因素。
第一， OceanBase有蚂蚁集团背书，稳定支撑9年“天猫双11购物节”和支付宝核心业务。
第二， OceanBase生态工具丰富，自研工具OCP、ODC、OMS等操作简单、易于维护，还集成了400+上下游生态伙伴。
第三， OceanBase的租户通过资源池、资源规格，来划分CPU/MEM/IOPS。所以我们按业务+平台的层级来划分租户，保证了各个业务线的资源使用不会相互影响，同时方便运维、备份恢复等。
第四， OceanBase 的扩展性良好，支持集群级别的扩缩容和租户内的资源扩缩容。
- 集群级扩缩容
- 物理机-observer
- 可用区zone动态调整
- 租户内资源扩缩容
- 水平扩缩容 – 调整资源池 unit_num 数量
- 垂直扩缩容 – 调整资源规格 unit_config
而且，可以通过添加服务器和调整资源规格来实现水平和垂直扩容。扩缩容的运维操作非常简单
第五， 在业务侧， OceanBase提供了副本读的功能，避免读主副本的压力。使用上非常简单，可以在Session级别上设置，也可以在SQL级别上增加hint。
#session 级别设置系统变量（1=FROZEN、2=WEAK、3=STRONG）
SET @@ob_read_consistency= 2;
#SELECT 查询语句添加 hint
SELECT /*+read_consistency(weak)*/ * FROM test WHERE c1=1;我们有两个读实时性要求不高的场景使用了弱一致性读 。
第六，OceanBase是首个提出三地五中心容灾解决方案的数据库厂商，拥有全球领先的 RPO = 0，RTO 小于8秒故障自动恢复能力。我们采用了2-2-2的三副本模式，副本间通过Paxos协议保证一致性。同时，通过机柜级容灾来实现容错性，使用OBProxy的无状态特性通过VRP控制应用指向，实现了高可用性。
总的来说， OceanBase满足我们的业务需求，拥有良好的性能、可靠性和扩展性，简化了运维复杂度。
应用收益及部署问题总结
应用收益
目前，我们已上线OceanBase 4.1.0.1版本，用于云计算平台后端数据库、支持跨地域的数据中心。由于每个数据中心规模较大，考虑到网络延迟问题，各个数据中心独立部署。控制层数据集中存储，集成层数据分散存储。
使用OceanBase后，我们节省了大量的服务器资源，由原本使用十几套MySQL数据库集群，到现在使用一套三副本的OceanBase集群，并极大地降低了运维成本。当然，得益于OceanBase极致的数据压缩率，我们的数据容量占用降低了近70%。尽管 OceanBase 只将数据写入一个目录，底层存储需要自行实现高冗余能力，考虑到 OceanBase 自身的三副本能力，因此不希望在磁盘级别做高冗余。我们选择了 read 0 架构，这样数据存储只需存储一份，进一步降低存储成本。
部署问题总结
在上线初始阶段，当我们把 OceanBase 集群部署在虚拟机环境时，发现每天早上集群都不可用，需要重启磁盘，但重启耗时很久。我们分析其中的原因，发现底层存储在夜间23点到早上6点做数据校验，而OceanBase租户合并的时间在凌晨2点，同时OCPExpress也在夜间处理很多指标数据。因此，夜间对外提供的 IOPS 极低，同时磁盘 I/O 降低，影响OceanBase集群的性能。在对OceanBase和OCPExpress分开部署，同时分散OceanBase租户合并时间，避免与底层存储数据校验时间重叠后，问题得到解决。
部署单机模式时，我们也遇到了一个小问题。即Meta租户freeze次数非常多。原因是堆栈大小参数的设置不正确，导致租户内memstore的内存被co_stack挤压，而stack_size这个参数会控制co_stack内存占用。例如原来memstore理论有800M，按照20%的trigger freeze比例，应该在使用到160M的时候发生冻结，但现在memstore被挤占到只有30M，那么按照30 * 0.2 = 6M，也就是说。只要有一点数据就会冻结。因此，我们修改了参数文件 stack_size 512k，重启集群后就恢复正常了。
此外，在备份归档时，NFS节点挂载异常导致归档失败。
具体而言，租户 1004 指定时间恢复到新的目标集群，提示归档日志不够，其它租户正常。
MySQL [oceanbase]> ALTER SYSTEM RESTORE xxx FROM 'file:///backup/nfs/xxx/xxx/backup,file:///arch/nfs/xxx/xxx/archive' UNTIL TIME='2023-10-26 13:30:00' WITH 'pool_list=xxx_pool';
ERROR 4018 (HY000): No enough log for restore我们在源集群上发现1004租户的归档状态虽然是doing，但归档时间缺停留在9/12号，这个时间是上次运维的时间。
查看1004 租户日志流：
但只有两个日志流归档进程， 缺少对1002日志流的归档进程：
下面定位1002日志流的leader节点：
登录节点，发现observer.log日志
最后发现 这个节点的NFS目录没有挂载成功。我们的处理方案是先mount上，安装autofs，等待OceanBase 4.2版本支持备份到S3时，进行版本升级。
综上所述，我们通过不断排查和调整参数，解决了一些应用案例中遇到的问题。因此，我们总结了一些注意事项以供参考。
- 建议OCP/OCPExpress和OceanBase不要部署在同一台机器上，如果有最小化部署需求，建议使用MySQL。
- 共享云盘I/O一般都有限制，而且不可控，部署时可能会遇到I/O hung住问题，建议确认IOPS或部署物理机。
- 在备份与归档时，如果必须使用NFS模式，需要使用I/O能力相当的磁盘做为归档磁盘，否则归档进程一直跟不上。
OceanBase正在逐步走向完善，希望后续这些问题都能得到解决。
后续应用规划
目前，OceanBase已在芯赛云稳定运行三个月，我们统一了内部的数据库版本，解决了管理多种数据库类型和版本的问题。此外还实现了超出预期的降本增效的收益，以及获得了方便的动态扩容方案和高并发场景支撑方案，以应对业务需求的增长。
我们计划2024年启用规模更大的数据中心，到时还会部署一套OceanBase集群。此外，由于OceanBase相较于MySQL高可用版的硬件利用率更高，以及运维更加便捷、运维成本更低，我们也将在云平台接入OceanBase。
我们期待OceanBase能够支持多数据目录部署，磁盘级的数据恢复，并尽快支持备份到 S3。也希望OceanBase能够优化磁盘 I/O ，因为OceanBase 4.1在空库状态下，磁盘 I/O 需求比 MySQL 重，从监控看，部分节点大概3-5k的 IOPS，希望OceanBase的磁盘 I/O能接近 MySQL 空库的表现。我们将继续关注 OceanBase 的改进和发展。
