資料庫管理-第124期 資料庫圈的夜郎自大，危！（202301213）

今天看到薛首席在OSCHINA邀稿的一篇文章 國產資料庫的出現和消失，都不是技術問題及其評論，感觸頗多，忍不住得寫一篇文章。

1 0和1的藝術

現在計算機，歸根結底是二極體的使用藝術，即開與合，0和1，執行在硬體之上無論是作業系統、軟體還是其他什麼的，都是對二進位制的使用，本質還是和數學打交道。以資料庫為例，其中的各項演算法都得和這最基礎的數學打交道，涉及基本的二進位制、硬體韌體、硬體指令集、硬體驅動等等與軟體執行之間的結合。我一直沒搞懂總有人在說，近幾十年來很多涉及資料庫數學層面的東西沒有進步，我們隨隨便便就能趕超？！我是一個高中文科大學園林設計專業的DBA，我無法從深層次的數學層面來解釋一些東西，但是我可以透過一些方法來展現結果：安安分分用相同的配置在Oracle 11g vs 19c、MySQL 5.6 vs 8.0、PG 9 vs 16跑跑完全相同的東西，抹平所謂的硬體帶來的進步，看看效能有沒有提升（別說難搞，大不了一臺4C16GB虛擬機器輪流測試）。

2 頻寬的瓶頸

說起頻寬瓶頸以前一直說是磁碟IO瓶頸，傳統的HDD頂多300MB/s和幾百幾千IOPS的效能確實不夠看。但現在的傳輸頻寬，還是存在一個比較尷尬的情況，大多數網路都是以萬兆為主，之前我的文章也講過，現在主流的PCIe4.0 x4 NVMe SSD單盤極限頻寬能來到4000MB/s，即是一塊SSD即可佔滿萬兆網路（1250MB/s），而主流的32GBps的HBA卡也可以一塊SSD佔滿，40GBps的IB交換機勉強支撐一塊SSD，100GBps的RoCE交換機3塊SSD即超越，再往上多路的話依次類推，總之在NVMe SSD越來越廉價的今天，即使考慮 隨機讀寫的效能衰減問題，數量不多的SSD也能佔滿單機的頻寬。在磁碟效能>傳輸效能的當下，我仍然能聽到，就對比Oracle Exadata的基於X86伺服器的分散式儲存來說，專用儲存裝置更好。Oracle Exadata儲存層做了啥，Exadata Storage Software充分利用了硬體特性與軟體結合，在儲存內部就實現資料的過濾篩選， 減少網路傳輸層面的頻寬需求，讓NVMe SSD、PMEM這些高效能磁碟裝置發揮真正的作用而不是去撐爆網路。就專用儲存而言，無法突破使用伺服器的傳輸瓶頸，即使IO再強勁，出口頻寬再大，也只能突增使用儲存裝置的伺服器數量；而對於單機伺服器配置大量高效能磁碟來說，特別是用於分散式資料庫中的跨分片操作，只要資料量稍微大一些，網路就很難扛得住（不一定是磁碟引起的也可以是記憶體），這也是為啥分散式資料庫建議把關聯資料放在一個分片內（這得從資料庫層面幹掉多少需求或者說是一些需求就不能用分散式資料庫實現）。回頭看看本節一開始，為啥當年有分散式，我個人認為單機效能不足需要更多機器來堆，但是現在一塊小小的SSD比曾經幾十上百臺叢集整體IO效能還好的情況下，分散式是不是又成為了一個偽需求。再看Exadata的解決方案，充分利用硬體的儲存分散式+資料庫集中式，是不是更合理呢。

3 “遙遙領先”

不知何時開始，估摸著是電影《蕃茄首富》的“臥龍鳳雛”開始，很多曾經的讚美之詞，現在也蒙上了貶義詞的陰影，其中就有來自某大廠某大嘴的“遙遙領先”。我已經不止一次在國產資料庫溝通、宣傳材料（包含潛臺詞）、行業形勢宣傳中看到，我們們的很多產品已經遙遙領先於Oracle、DB2、SQLServer、MySQL、PostgreSQL這些國外資料庫產品（我也不知道後兩個那麼多套殼的好意思說出口）。回到之前寫過的，資料庫是一個需要長期時間去磨礪的基礎系統工程，不是把一大堆所謂的“先進理念、先進架構、先進演算法（特別是只會拿來用不知道到底怎麼實現的演算法）”縫合在一起，倒騰出資料庫產品就能很牛逼的？！這樣帶來的只能是所謂的快速追趕進度，真要追得上，以這種忽略地基的方式是不可能實現的。

總結

資料庫圈， 正 視差距不丟人，夜郎自大才丟人，所謂的“遙遙領先”最終帶來的是系統的危險。