第133期 為什麼一些場景下Oracle很難被替換掉（20240113）

今天在薛首席的群裡，聊到一些應用場景和資料庫的事情，講到很多國產資料庫也在朝All in One的融合方向發展，但是很多資料庫連一件事情都還沒做好，發展充滿了挑戰、機遇與矛盾。PostgreSQL中文社群前主 席、巨杉資料庫產品及運營資 深總監蕭少聰，蕭老師說了一句話“說實話都是Oracle惹的禍，要不是他做的那麼牛逼，中國資料庫有至於那麼難嗎。”確實，在某些應用場景或者說叫使用環境下，Oracle資料庫是很難被替換的，結合一些以前一些文章（包括被轉載的地方）的留言討論和一些群聊內容。

1 資料量

先保個命，這裡不是說分散式資料庫不好，但確實最早分散式資料庫的出現有一點原因是單機處理效能不夠，需要更多的伺服器來解決問題，其中很大一個原因就是資料量的增長。而現在在軟硬體水平飛速發展的現在（尤其是IO能力），單機的處理能力有了非常顯著的提升，現在的瓶頸反而來到了資料庫單個例項的處理能力上了，當然Oracle也可以需要透過RAC來擴充套件多個例項來解決一些場景，但就目前的實踐來看，使用Oracle RAC確實用不到分散式資料庫那麼龐大的伺服器規模。
這裡又到某些人的觀念，一個關係型資料庫就不該存放超過10TB的資料，這裡拿我服務的運營商來舉例，一個省的資源點大大小小加起來會達到幾十億的量級，其中本身描述資料非常複雜（說白了就是行資料量賊大的那種）的資源點也是過億的，其中的關聯關係和資源本身的其他屬性，就會帶來海量的資料（這裡還沒有包含所謂的時序資料），對這些資料的使用，其實偏向於OLTP，比如資源點的存活狀態、效能狀態、上下游關係、告警等等操作，這種雜亂無序的資料的操作，是Oracle（或者說是集中式資料庫）擅長的，而單存從海量資料的處理效能和硬體資源利用率來看，目前Oracle還無出其右。
說起資料量，吐槽一下之前看到的留言評論，說資料庫使用不佔IO資源，其實說出這樣觀點的人無外乎就幾種，沒有接觸過大規模的系統的、只接觸過大系統的部分功能的或者純純圈外習慣質疑的…

2 架構

雖然現在我主要服務於運營商，算是傳統企業，但是曾幾何時也供職工網際網路公司（再說了還有那麼多網際網路公司的大佬朋友可以探討）。我發現一點，傳統企業或者說是傳統行業，IT架構往往十分簡單，一個或多箇中介軟體伺服器加上一套資料庫就能解決問題，這裡也要說一下Oracle無論在功能還是效能上都能很好的支撐這種架構（PG用好了也可以哈）。
但是很多網際網路架構，實現資料的高效能和及時性往往是透過一個比較龐大且複雜的資料中間層實現的，比如Kafka、Redis、ElasticSearch、ClickHouse等等組合出來的，也就是很多地方說的中臺架構，這種架構（如果配合上雲）的好處就是可以便捷支撐快速擴充套件的業務，快捷上線新功能，而最終資料庫成為了最終記錄和兜底的存在。
傳統架構和網際網路架構沒有好壞之分，差的只是應用場景的不同而已，但是有一點，傳統企業的IT架構往往只需要幾臺伺服器，而變更為網際網路架構（或稱為數字化轉型），往往就要幾十上百臺的伺服器，同時技術棧的擴充套件，原來中介軟體+資料庫的開發管理維護現在可能需要近10種技術棧的使用，以前一種資料庫就能解決的問題，現在A庫查完去B庫，B庫關聯完去C庫，最終結果還要去D庫關聯，不一定每一家傳統企業都能接受或者承受這種變化。

3 應用改造

其實這又是一個歷史遺留問題，大量存量且高負載的重要核心系統仍然執行在Oracle資料庫上，舉一些鮮紅的例子，不能點名，某些金融行業客戶（不是那種賊小的地方）對部分核心系統進行國產化改造，資料庫也就1000W左右，但是應用改造破億了（還超的有點多）。不要去聽信那種不需要針對資料庫進行應用改造的忽悠，不同資料庫單就SQL方言問題都能搞死一大片，更別說不同架構的資料庫使用方式是完全不一樣的。即使是號稱相容性最好的國產資料庫，也需要大量改寫來解決很多效能問題（其實最終整體效能還是不達標）。

4 Exadata和融合資料庫

還是說那些大量存量且高負載的重要核心系統仍然執行在Oracle資料庫上，這類資料庫還有一部分還執行在Oracle Exadata一體機上，一體機效能的強大，可以翻翻我以前的文章，一體機的效能會給很多業務研發帶來一種幻覺，寫個不怎麼好的SQL也能跑出那麼好的效能（我真牛？那是一體機真牛！放在普通自建環境該跑不出來還是跑不出來）。雖然也有人說國產一體機能不錯（同樣跑Oracle），但就一點不行，在Exadata上全庫可以不建索引（這其實是一個調侃，有些場景不建索引效能也還行甚至在分析場景下因為一體機特性效能會更好），而在國產一體機上都得整上（其實就算是國產化硬體遷移不換資料庫，改造量就不少，更別說換資料庫了）。
Oracle近幾個版本都在推融合資料庫，很早以前實現的GIS、Spatial，到後來的Inmemory和JSON資料型別，再到最近Oracle 23c融合了Kafka、JSON二元性、關係型圖、全功能快取記憶體等等功能，使得可以將傳統複雜的資料架構合一到一套資料庫，有些融合進來的功能還不用改使用習慣。這對於IT架構簡單和團隊小的地方，吸引力還是蠻大的。

總結

我認為，資料庫的使用，是應用場景與資料庫產品的匹配，資料庫得適合應用場景，應用也得好好使用、遵循資料庫產品的特性。
最後，我是沒有自己的微信群，這裡推廣一下薛首席的微信群，裡面資料庫圈大佬眾多，日常進行技術、非技術討論，由於群人數已超過200，只能把首席微信二維碼貼出來，想入速加：