滴滴，某DB，和OceanBase的愛恨情仇。。。

關注飛總聊IT，瞭解IT行業的方方面面。

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。

先去買個吧。

今天宣傳一下我的朋友圈吧。專欄也賣不動。朋友圈已經很多年了，能聽到飛總更真實的，不用遮遮掩掩話，能直接向飛總諮詢。飛總真粉絲可以考慮一下。

新人優惠券100份到月底：

續費85折，外加優惠券100份，到月底：