作者：馮源
整理：老魚
作者介紹：
馮源，武漢達夢資料庫股份有限公司副總經理,主要負責達夢資料庫產品的軟體測試、技術規劃工作。長期從事大型、通用國產關係資料庫管理系統——達夢資料庫產品DMDBMS v4.0、v5.0、v6.0、v7.0和v8.0系列的產品測試和技術規劃工作，熟悉國內外主流資料庫產品體系架構，對於資料庫安全防護體系、資料庫性能優化、資料庫領域基準測試模型與方法具有深厚經驗;參與了《GB/T 30994-2014 關係資料庫管理系統檢測規範》、《GB/T 20273-2019 資料庫管理系統安全技術要求》等多項國家標準的編制工作。
正文
我分享的主題是「達夢分布式資料庫演進」，主要分享達夢公司分布式資料庫演進、發展歷程，介紹達夢公司對分布式資料庫未來發展和應用前景的分析觀點。
在正式分享前，我想先從幾個不太相關的小故事講起，以歸納我的核心觀點。
無論是爆米花，還是要扔出去的手雷，亦或是過年發射的竄天猴，其實都有一定共性，就是加熱膨脹時，如果不對其進行精準控制，扔出去就會變成一個炸彈，如果是在精準的溫度、壓力下釋放，就會變成爆米花，如果自始至終都給其一個發洩口，就會飛上天去變成一個漂亮的焰火。
通過這三個事物，我想表達的是什麼？很多時候，看起來不太一樣的東西背後，其實都有著相似的原理，不同的用途，就看你怎麼用？
技術是用來解決問題的，同樣的技術可以解決不同問題。反之，為了解決問題，達到相同目標，又可以選擇不同的技術，至於用什麼技術、用哪項技術，還是以需求為核心，這是我在導語當中可以得出的兩個結論。
接下來，我將通過挖掘分布式資料庫是怎麼產生的，最初是為了解決什麼問題，來印證前面兩個結論。
分布式資料庫其實不是什麼特別新鮮的東西，基於以下幾個事實：
為什麼？上述事實可能不是特別清晰，回到當時文獻看一看，這是1979年到1980年的文獻。
總體來說，當時學術界對於分布式資料庫的研究，主要分為兩個架構：一個是分層集中控制式，也就是很多區域性資料庫，上面加一個分布式調度層。另一個是非集中控制式，這個更接近現在的分布式資料庫，也就是去中心化的架構。即便是在今天來看，也不是特別過時，現在有很多資料庫仍然是沿著這樣的思路架構來做。
無論任何一種架構，1970-1980年時，其定義，抽象出來有三個特點，也就是所謂的分布式資料庫應該具備哪些特徵？
首先，是跨物理地域的特點，資料庫實例分布在不同的物理地點。當時名詞中，有一個「集群系統」，也是採用類似架構，由很多節點組成，但沒有跨地域，所以，稱之為集群系統。
另一特點是局部自治性，任何資料庫都應該具備本地管理、本地處理的能力。
在此基礎上有全局性的數據訪問請求時，不需要關心數據分布在哪一個區域，稱之為應用透明性。
總結起來，就是物理上分布，邏輯上一體。
當時的分布式資料庫選的什麼技術進行研究？我們能發現，其中很多詞在今天是非常熟悉了，比如數據的劃分，水平劃分還是垂直劃分，分片存儲還是複製存儲，數據分布以後如何保證事務完整性？怎麼實現數據提交？怎麼預防分布式環境下的變化？
要用一項技術，一定要看當時的需求是什麼？我們再仔細看，就會發現非常有意思的東西，今天我們談資料庫的劃分，更多的是希望，通過資料庫的劃分讓數據分散存儲，提高數據存儲能力，通過分散存儲可以實現過載均衡性能提高，但當時的論文寫得非常有意思，他們的目標是節省網絡費用，甚至包括後面很多研究者在研究，到底是應該分片還是應該複製，或者是在什麼時候分片、什麼時候覆制，出發點也是怎樣平衡存儲費用和網絡通信費用。
既然，分布式資料庫的大量技術問題，早在「上古時代」就已經提出，並已有相當的基礎，那麼，為什麼分布式資料庫在90年代卻「偃旗息鼓」了？
如果仔細回顧當時研究這些技術的目標，也就是費用問題，就能夠很清楚地知道，為什麼出現這些情況。（左圖）是當時西德實驗室的分布式資料庫，從當時的架構圖非常清楚地看到，三所大學節點網絡通信用的是電話線，九十年代，在家裡上網都知道，那個時候上網費有多貴，所以，如果資料庫系統，分布式通信依靠的是電話線實現，就近劃分數據就近訪問數據，一定能夠節省大量的通信費用成本，如果不去挖歷史，是無法得知當時的技術目標是什麼。
七八十年代，計算機應用剛剛興起，那時，現在熟悉的中間件還不存在，用戶稍微多一點，資料庫就無法承擔並發能力，在C/S模式下，硬體能力不足以支撐「較高並發」，因此，單機資料庫或者集中式資料庫沒有辦法滿足性能要求。
為什麼在九十年代會發生這種巨變？原因很簡單，硬體技術的發展，使得集中式資料庫具備了足夠的並發處理能力。另一個非常重要的原因是，交易中間件的誕生和完善，大概是1985年到1995年，它的出現改變了應用程式訪問資料庫的訪問模式，信息系統從兩層結構變成三層結構，顯著改善了資料庫並發響應速度。
達夢認為，集中式資料庫技術的發展，充分發揮了硬體設備的能力，當時面對的問題，最終由硬體設備的發展+集中式資料庫組合解決，人們失去了繼續發展、使用分布式資料庫技術的理由。
小結一下，通過對七十年代到八十年代分布式資料庫的回顧，不管是用戶或是研究者，在當時研究分布式資料庫技術，或者到了九十年代不再研究分布式資料庫技術，最終都是「需求第一」 性原則的作用結果。
1989年，達夢發布了第二代資料庫產品DM2（分布式資料庫管理系統），也是那時，達夢開始做分布式資料庫研究，體系結構、存儲結構和隨機查詢方面都做了一些工作，最後，也是隨著技術趨勢的演進，演變為主要研發集中式資料庫產品。
到了今天為什麼分布式資料庫再次興起？移動網際網路之前，我們非常熟悉的甲骨文和IBM這些巨頭，在市場上非常成功。而到2012年，以Google發布Spanner論文為標誌，分布式資料庫結束蟄伏。分布式資料庫到今天有著非常多的流派，大體上可以分為三類：Google Spanner及其參考文獻，PG XC/XL技術結構方案更傳統，也更接近經典的分布式資料庫，為什麼我把PG單獨拎出來說？因為，達夢看到，今年國內有很多分布式資料庫廠商基於PG XC/XL，產業上是不可忽視的點。另外Amazon雲原生資料庫，國內也有很多產品是參照其方案實現。
我們找到一些參考資料，只針對Spanner和Aurora進行了對比，我個人把PG也加進來了。可以看到，雖然大家都叫分布式資料庫，但實際上細節不一樣，這說明實現目標不一樣。如果仔細去看的話，有的是共享存儲架構，有的是非共享。今天，因為時間有限，我們單獨拎出來一個點看一看，比如持續可用。為什麼不同的分布式資料庫會選擇不同的資料庫協議？強調一下，之前我形成的第一個結論，為了解決產品的問題，用戶和開發人員都是以「需求第一性」原則為主。
Spanner有很多的技術創新，最關鍵的精髓有幾點：首先是引入PAXOS，引入TruTime API，然後，做了多版本的外部一致性。
為什麼Spanner要做PAXOS？Spanner是Google自用的資料庫，雖然後來發布了Cloud Spanner，但在最初，它是給Google廣告系統用的。Google是一個全球化的公司，業務遍布全球，用戶遍布全球，分布式機構也是遍布全球，全球化的公司就有全球化的利益，什麼叫做全球化的利益？就是當一個區域甚至一個大洲發生不可控的因素的時候，利益不會受損，業務可以持續運轉，需要一個能夠維護全球利益的資料庫，也就意味著遇到局域性的災害、疫情甚至政治不穩定、海底光纜故障大面積設備失效，也可以保證其業務持續不斷地賺錢，也能為客戶帶去它的價值，這是Google對資料庫的訴求。正因為如此，Google第一篇論文並非冠以分布式資料庫，而是冠以全球分布式資料庫的名字和原因。
今天，我們發微信或打電話都時習以為常，認為信息傳播成本非常低，可能就幾分錢或者幾毛錢話費，但我們忽略了一個事實，信息傳播速度是有上限，信息傳輸是有成本的。
站在地球這樣個範圍不是問題，如果極端一點，遠在火星或太陽進行通信，一條消息發過去，要五分鐘的時間，如何知道消息對方收到否？所以，通信天生的不可靠才是一種常態。
只有在這種情況下，我們才會意識到，進行一次通信傳輸應該有一些保證，保證信息不可失真，保證大家能夠看到同樣的消息，在這種情況下PAXOS是最好的衍生性保障。
為什麼70年代會有分布式集群概念？因為距離比較近，如果距離遠，信息能不能收到會成問題，我們是不是能達成共識也是問題，這是這個概念的由來，沒有一個大距離的跨度，是不需要這麼複雜技術的。
眾所周知，PG-XC/XL的經典版本，或社區版本當中用的是傳統複製技術，保證同步複製和異步複製，好處是同步複製帶來強一致，異步複製延遲較低，但這是在一個小距離環境下看到的，也就是一個硬幣正面和反面的問題。要是這個距離擴大到一千公裡級別，硬幣的另外一面就會顯現出來，在大區域範圍下，同步複製的延遲以及異步複製帶來的不一致性問題就會顯現。PG這套系統如果視之為集群效果非常好，有著更好的響應時間、運維和線性擴展效果，所以，這套系統更適合小範圍部署的、追求線性擴展的用戶。
雲原生算不算分布式？有沒有衡量標準？如果以是否產生分布式事務來看，單主模式是沒有分布式事務的，所以不是分布式資料庫。以有沒有分布式存儲來看，邏輯上看是共享存儲，所以，好像也不算分布式資料庫，但是基於雲技術實現分布式存儲，所以應該可以算分布式資料庫。如果從有沒有跨地域的能力來看，當然有了，所以應該算分布式資料庫。
因此，從需求第一性原則出發，雲原生是不是分布式不重要，重要的還是Amazon為什麼要做？Aurora的定位是什麼？滿足全球訪問需求？其實不是，也不是在小範圍做到極致擴展，就是為了租賃給普通用戶。普通用戶怎樣使用資料庫？99%的用戶沒有像Google那樣的全球利益，也不需要做極致的擴展，其實就是一種使用模式，只是想把以前使用從本地搬到雲上，簡簡單單地讓雲廠商解決副本的問題就很完美。
所以我們能看到，過去幾年，雲原生數據架構的變革更多的是在中下層動刀，比如亞馬遜的日誌即數據，減少雲上的網絡流量，到了國內可能還有一些改變，Quorum協議改到Raft協議，進一步降低網絡同步流量佔用，但會引入一些延遲；不過這樣也沒關係，可以通過RDMA來彌補。另一方面，因為雲上部署，因此基礎設施集約化是可以做到的，NVME可以上，FPEG、RDMA也可以上，這些就是前幾年可以看到的雲原生資料庫廠商的技術發展的內容，而資料庫的中上層，更多的是以繼承PG和MySQL為主。
通過分析這三類技術路線，達夢認為是不是分布式其實並不重要，還是要回到發展技術的初衷來看「需求第一性」。站在用戶的角度要不要用分布式資料庫？怎樣用分布式資料庫？用戶應該要對自己的需求非常清楚，然再去選資料庫。
剛才談了三種架構，還有一種沒有談，就是分布式中間件。2015年，達夢做了一個分布式中間件，後來發現這個技術方案對應用不透明，事務也不保證，容災能力也較弱，所以，達夢拋棄了這套方案，中間件的事情，交給中間件廠商來做，達夢來走適配，效果同樣很好。
到了2019年，達夢認為從現狀上來看，分布式資料庫最大的問題是兼容性代價太高，所以，達夢更提倡透明式TDD的概念，在保障資料庫通用性、具有比較強的一致性前提下，同時具備一些可擴展的能力。
到了2020年，達夢發布了新一代的原生資料庫，希望在透明式分布式資料庫的基礎上進一步加強分布式處理能力。
達夢分布式思路，原則是「需求第一性」，技術只是工具手段，按需選擇。
鑑於分布式資料庫現狀，眾所周知，分布式資料庫性能很強，但有好就有壞。達夢對未來的判斷是，80%的系統架構還會在原有的傳統集中式架構當中去用，因為這些業務系統負載較高，或者對可靠性要求沒有那麼高，並發也沒有那麼高，通過傳統技術可以非常低成本地解決。
隨著分布式架構複雜度的增加，成本也一定會增加，所以，更適合更高端的行業場景。傳統集中式無法解決的分布式資料庫應該是什麼樣子？
首先，是數據量爆炸，並發曲線非常陡峭，用戶對數據響應時間的容忍度相對比較低，這也是一個現實，分布式資料庫今後不是你的資料庫或者是我的資料庫，它將變成基礎設施，因此一定要有足夠的容災能力，因為，大家都是跑在一個系統上。
時間有限，每個需求採用什麼樣的技術來滿足，不能全部介紹，我只提三點：達夢資料庫已經引入Raft，因為異地副本自適應能力是採用傳統複製技術不可能實現的，現在有很多廠商仍然採用一主多備的複製，達夢認為並不太適合1000公裡以上的自適應故障處理能力。
前幾年，分布式資料庫主要是談架構，很少談優化器，其實優化器是資料庫的核心。作為一個傳統的資料庫廠商，做了這麼多年，達夢最大的優勢就在於優化器。記得以前和大家分析過一個案例，一個央企財務系統上，有一個500多頁的SQL，達夢可以很好的處理這種複雜SQL，這種請求目前來看，在分布式是比較難處理的，而達夢可以把這種SQL優化能力，從集中式資料庫平移到分布式資料庫產品裡面。
目前，分布式資料庫應用和推廣最大的障礙就是生態，原因在於分布式資料庫的通用性不夠：很多經典功能在集中式可以用得很好，分布式就不能用，所以，會有很多的應用移植工作。達夢的重點思路是通過一套Code Base完成這項工作，不管是集中式還是分布式，達夢都用一套Code Base，無論是做運維管理還是應用開發，或是做大數據集中層，協議都是一樣的，語法都是一樣的，可以做到平滑的過渡、互聯，實現統一。
最後，目前看來分布式資料庫技術現狀，用一個字來總結就是「亂」，廠商多、路線多、概念多。但這是百花齊放的時代，亂是正常的。從長久來看，最終一定是趨同。不管是從傳統廠商做起的達夢，還是從To B、To C或者伺服器廠商做起的，沒有誰一開始就是做分布式資料庫的，大家的基因不太一樣，但基因不是重點，重點是環境最後會把大家塑造成長得差不多的模樣。所以，作為用戶不用太擔心，選誰都不會錯。