關系資料庫肯定都用過，今天我們看一看分布式資料庫。
網際網路進入了 web2.0 時代以來，資料庫作為核心的底層基礎設施軟體也經曆了蓬勃的發展期，從早期的單機關系型資料庫到NoSQL 再到如今的 NewSQL，資料庫領域不管是技術還是場景都發生了巨大的變化。在當下雲原生時代，任何軟體系統擁有分布式能力似乎成了标配。
特别是在目前基礎軟體國産化的浪潮下，國産資料庫百花齊放，大有彎道超車的趨勢。
在這個領域裡面，分布式資料庫無疑是當今最熱門的賽道，本期就帶大家來了解什麼是分布式資料庫。
回答這個問題之前，我們暫且不去考慮各種官方定義，不妨換個思路入手把這個名詞做下拆分，再看一下碰撞在一起會有什麼火花。
#1 什麼是分布式資料庫
Part 1：分布式
以大家非常熟悉的場景舉例，比如完成一項軟體開發工作。
小公司的做法就是招一個全棧工程師，所有任務全包，但往往這樣的人雖然各方面都懂一點卻沒有特别精通的方向，很容易達到能力上限。
在一個大團隊通常會分為多種角色（UI、前端、後端、DBA、運維等），這些人就構成了一個分布式系統，大家協調完成共同的任務，這中間的協調者就是項目經理或者部門 leader。
項目開發中的“分布式
這樣的好處就是：
•職責分離：大家各司其職，各自做好擅長的事。
• 平滑擴容：哪個環節缺人就定點補充。
• 負載能力：可以應對更大更多的項目。
當然了有優點就有缺點：
• 網絡通信：溝通成本增加，需要标準化工作模式。
• 排程：如何高效率協調所有人員。
• 一緻性：如何保證上下遊人員資訊對齊。
概念區分：分布式與叢集
說到分布式就不得不提與之相關的另一個概念，那就是叢集，很多初學者并不能很好的了解叢集和分布式的差别。
還是拿前面的例子來說，假如小公司的全棧工程師有點異常情況（請假、跑路、忙不過來等等）老闆會考慮招多個這樣的人，這就形成了一個叢集，好處就是能幹更多的活（負載分流）和互補（高可用），但本質上還是一個人做所有事。
事實上，分布式和叢集是可以搭配使用的，比如上面的大團隊例子，每個角色可以配置多個人，這就形成了分布式叢集。
Part 2：資料庫
資料庫用通俗易懂的話來說就是管理資料的地方，就像生活中一個存放貨物的倉庫，我們要按一定的規則把物品整整齊齊的擺好（寫資料），這樣就友善我們去檢索出貨（查資料）。
在計算機世界裡，通常會把資料按照二維表格組織起來，這個表格我們稱之為關系模型，然後對這些資料使用結構化查詢語言（SQL）做各種關系運算，就能得到我們想要的結果，這就是關系型資料庫，也是目前使用最廣泛的一種資料庫。除此之外，相信大家也還聽過其他類型的資料庫，比如KV型、文檔型、時序型、圖資料庫等等。
最常見的資料庫就是每個人都用過的 Excel 文檔，一個檔案可以看成一個資料庫，每個 sheet 就是資料表，表裡的列就是字段，每一行就是存儲的資料。
做乘法的“分布式”與“資料庫”
在我看來，“分布式”和“資料庫”放在一起并不是做加法，而是做了乘法。
傳統的那些分庫分表以及各種 Sharding 方案可以看做是一種僞分布式（做加法），和真正的分布式資料庫有着本質不同。
其中最大的差別，便展現在分布式事務上。單機資料庫的事務是在一個節點上完成的，分布式資料庫需要多個節點協調完成。
以經典的銀行轉賬場景舉例：
甲要給乙轉100塊錢，但是甲的賬戶資訊存放在節點 A，乙的資料存放在節點 B。
單機資料庫通過事務很容易就能完成。
分布式環境下的事務就需要考慮各種網絡故障、資料一緻性的問題，對用戶端而言仍然要保證事務操作的簡便性，完成整個轉賬操作和單機資料庫體驗一緻，所有故障處理都要透明。
分布式資料庫繼承了傳統單機資料庫的核心特性，同時還擁有分布式系統的處理能力，理論上所有需求都能通過橫向擴充解決，這是在大資料高并發場景下誕生的一種産物。雖然起步較晚，可以預見的是它将是資料庫下一個發展方向。
#2 為什麼需要分布式資料庫
首先要聲明的是，分布式資料庫的出現并不是要完全取代傳統資料庫，傳統資料庫在市場佔有率和流行度上仍然保持遙遙領先，畢竟這是過去30多年的發展沉澱，底子擺在那裡。至少未來很長的一段時間内，這種領先優勢會持續存在，隻是差距會慢慢變小。
為什麼需要分布式資料庫呢?那一定為了解決傳統資料庫解決不了的問題，任何新技術的引進我認為就是一個目的：降本增效。
達到這個目的之前，我們都要先考慮清楚是否把這個技術用在了适合它的場景。
以我使用較多的分布式資料庫 TiDB 為例：
很多剛接觸到的使用者都會拿它和 MySQL 做對比測試，最後得出的結論就是為什麼 3 台機器的 TiDB 還沒有單台機器的 MySQL 性能好？
這就是一個典型的使用場景錯誤案例。單機 MySQL 就能解決的問題，TiDB 是發揮不出它的優勢的。
這就好比于大家上班通勤，坐計程車就能搞定的事情，你會選擇坐高鐵嗎？你又能說計程車一定比高鐵快嗎？
這兩樣除了都是交通工具外，其實沒有太多可比性，根本原因就是各自的使用場景不一樣，上面 MySQL 和 TiDB 的案例也是這個道理。
下面就來看看傳統資料庫面臨着哪些難以解決的問題。
問題一：海量資料存儲
現在各種各種的終端裝置每天産生着海量資料，這些資料最終都要通過資料庫系統保留下來，如何才能高效地儲存這麼多資料是首先要面對的難題。
一般來說，傳統資料庫的做法就是縱向擴充（scale-up），存儲不夠就加磁盤，計算不夠就加 CPU，記憶體不夠就加記憶體，加到後面加不動了就上小型機大型機。但這種擴充方式總會達到一個極限，而且随着資料庫越來越大，實際成本和收益比會越來越小。
加配置的縱向擴充
分布式資料庫采用了橫向擴充（scale-out）思路，也就是說遇到瓶頸通過加機器而不是加配置解決，這樣就能實作無限水準擴充。再多的資料都能使用一定的分片政策分散到不同的機器，分而治之就是分布式的核心理念。
加機器的橫向擴充
問題二：分庫分表的痛點
在分布式資料庫出來之前，針對大資料量的讀寫場景廣泛采用分庫分表方案，也由此誕生了很多分庫分表、讀寫分離中間件。這些方案雖然能帶來一定的效果，也會引發一些後遺症，比如：
• 需要提前規劃好分片規則，一旦定好規則就難以移動，擴充困難
• 分得太細會浪費資源，分得太粗會導緻二次拆分
• 資料遷移困難
• 運維難度高
說一個我見過的小案例：
下面這張圖是 MySQL 遷移過程中發生的一個報錯資訊：
相信大部分人第一反應和我一樣：從未見過這麼長的表名，根據命名規則來看，基本能判定是為了保持分表規範才這樣設計，要麼是做資料拆分要麼就是資料歸檔，這樣的設計給後期資料庫運維帶來了很大的困難。
在分布式資料庫中不用考慮單表的存儲限制，幾十億上百億行的表非常常見，它能充分利用每一個節點的計算存儲資源，保證讀寫性能。
問題三：高可用容災
高可用名額
說到高可用的時候我們都會提到 3個9、4個9 這樣的名額，它反映了一個軟體系統的可靠性。與此相關的還有兩個重要名額：
• RTO-恢複服務所用的時間，越短越好
• RPO-恢複服務後丢失的資料量，越小越好
對于資料庫系統來說，可靠性的最好情況就是服務永不停機，但這是不可能實作的，因為本身硬體層面就存在一定的故障率。
傳統資料庫的做法
傳統資料庫的做法是做主備架構，部署兩套或多套相同的資料庫系統，中間使用資料同步技術實作實體備份，當主庫出現故障時切換到備庫提供服務。
這種方案有以下幾個缺點：
• 主備切換需要時間，RTO 難以保證
• 主備資料同步存在延時，RPO 也難以保證
• 硬體資源消耗大，運維困難
分布式資料庫的做法
丢資料這種事在某些資料敏感行業是無法接受的。而絕大部分的分布式資料庫自帶多副本特性，并且能保證副本之間的強一緻性，這就相當于天生擁有高可用能力。這種多副本同步能力不僅可以應用在多主機中，甚至能擴充到多機櫃、多資料中心、以及跨區域的能力，極大地減少了硬體成本和運維成本。由于多副本的存在，它可以做到 RPO 為 0，自動故障轉移可以讓 RTO 在秒級。
#3 有哪些分布式資料庫
分布式資料庫根據架構風格的不同我們可以大緻分為兩類。
第一種是由傳統分庫分表演進而來，再加上額外的排程節點實作分片路由、全局時鐘實作分布式事務，基本構成了一個分布式資料庫，但每一個資料節點依然是單體資料庫，通過主從複制來實作高可用，我們把這一類稱為 PG-XC 風格。
這一類的代表作品有：
• 中興的 GoldenDB
• 華為的 GaussDB
• 騰訊的 TDSQL
第二種是整個體系完全重構，資料庫中的每個元件都采用分布式設計，底層存儲多采用鍵值（KV）系統，同時引入多數派選舉算法實作多副本同步，存儲、計算、排程完全分離，我們把這一類稱為 NewSQL 風格。
這一類的代表作品有：
• 國外的 CockroachDB、YugabyteDB
• PingCAP 的 TiDB
• 螞蟻的 OceanBase
還有一類雲原生資料庫也屬于分布式資料庫範疇，典型的産品有AWS的Aurora、微軟的Cosmos DB、阿裡的PolarDB 等等。
#4 分布式資料庫的未來
下圖對比了傳統關系型資料庫三巨頭和新型分布式資料庫的流行度趨勢：
這個統計資料來源于各大搜尋引擎、資料庫問答社群、社交媒體話題等，能夠反映某一項技術的使用情況。
可以看到，分布式資料庫正在以猛烈的趨勢追趕，而傳統資料庫指數在慢慢往下降。
得益于國内網際網路行業的快速發展，國外的資料庫系統遠遠不能滿足需要，由此催生了一批走在世界前沿的國産分布式資料庫産品。不僅僅網際網路客戶在使用，越來越多的國企、政府機關、銀行、證券這些傳統行業也開始關注分布式資料庫，去 O 道路将被加速。
文章來源：https://zhuanlan.zhihu.com/p/503180808