2019 年 10 月 9 日，某部委人士在公开会议上指出， “ OceanBase 测试指标虽高，但在关键领域仍不能使用” 、“ 互联网和银行场景完全不同” 、“ 不能支持跑批（批处理业务） ” 。问题本质是 “ 什么样的分布式数据库在关键领域可用 ” ？
从用户的角度，答案很明确，兼容Oracle 功能且满足性能要求。兼容Oracle ，意味着“ 不改造应用系统无缝升级模式” ，用户责任小，风险低。满足性能要求，意味着业务可运行。
那OceanBase 是不是这样一个产品呢？
先说Oracle 的兼容性：
数据库核心功能，OceanBase 在分布式架构下，不兼容Oracle 的存储过程、触发器、视图、多表关联、大表关联等常用数据库核心功能，需要通过大规模改造应用系统来弥补功能缺口，工程繁复，且不保证改造一定成功；
隔离等级，OceanBase 不支持Oracle 的隔离等级“ 可重复读” ，存在不可知数据错误风险及高失败率；
锁机制，和Oracle 严苛锁机制相比，OceanBase 是松散锁机制，在有数据冲突的金融场景，必然导致跑批（批处理业务）中断，存在业务连续性风险；
结论， OceanBase 完全不兼容 Oracle ，其缺口源于结构性差异，不可能通过适配解决 。
再说性能，分布式数据库性能的关键是处理分布式事务的效率：
两次tpc-c 测试，分布式事务均不是由OceanBase 数据库完成的。按tpc-c 规则，存在随机15% 和1% 跨仓交易，如果完全随机，总交易量的6.896% ，即8 小时共有520.017798 亿个交易，成为跨数据库节点的分布式事务。蚂蚁金服披露“OceanBase1557 节点集群时，压测tpmC/ 理论tpmC=0.987” ，集群与单机相比性能0 损耗，即分布式架构却完全没有分布式开销，显然 tpc-c 测试里的分布式事务不是由 OceanBase 数据库节点完成的 。
2019 年6 月，中国信通院和中国软件评测中心搞过一次分布式数据库的公开摸底考试，不允许大规模修改应用系统，OceanBase 性能不佳，没有进入复试。
支付宝场景，有专业人士认为：“ 网络支付场景，更多是连接，而资金的清算早期在商业银行，现在在人行网联平台，而非支付公司。相反，说明银行的核心系统大有进步。” 支付场景与金融场景差异明显，OceanBase 分布式事务能力仍需证明。
OceanBase 多个外部测试场景，目前均未见到OceanBase 单独完成分布式事务，更多是由应用系统分担，OceanBase 作为数据存储。
高斯分布式数据库与OceanBase 同属一类，实战效果不佳，已下架。
小结， 没有直接证据证明 OceanBase 分布式事务处理性能 。
综上所述，OceanBase 完全不兼容Oracle ，分布式数据库性能尚待证明。结构上更像是一个数据库存储而非完整数据库，就像没有发动机的裸底盘，替换高端整车Oracle 缺乏理论支撑和实践证明。
以上观点均可快速验证 ，当众迁移一简单Oracle 系统即可，如某标准OA 。
转自：新一代分布式数据库技术（ https://mp.weixin.qq.com/s/rRDYNW98DyQhAAb6bSydSw）
