集中式数据库的本质是单机数据库 ， 在互联网日均流量上百亿破千亿的环境下 ， 单机数据库的存储能力都极其有限 ， 更谈不上如何分析、处理数据 。 受限于分布式数据库更加复杂、故障定位更加困难、分布式事务性能有所降低、系统成熟度有所不足等因素 ， 传统数据库厂商选择了“分库分表+中间件”的解决方案 ， 即基于集中式数据库 ， 对业务进行较大幅度地改造和拆解、拆分 ， 使每个拆解、拆分后的部分适合于单个集中式数据库 ， 这就是分库分表数据库 。 这种方式其实是把原来在一个数据库中的大业务拆分为多份小业务 ， 阳振坤称之为“没有大飞机 ， 就分成多份 ， 用小飞机来运” ， 但如果是重装备、重武器如坦克大炮 ， 小飞机装都装不下 。 因此 ， 这终究不是彻底解决问题的办法 ， 而且面临高额的成本和繁杂的运维 。
阳振坤意识到“机会来了！”于是立项 ， “方向和目标是明确的” 。 尽管分布式联机事务处理的开发非常复杂和困难；尽管分布式数据库在SQL优化器、存储架构等方面门槛极高；尽管这个分布式数据库需要长时间的、大量的实际场景打磨；尽管分布式架构与关系型数据库结合 ， 没有任何可参考的先人经验 ，
“我们要做一个大飞机 ， 不管你有多大的业务量 ， 都能用分布式数据库这个大飞机给你运走” 。 当系统容量不受限制的时候 ， 一定能做更多的事情 。 这是阳振坤当时唯一确定的事——价值 。
阳振坤的做事方式是“把事情想清楚再做 ， 做到哪算哪就麻烦大了” ， 只确定目标 ， 如何行动依然是问题 。 好在做分布式数据库需要哪些功能 ， 其实不用发愁 ， 有现成的如MySQL、Oracle等成熟的开源和商业数据库 ， 功能早就定义好了 。 也就是说 ， 创建分布式的环境 ， 用多台机器 ， 参考成熟数据库已有的功能列表 ， 实现分布式数据库 。
但对于数据库这种基础软件而言 ， 尤其是与传统集中式数据库架构完全不同的、新型的分布式数据库 ， 绝不是把架构搭建好、代码写出来就能应用在业务中的 。 而是得从一个个具体的业务开始 ， 针对它做基础功能 ， 满足其基本业务需求 ， 然后一步一步将数据库做大、做强 。 因此 ， 只有找到业务需求带来的机会 ， 切入进去 ， 并且落地 ， 就有机会活下来 。
一定要“活下来”
说起来容易 ， 做起来难 ， 阳振坤要做的分布式数据库 ， 是个“难产儿” ， 根本找不到业务 。
好在当时出任OceanBase项目负责人的楚材是淘宝老人 ， 他带着阳振坤走遍了淘宝各个业务技术团队 ， 几天后 ， 终于在淘宝收藏夹这个业务团队找到一丝的机会 。
为什么淘宝收藏夹愿意试水？“收藏夹是一个比较特殊的需求 ， 到现在为止 ， 我们也不知道有什么更好的方案能解决它的问题 。 ”收藏夹给淘宝用户提供的服务是 ， 一个人可以收藏上百条、上千条自己感兴趣的商品 ， 商品的信息变化如降价、下架等都需要及时更新 ， 以便用户掌握商品动态 。 每次用户打开收藏夹 ， 后台系统都要查询数据库成百上千次 ， 获取每个商品的最新信息 ， 这对于数据库来说 ， 相当于几百万、几千万的人在读取数据 ， 再乘百千次的读次数 。 如此高频的数据处理量 ， 几乎没有什么数据库能够扛得住 ， 经常被用户投诉“没反应”“打不开” 。
“我们做了一个比较特殊的架构 ， 后来发现这个架构有非常大的价值” ， 阳振坤欣喜地说道 。 简单来讲 ， 商品信息修改不会直接写进硬盘 ， 而是暂存在内存中 ， 每次用户收藏夹展示的时候 ， 只需要从内存中获得修改后的商品信息 。 相当于将收藏夹原来的成百上千次I/O（输入/输出）变成了一次I/O ， 原计划需要扩容至数百台机器 ， 现在也只需20多台机器就能解决问题 。 这极大地减少了机器数量 ， 降低了成本 ， 增强了业务稳定性 ， 初步证明了OceanBase的生存价值 。