今天早上南京下暴雨，我有走路上班的習慣，今天也不例外。不過不巧的是家里的兩把大傘都被我放在辦公室里忘記帶回來了，只能拿著一把遮陽的小傘出門。可想而知，在瓢潑大雨之下，沒走到草場門大橋，我渾身上下除了腦袋都已經濕透了。突然間我想起了國產數據庫和Oracle，和這把小傘似乎類似。雖然外觀和功能差不多，都是可以用來防雨的，擋個太陽或者雨小的時候看不出太大的分別，遇到這樣的暴雨，才能看出差別來。
今天不討論國產數據庫行不行的問題，而是討論一下RAC這種技術。前些年國產數據庫興起的時候，大多數都是使用分布式架構的。和一些國產數據庫的從業人員交流的時候，他們都認為分布式架構可以突破Oracle RAC的限制，實現PB級的OLTP系統，而RAC這種共享存儲架構的數據庫，節點數量超過8個就很難使用了，因此頂多能處理100TB左右的數據。因此說，共享存儲架構的代表性技術RAC是一種過時技術，早晚會被淘汰。
快10年過去了，真正能夠很好地支持PB級的OLTP分布式數據庫系統我還沒有見到，RAC技術被淘汰同樣也沒有見到。倒是今年的DTCC上，看到很多國產數據庫廠商紛紛發布了類似RAC技術的產品。達夢DSC已經在部分用戶那邊商用了，優炫再次發布了SuperRAC，人大金倉也很快會推出共享存儲多讀多寫的產品，高斯的RAC版本已經在路上了，虛谷偉業的RAC也在開發中。連萬里開源都聯合華為發布了支持共享存儲多讀多寫的MySQL產品。從這些情況來看，似乎RAC技術并沒有被人遺棄，一大波國產RAC馬上就要登場了。
仔細想想這個現象為什么會出現，我想主要是兩方面的問題，一方面是IT技術發展的速度與方向比較難以預測，另外一方面是很多數據庫從業者對用戶需求的掌握也存在偏差。
實際上，預言一種技術是否有前途并不是一件簡單的事情，特別是在IT領域。二十多年前，當我第一次看到Oracle RAC的前身Oracle OPS（Oracle Parallel Server）的時候也是不屑一顧的，因為我覺得基于VAXCLUSTER的RDB才代表著集群數據庫最高水平。
通過CI耦合器連接起來的VAX小型機和HSC-50存儲系統可以以70MB/S的速度互聯，在任何一臺小型機上都可以無差別地通過VMS系統的鎖來并發訪問RDB數據庫中的數據，VAX/Cluster的分布式鎖為RDB數據庫從底層提供了并行訪問能力。而基于緩慢的10M網絡的Oracle OPS肯定就不被看好了。不過隨著1000M網絡的普及，Oracle 9i推出了革命性的Oracle RAC，通過網絡傳輸CURRENT BLOCK替代了效率極低的通過寫盤解決緩沖區中臟數據的低效機制，效率上的提升讓Oracle的并發處理性能得到了質的提升。而VAX/CLUSTER在這場技術競爭中徹底消失了。
Oracle OPS和RAC都是為了彌補Oracle只能SCALE UP無法SCALE OUT的缺陷的。主要是怕當時的小型機單機性能遇到瓶頸后，數據庫算力無法橫向擴展的問題。隨著時間的推移，2節點RAC，甚至4節點、8節點的RAC都可能無法處理一些超高并發的應用場景了，因為網絡和IO都可能成為RAC增加節點的攔路虎。
事實上這個情況到現在還沒有出現，萬兆甚至10萬兆網絡的出現與普及、SSD盤替代傳統的SAS HDD，這一切似乎讓那些十年前十分令人擔憂的問題迎刃而解了。10年前Oracle公司也曾動搖過，在12c中十分匆忙的推出了sharding數據庫技術。不過到了2019年，隨著計算機硬件出現的突破性發展，Oracle的戰略又回歸到了以RAC為核心的技術層面，在2019年的OOW上提出了融合數據庫（Coverage database）的概念。學習了智能手機對用戶提供的友好互動能力的理念，回歸到給用戶提供便捷的應用支出上。我想這是Oracle針對IT基礎硬件發展后的重要修正。
目前我見過的絕大多數使用Oracle RAC的用戶，都不是因為單機處理能力不足，主要還是為了系統的高可用。而我見到過的絕大多數分布式數據庫用戶，也在用著高射炮打蚊子這樣的超級豪華配置小心翼翼的使用著分布式數據庫，因為他們發現一旦分布式數據庫的某個節點的硬件資源出現了瓶頸，會導致數據庫很容易出現一些莫名其妙的問題，而對他們而言，多配點硬件并沒有什么壓力，讓數據庫更穩定的運行才是他們最需要的。
另外一個十分值得數據庫從業人員注意的方面是應用于計算模式的改變，已經讓SALE-OUT不是剛需了。歷史數據歸檔平臺、大數據平臺、數據湖、流批一體實時數倉的建設，讓OLTP數據庫不會無限擴大到集中式數據庫無法管理的規模了。在我們腦子里十分需要SCALE-OUT，生怕SCALEUP無法滿足業務需求的時候，沒有大數據平臺的概念，甚至沒有OLTP/OLAP分離的概念。而當數據處理技術發展后，實際上對SALE-UP的恐慌應該消失了。現在再拿SCALEOUT說事，似乎已經有點不合時宜了。
從上面兩方面來看，我們需要分布式數據庫，不是因為需要SCALE-OUT，大多數用戶使用分布式數據庫需要的只是高可用。我曾經和一個金融用戶討論過分布式數據庫，他說他們選擇分布式數據庫，是考慮一旦某個硬件故障后，系統只會有部分不可用，因此在考核中，不會算他們是系統故障。如果從這個角度看，如果一個分布式數據庫的節點故障，最壞的情況是在幾十秒鐘到一兩分鐘內業務全停。而如果是RAC系統，當一個節點故障時，RAC RECONFIGATION導致的業務全停時間最多只有幾秒鐘，在最壞情況下RAC并不落下風。
實際上討論一種技術的好壞，主要還是看用戶的應用需求以及技術與用戶應用的匹配度。從我目前見過的用戶的情況來看，說RAC是一種過時的技術，似乎還有些武斷。
