度小满列举五大技术场景拆解数据库选型方案，降本、性能、效率均翻倍

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

本文整理自6月21日“OceanBase 城市交流会 · SQL 遇上 AI ”《度小满 × OceanBase 实践：统一架构驱动效率与成本双突破》，点击链接可观看视频回顾。

作者：赵辉，度小满技术委员会负责人
度小满，原百度金融。2018年4月，百度宣布旗下金融服务事业群组正式完成拆分融资协议签署，实现独立运营。作为一家金融科技公司，度小满充分发挥百度的AI优势和技术实力，携手金融机构合作伙伴，用科技更好地提供金融服务。本文介绍度小满业务高速增长背后，面临的存储挑战与数据库解决方案。
四大成本优势决定数据库选型结果

度小满金融业务规模的高速扩张，使存储需求呈指数级增长。那时，底层的数据库方案面临数亿用户的高并发交易、毫秒级实时风控决策、高吞吐变量数据写入，以及报表分析的极低延迟的挑战。经大数据部门的深入分析，存储架构存在五个方面的问题，导致其很难面对上述挑战，持续支撑业务需求。
其一，度小满自研技术栈多，比如关系存储类DDBS、KV存储类的CKV、稀疏海量存储类的Eggroll、等等。对于一线开发人员来说学习成本较高，需要对接并学习多种用法，开发和对接效率有待提高。
其二，资源成本高，主机规模大，主从备架构部署冗余，存在多个小集群，导致存储成本高、CPU利用率低、资源难复用。
其三，一些业务操作如流量切换与屏蔽、数据均衡操作、扩缩容操作复杂，且对业务不透明，需要多方配合，执行周期较长，部分场景更是需要方案定制。
其四，存在可用性风险，所有类型的存储引擎在全场景下，比如进程挂起、硬件故障、机房故障、地域灾难等场景，难以达到9999的SLA。
其五，工具生态欠缺，工具自动化，尤其是产品化程度较低，运维效率有提升空间。
针对业务需求及原本数据库方案面临的困境，我们决定重新选择一款既满足业务需求又可以统一当前所有技术栈的产品。那么，为什么最终选择OceanBase呢？
经过前期对多款数据库在迁移成本、资源成本、学习成本、运维成本等方面的调研，我们发现 OceanBase 非常符合我们的选型需求。
1.迁移成本低：兼容 MySQL 和 Redis 协议，迁移过程平滑无感。
为了实现底层架构栈的统一，我们替换数据库方案面临的第一个要求就是迁移成本不能过高，否则将会面临较大的业务阻力。由于 OceanBase 兼容 MySQL 和 Redis 协议，整个迁移过程非常平滑，几乎没有改造，我们投入的人力、时间都较少，对业务有正向收益，因此，间接降低了整体的迁移成本。
2.资源成本低：引擎执行高效，TPCC 刷榜世界纪录，超高压缩比。
OceanBase 有世界领先的计算执行引擎，曾打破 TPCC 世界纪录。而且，极致的数据压缩比在业内闻名，相比传统数据库 MySQL，能够实现几倍的存储空间节约，极大地降低了企业的存储成本，带来显著的资源利用率提升。
3.学习成本低：支持关系/KV /向量等技术栈统一，多种部署架构的运维方式统一。
如上文提到的，我们的多种技术栈及组件给一线的开发人员和运维人员带来了极大的学习成本，OceanBase 用一套引擎就可以解决关系型数据、KV、向量等多种数据类型的存储及计算，满足所有业务场景的需求，极大降低了学习成本，提升了运维效率。

<strong>4.运维成本低：支持机房地域级的容灾，RTO