业务背景
“综合执法监管”是国务院深入推进“放管服”改革的重大部署，需要依托国家政务服务平台建设“互联网+监管”系统，从而强化对地方和部门监管工作的监督，实现对监管的“监管”。
随着业务运行的时间越来越长，我们内部系统的存量数据越来越多，数据规模越来越大，处理速度渐渐跟不上业务需求，这也使得我们更加坚定不移的优化数据处理架构，提高平台监管效能。
选型考虑
本次的测试对象是我们内部的大数据处理平台，平台数据来源于多个项目业务，使用的产品有PostgreSQL、Spring Boot、Redis。其中Redis 接口作为读缓存，使用内部工具做数据治理例如格式校验、限制字段写入等。大部分数据最终都会存储在PostgreSQL，每月数据会有4～5亿的增长，随着使用时间越来越长，PostgreSQL渐渐无法满足需求。表现有如下痛点问题：
- 某些操作执行性能渐渐无法满足需求，例如某些带索引的删除操作，耗时较长且不生效，最终会卡住，调优方面有些吃力。
- 其次物理机扩容局限很大，随着数据量越来越多，后期PostgreSQL集群扩容上限有限制，物理机能加的都加满了，但仍满足不了业务的查询需求。
- 调优方面有些越来越吃力，部分服务只能迁走，这也导致系统运维调优投入的人力越来越少，性能越来越差。
- 数据库升级需求、查询速度严重影响多个系统正常运行、PostgreSQL运维团队离场等多方面因素使得我们需要寻找一款扩展性好、性能强的产品解决目前使用场景的一些瓶颈，同时我们也听说OceanBase性能、扩展性、压缩技术、安全容灾能力等很不错，在今年初主要进行了兼容性测试和业务压测。
测试过程
我们的数据是各个业务系统通过ETL工具（数据治理工具）写入到PostgreSQL、mysql，首先我们将之前的业务数据通过ETL工具（数据治理工具）写入到OceanBase，在兼容性方面，PostgreSQL和OceanBase的语法不完全通用，主要做了PostgreSQL到mysql的语法、字段类型准换，字符集问题暂时没遇到，部分函数例如OVER(PARTITION by xx) 在OceanBase是兼容的，大部分应用、统计、接口都需要做改造，目前测试的不是很多。
业务压测方面，我们主要测试的是一个数仓场景，数据量有13亿，平均每小时进行数据更新插入的数据同步任务，基于etl功能+上质检功能在接口平台使用OceanBase数据源做了接口压测。该场景下，我们在数据原始层不做修改，清洗层生成一个质检状态字段，把不符合的单独抽取出来。在PostgreSQL中五张表合成了一个作业，在我们平台的运行时间是2小时30分钟17秒，使用OceanBase后，分成了多个同步作业，用时共计58分钟38秒。
PG
OB
如以下相同的一条SQL，在OceanBase查询是0.427s，在PostgreSQL是0.716s。
运行总结
通过测试验证及结合试运行表现来看，OceanBase在查询效率、安全稳定性、高数据量查询等方面基本满足我们的现有业务场景，解决了大表查询效率低下、数据更新效率慢的历史问题。其次多租户能力在业务中很实用，我们后续也计划把多租户能力引入其他业务。运维方面，OCP云平台功能丰富、数据展示直观，其中资源使用情况展示和监控预警功能很不错，大大提高了运维的便利性。作为一款准内存性数据库，查询效率比传统数据性能高太多，多副本能力安全性稳定容灾能力强，数据压缩这一块的高压缩比很大的节省一部分资源成本。
当然，在替换测试过程中也发现了部分问题，我们的测试版本是OceanBase v 3.1.4，在兼容性方面，部分存储过程不适用，需要进行改造。部分语法函数不通用，数据迁移到OceanBase过程中需要转成相应语法函数，部分还需要更改旧的实现方式。工具方面，我们使用环境使用Navicat 16较多，兼容性尚有欠缺，比如使用Navicat创建存储过程，首次创建没问题，再次去修改就报错，只能每次重新删除重建，修改日期这部分就无法使用。
最后，非常感谢OceanBase社区团队在我们测试过程的支持和响应，也希望我们的分享对其他使用PostgreSQL的社区小伙伴带来一些参考。同时我们希望OceanBase研发团队可以丰富OCP的更多功能，将目前需要服务器完成的事项添加在OCP平台，使得OCP成为运维功能更加集成全面的一站式管理平台。
