技术升级，实现降本增效、高可用、高可靠
1.极致降本：LSM-Tree 引擎对海量数据的存储重塑
使用 OceanBase 后，告别了传统 MySQL B+ 树的页分裂与空间碎片，采用 LSM-Tree 存储引擎将随机写转化为顺序追加写，实现极致的写入性能与双层数据压缩。89TB 的数据被压缩至 29TB，存储空间节约 67%。
业务场景一：历史存量业务 (冷热分离)。存量数据的日常访问频次极低且无法下线，占用着大量昂贵的 SSD 存储资源。我们考虑将部分数据切换到 OceanBase，利用其极致压缩能力将海量数据在线归档。在不影响偶尔查询的前提下，大幅削减硬件成本，实现“冷热数据”高效治理。
业务场景二：营销投放业务 (高频并发)。这是一个典型的写密集型业务，流水产生极快，且因合规与对账要求，保留周期极长，极易引发容量危机。在 MySQL 分表方案中，每台机器配置两块数据盘，使用压力经常达到 85%。
DBA 需要频繁做归档和表空间收缩，运维压力很大。OceanBase 采用 LSM-Tree 架构，增量数据写入后通过定期合并完成空间回收，无需手动收缩，整体运维压力大幅降低。
值得一提的是， OceanBase “内存追加写”特性完美消除高频写入的 I/O 瓶颈，底层高压缩比彻底瓦解长期保留的容量焦虑，让业务敢于记录详尽流水。
业务场景三：同城双活演练。我们每年进行两次同城双活演练，两个机房之间将流量和数据库全部切换。
备租户 (Standby Tenant) 容灾体系。打破传统主备架构局限，基于底层 Redo Log 异步/强同步传输，实现跨机房的“租户级”物理容灾。无论遭遇多极端的机房级故障，坚守底层数据零丢失的绝对红线。
“切浦江”常态化双活演练。告别纸上谈兵，将主备角色平滑互换演练融入日常运维。结合业务流量管控与紧急回滚预案，验证全链路可靠性，确保极端场景下核心交易流量接管无感丝滑。
在演练过程中，MySQL 及其他关键数据库会出现抖动，对业务有一定影响。公司管理层也在关注如何将切换影响降到更低、更平滑。OceanBase 的架构天然适配这一需求，通过 OBProxy 和 Service 层访问，切换更加丝滑。如果线上核心业务使用 OceanBase，强烈建议配置 OBProxy。
3.资源池化与多租户架构：打破物理孤岛，实现极致弹性
业务场景四：多租户资源隔离。很多 DBA 在银行类金融场景下按需开机器、部署交付即可，但需要思考成本与交付的平衡。
当前的痛点是：研发强调业务重要，要求独立资源。我们目前采用物理机部署，对于业务压力并不高的“核心”业务，只能给三副本 5TB 存储，造成资源浪费。同时，多条业务线部署在同一组物理机上，某个业务线的慢查询接口可能影响其他业务。
OceanBase 的多租户能力可以解决这一问题。
· 告别物理机孤岛：打破传统架构按“峰值”预占硬件的痛点，实现资源池化管理。按需动态分配 CPU/内存，彻底消除物理机闲置造成的成本浪费。
· 租户级物理硬隔离：通过底层的 CPU 绑核与 IOPS 阈值控制，实现租户间的物理级硬隔离。确保营销等高 I/O 业务突发打满时，核心交易链路绝对不受“噪音效应”干扰。
· 分钟级动态扩缩容：以 Unit 为最小迁移单位，实现业务零感知的在线扩容与缩容。轻松应对跨地域、多时区的突发业务洪峰与节假日高并发。
使用 OceanBase 后，整体资源利用率提升 40%，新业务节点部署周期缩短 90%。此外，对于如何避免资源浪费问题，我们在早期采购机器时得到一个经验：CPU 核数买得太少，存储配置较大，导致 CPU 资源用完后仍剩余大量存储空间。建议采购时选择高 CPU 规格（如 96C），与内存配比大约 1:2。迁移单位，实现业务零感知的在线扩容与缩容。轻松应对跨地域、多时区的突发业务洪峰与节假日高并发。
自动化运维与生态打通
将新数据库纳入既有运维体系是一个常见问题。信也科技数据库种类较多，包括 MySQL、Redis、OceanBase、Elasticsearch 等多种关系型和非关系型数据库。我们有一套面向研发和 DBA 的管理平台，已将 OceanBase 的自动化流程纳入其中。
在 SQL 变更方面，我们采用双重验证机制：通过 OCP 平台和内部工具进行交叉验证，确认无误后直接执行；如有风险则走工单审批流程。但工单执行也存在问题——大表改表操作耗时非常长，业务方能否等待是一个问题，同时改表过程中本身存在锁开销等风险。
我们的做法是安排在每天 21 点执行，如果到早上窗口期结束仍未完成，则进行抑制操作，暂停 DDL 避免影响业务。
在开发平台方面，我们参考了阿里云的建表体验，将开发规范内置到平台中，研发人员无需关心索引、表备注、字符集等规范细节，只需填写表名、备注和字段类型，提交后平台自动处理。
一个重要的经验教训是：早期未配置 OBProxy 时，在大数据抽数场景中，复杂查询任务直连主租户 (Primary Tenant)。凌晨抽数高峰期引发大面积全表扫描，导致主库 CPU 飙升、I/O 触及瓶颈，严重威胁核心交易链路安全。后来我们将所有离线抽数、报表分析流量无缝引流至备租户 (Standby Tenant)，彻底实现底层读写分离，物理隔离 OLAP 与 OLTP，主库性能稳如磐石。
