OceanBase的公众号上发了一篇文章：滴滴分布式数据库选型之路。这是一篇非常精彩的文章，技术值得大家深究，非技术的东西，更值得大家深究。

文章呢，大概描述了这样一个故事，恩怨情仇可谓有趣。

滴滴用的MySQL，百亿大表，业务访问延迟高，而且业务有事务依赖，这种事情，拆分表就搞不定了。加上有审计需求，所以，归档服务里面保存了几十上百TB数据，每次业务需要做DDL增加新的column的时候，DDL本身能持续数天甚至数周，可谓夸张。而且，有些业务既要又要，既要TP又要AP，MySQL干不了AP就只能通过复制的方式把数据同步去另外一个AP平台。这就不好了，成本贵，有延迟，为什么不能够既要又要HTAP呢？

最后，金融服务对数据有强一致性要求，所以只能强制读写主库，然后业务量上升，就只能不断拆分主库了。是不是很熟悉，是不是很熟悉。是的，这些个MySQL的痛点，加上既要又要的需求，可不是某DB宣传的重点吗？于是，滴滴的业务痛点，和某DB提供的产品特性，就这样结合起来了。

2021年初，滴滴受不了MySQL了，只能换产品。经过紧锣密鼓的选择，滴滴选中了某个名声响亮的某DB。于是故事进入下一个阶段。滴滴的同学们开始学习分布式数据库基础，然后进行了四个阶段的测试，先是各种测试，然后上了某非核心归档库，接下来又接入了公司级监控，最后接入了线上归档库和在线集群。

从2021年初调研，到2023年初最终接入，前后差不多两年时间，也算是真的修成正果了。问题是，事情并没有想象中的那么美好啊。修成正果的这个正果，好像有点歪了。某DB在日常集群扩容，索引添加的整个过程中，业务延迟上涨40%。而且，在业务流量和业务模型都不变的情况下，某DB会像帕金斯病人一样，日常抖动起来。抖动范围在40%-100%。一旦抖动起来，延迟变长，就会导致大量SQL执行失败。

故事到这里，大家也应该知道，某个名声响亮的某DB，到底有哪些可能了。滴滴知道，OceanBase的人知道，你知道，大家都知道。后面的故事，就是转角遇到爱的故事了。既然大名鼎鼎的某DB都不行了，滴滴也只能在圈子里看看还有没有类似大名鼎鼎的其他DB了。于是，就看上了OceanBase。

考虑到上次测试某DB的时候走了很多歪路，各种各样的常规测试无法反映上线以后的帕金斯抖动问题，所以滴滴这次打算上来就来一剂猛药。结果测试以后，很牛逼，完全没毛病，而且也没有出现帕金斯综合征的抖动问题。按照滴滴的说法，完全满足了业务需求。总之，上次结婚很不成功，虽然某DB有HTAP，自动扩容等各种能力，但是架不住日常时不时的帕金斯综合症抖动。而OceanBase就很平稳了。

文章后面就是OceanBase要继续在滴滴推广，干翻MySQL，以及一些对OceanBase提出来的可以改进的不痛不痒的地方，这些就不重要了。有趣的事情在于，为什么在OceanBase的公众号上，发表了一篇使用OceanBase如何改善业务的文章，里面为什么有一段专门去描述滴滴上线某著名DB以后的段落。

在这个段落里，还和大家揭示了某DB的帕金斯病，抖啊抖，没事也要抖，严重影响业务。

OceanBase这打某DB打的也是不遗余力。我们都知道有句话叫做盛名之下其实难副。到底是真牛逼，还是风口的猪在飞，确实说不清楚。但是同行就是冤家吗？出来混，总是要打脸对方和被对方打脸的？

某DB是一个好名字，好像某DB知道自己被打脸，滴滴和OceanBase知道自己打脸的某DB是谁，我这个作者也能猜猜某DB是哪个DB，读者们还能会心一笑的说，哦，原来是那个DB。但是呢，从滴滴到OceanBase到我这个作者，具体某DB是哪个DB，都是不能说的。所以，这脸，好像打了，又好像没打，到底是打了还是没打？OceanBase确实够猛。我也想看看，有没有可能某DB出来打脸OceanBase啊。

按照滴滴说的，某DB应该有个新名字：某帕金森DB。
先去买个🍉吧。