共計 6403 個字符，預(yù)計需要花費(fèi) 17 分鐘才能閱讀完成。

這篇文章主要介紹了云原生數(shù)據(jù)庫設(shè)計的方法是什么的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇云原生數(shù)據(jù)庫設(shè)計的方法是什么文章都會有所收獲，下面我們一起來看看吧。

常見的分布式數(shù)據(jù)庫流派

分布式數(shù)據(jù)庫的發(fā)展歷程，我按照年代進(jìn)行了分類，到目前為止分成了四代。第一代是基于簡單的分庫分表或者中間件來做 Data Sharding 和 水平擴(kuò)展。第二代系統(tǒng)是以 Cassandra、HBase 或者 MongoDB 為代表的 NoSQL 數(shù)據(jù)庫，一般多為互聯(lián)網(wǎng)公司在使用，擁有很好的水平擴(kuò)展能力。

第三代系統(tǒng)我個人認(rèn)為是以 Google Spanner 和 AWS Aurora 為代表的新一代云數(shù)據(jù)庫，他們的特點(diǎn)是融合了 SQL 和 NoSQL 的擴(kuò)展能力，對業(yè)務(wù)層暴露了 SQL 的接口，在使用上可以做到水平的擴(kuò)展。

第四代系統(tǒng)是以現(xiàn)在 TiDB 的設(shè)計為例，開始進(jìn)入到混合業(yè)務(wù)負(fù)載的時代，一套系統(tǒng)擁有既能做交易也能處理高并發(fā)事務(wù)的特性，同時又能結(jié)合一些數(shù)據(jù)倉庫或者分析型數(shù)據(jù)庫的能力，所以叫 HTAP，就是融合型的數(shù)據(jù)庫產(chǎn)品。

未來是什么樣子，后面的分享我會介紹關(guān)于未來的一些展望。從整個時間線看，從 1970 年代發(fā)展到現(xiàn)在，database 也算是個古老的行業(yè)了，具體每個階段的發(fā)展情況，我就不過多展開。

數(shù)據(jù)庫中間件

對于數(shù)據(jù)庫中間件來說，第一代系統(tǒng)是中間件的系統(tǒng)，基本上整個主流模式有兩種，一種是在業(yè)務(wù)層做手動的分庫分表，比如數(shù)據(jù)庫的使用者在業(yè)務(wù)層里告訴你；北京的數(shù)據(jù)放在一個數(shù)據(jù)庫里，而上海的數(shù)據(jù)放在另一個數(shù)據(jù)庫或者寫到不同的表上，這種就是業(yè)務(wù)層手動的最簡單的分庫分表，相信大家操作過數(shù)據(jù)庫的朋友都很熟悉。

第二種通過一個數(shù)據(jù)庫中間件指定 Sharding 的規(guī)則。比如像用戶的城市、用戶的 ID、時間來做為分片的規(guī)則，通過中間件來自動的分配，就不用業(yè)務(wù)層去做。

這種方式的優(yōu)點(diǎn)就是簡單。如果業(yè)務(wù)在特別簡單的情況下，比如說寫入或者讀取基本能退化成在一個分片上完成，在應(yīng)用層做充分適配以后，延遲還是比較低的，而整體上，如果 workload 是隨機(jī)的，業(yè)務(wù)的 TPS 也能做到線性擴(kuò)展。

但是缺點(diǎn)也比較明顯。對于一些比較復(fù)雜的業(yè)務(wù)，特別是一些跨分片的操作，比如說查詢或者寫入要保持跨分片之間的數(shù)據(jù)強(qiáng)一致性的時候就比較麻煩。另外一個比較明顯的缺點(diǎn)是它對于大型集群的運(yùn)維是比較困難的，特別是去做一些類似的表結(jié)構(gòu)變更之類的操作。想象一下如果有一百個分片，要去加一列或者刪一列，相當(dāng)于要在一百臺機(jī)器上都執(zhí)行操作，其實(shí)很麻煩。

NoSQL – Not Only SQL

在 2010 年前后，好多互聯(lián)網(wǎng)公司都發(fā)現(xiàn)了這個大的痛點(diǎn)，仔細(xì)思考了業(yè)務(wù)后，他們發(fā)現(xiàn)業(yè)務(wù)很簡單，也不需要 SQL 特別復(fù)雜的功能，于是就發(fā)展出了一個流派就是 NoSQL 數(shù)據(jù)庫。NoSQL 的特點(diǎn)就是放棄到了高級的 SQL 能力，但是有得必有失，或者說放棄掉了東西總能換來一些東西，NoSQL 換來的是一個對業(yè)務(wù)透明的、強(qiáng)的水平擴(kuò)展能力，但反過來就意味著你的業(yè)務(wù)原來是基于 SQL 去寫的話，可能會帶來比較大的改造成本，代表的系統(tǒng)有剛才我說到的 MongoDB、Cassandra、HBase 等。

最有名的系統(tǒng)就是 MongoDB，MongoDB 雖然也是分布式，但仍然還是像分庫分表的方案一樣，要選擇分片的 key，他的優(yōu)點(diǎn)大家都比較熟悉，就是沒有表結(jié)構(gòu)信息，想寫什么就寫什么，對于文檔型的數(shù)據(jù)比較友好，但缺點(diǎn)也比較明顯，既然選擇了 Sharding Key，可能是按照一個固定的規(guī)則在做分片，所以當(dāng)有一些跨分片的聚合需求的時候會比較麻煩，第二是在跨分片的 ACID 事務(wù)上沒有很好的支持。

HBase 是 Hadoop 生態(tài)下的比較有名的分布式 NoSQL 數(shù)據(jù)庫，它是構(gòu)建在 HDFS 之上的一個 NoSQL 數(shù)據(jù)庫。Cassandra 是一個分布式的 KV 數(shù)據(jù)庫，其特點(diǎn)是在 KV 操作上提供多種一致性模型，缺點(diǎn)與很多 NoSQL 的問題一樣，包括運(yùn)維的復(fù)雜性，KV 的接口對于原有業(yè)務(wù)改造的要求等。

第三代分布式數(shù)據(jù)庫 NewSQL

剛才說過 Sharding 或者分庫分表，NoSQL 也好，都面臨著一個業(yè)務(wù)的侵入性問題，如果你的業(yè)務(wù)是重度依賴 SQL，那么用這兩種方案都是很不舒適的。于是一些技術(shù)比較前沿的公司就在思考，能不能結(jié)合傳統(tǒng)數(shù)據(jù)庫的優(yōu)點(diǎn)，比如 SQL 表達(dá)力，事務(wù)一致性等特性，但是又跟 NoSQL 時代好的特性，比如擴(kuò)展性能夠相結(jié)合發(fā)展出一種新的、可擴(kuò)展的，但是用起來又像單機(jī)數(shù)據(jù)庫一樣方便的系統(tǒng)。在這個思路下就誕生出了兩個流派，一個是 Spanner，一個是 Aurora，兩個都是頂級的互聯(lián)網(wǎng)公司在面臨到這種問題時做出的一個選擇。

Shared Nothing 流派

Shared Nothing 這個流派是以 Google Spanner 為代表，好處是在于可以做到幾乎無限的水平擴(kuò)展，整個系統(tǒng)沒有端點(diǎn)，不管是 1 個 T、10 個 T 或者 100 個 T，業(yè)務(wù)層基本上不用擔(dān)心擴(kuò)展能力。第二個好處是他的設(shè)計目標(biāo)是提供強(qiáng) SQL 的支持，不需要指定分片規(guī)則、分片策略，系統(tǒng)會自動的幫你做擴(kuò)展。第三是支持像單機(jī)數(shù)據(jù)庫一樣的強(qiáng)一致的事務(wù)，可以用來支持金融級別的業(yè)務(wù)。

代表產(chǎn)品就是 Spanner 與 TiDB，這類系統(tǒng)也有一些缺點(diǎn)，從本質(zhì)上來說一個純分布式數(shù)據(jù)庫，很多行為沒有辦法跟單機(jī)行為一模一樣。舉個例子，比如說延遲，單機(jī)數(shù)據(jù)庫在做交易事務(wù)的時候，可能在單機(jī)上就完成了，但是在分布式數(shù)據(jù)庫上，如果要去實(shí)現(xiàn)同樣的一個語義，這個事務(wù)需要操作的行可能分布在不同的機(jī)器上，需要涉及到多次網(wǎng)絡(luò)的通信和交互，響應(yīng)速度和性能肯定不如在單機(jī)上一次操作完成，所以在一些兼容性和行為上與單機(jī)數(shù)據(jù)庫還是有一些區(qū)別的。即使是這樣，對于很多業(yè)務(wù)來說，與分庫分表相比，分布式數(shù)據(jù)庫還是具備很多優(yōu)勢，比如在易用性方面還是比分庫分表的侵入性小很多。

Shared Everything 流派

第二種流派就是 Shared Everything 流派，代表有 AWS Aurora、阿里云的 PolarDB，很多數(shù)據(jù)庫都定義自己是 Cloud-Native Database，但我覺得這里的 Cloud-Native 更多是在于通常這些方案都是由公有云服務(wù)商來提供的，至于本身的技術(shù)是不是云原生，并沒有一個統(tǒng)一的標(biāo)準(zhǔn)。從純技術(shù)的角度來去說一個核心的要點(diǎn)，這類系統(tǒng)的計算與存儲是徹底分離的，計算節(jié)點(diǎn)與存儲節(jié)點(diǎn)跑在不同機(jī)器上，存儲相當(dāng)于把一個 MySQL 跑在云盤上的感覺，我個人認(rèn)為類似 Aurora 或者 PolarDB 的這種架構(gòu)并不是一個純粹的分布式架構(gòu)。

原來 MySQL 的主從復(fù)制都走 Binlog，Aurora 作為一種在云上 Share Everything Database 的代表，Aurora 的設(shè)計思路是把整個 IO 的 flow 只通過 redo log 的形式來做復(fù)制，而不是通過整個 IO 鏈路打到最后 Binlog，再發(fā)到另外一臺機(jī)器上，然后再 apply 這個 Binlog，所以 Aurora 的 IO 鏈路減少很多，這是一個很大的創(chuàng)新。

日志復(fù)制的單位變小，意味著我發(fā)過去的只有 Physical log，不是 Binlog，也不是直接發(fā)語句過去，直接發(fā)物理的日志能代表著更小的 IO 的路徑以及更小的網(wǎng)絡(luò)包，所以整個數(shù)據(jù)庫系統(tǒng)的吞吐效率會比傳統(tǒng)的 MySQL 的部署方案好很多。

Aurora 的優(yōu)勢是 100% 兼容 MySQL，業(yè)務(wù)兼容性好，業(yè)務(wù)基本上不用改就可以用，而且對于一些互聯(lián)網(wǎng)的場景，對一致性要求不高的話，數(shù)據(jù)庫的讀也可以做到水平擴(kuò)展，不管是 Aurora 也好，PolarDB 也好，讀性能是有上限的。

Aurora 的短板大家也能看得出來，本質(zhì)上這還是一個單機(jī)數(shù)據(jù)庫，因?yàn)樗袛?shù)據(jù)量都是存儲在一起的，Aurora 的計算層其實(shí)就是一個 MySQL 實(shí)例，不關(guān)心底下這些數(shù)據(jù)的分布，如果有大的寫入量或者有大的跨分片查詢的需求，如果要支持大數(shù)據(jù)量，還是需要分庫分表，所以 Aurora 是一款更好的云上單機(jī)數(shù)據(jù)庫。

第四代系統(tǒng)：分布式 HTAP 數(shù)據(jù)庫

第四代系統(tǒng)就是新形態(tài)的 HTAP 數(shù)據(jù)庫，英文名稱是 Hybrid Transactional and Analytical Processing，通過名字也很好理解，既可以做事務(wù)，又可以在同一套系統(tǒng)里面做實(shí)時分析。HTAP 數(shù)據(jù)庫的優(yōu)勢是可以像 NoSQL 一樣具備無限水平擴(kuò)展能力，像 NewSQL 一樣能夠去做 SQL 的查詢與事務(wù)的支持，更重要的是在混合業(yè)務(wù)等復(fù)雜的場景下，OLAP 不會影響到 OLTP 業(yè)務(wù)，同時省去了在同一個系統(tǒng)里面把數(shù)據(jù)搬來搬去的煩惱。目前，我看到在工業(yè)界基本只有 TiDB 4.0 加上 TiFlash 這個架構(gòu)能夠符合上述要求。

分布式 HTAP 數(shù)據(jù)庫：TiDB (with TiFlash)

為什么 TiDB 能夠?qū)崿F(xiàn) OLAP 和 OLTP 的徹底隔離，互不影響？因?yàn)?TiDB 是計算和存儲分離的架構(gòu)，底層的存儲是多副本機(jī)制，可以把其中一些副本轉(zhuǎn)換成列式存儲的副本。OLAP 的請求可以直接打到列式的副本上，也就是 TiFlash 的副本來提供高性能列式的分析服務(wù)，做到了同一份數(shù)據(jù)既可以做實(shí)時的交易又做實(shí)時的分析，這是 TiDB 在架構(gòu)層面的巨大創(chuàng)新和突破。

下圖是 TiDB 的測試結(jié)果，與 MemSQL 進(jìn)行了對比，根據(jù)用戶場景構(gòu)造了一種 workload，橫軸是并發(fā)數(shù)，縱軸是 OLTP 的性能，藍(lán)色、黃色、綠色這些是 OLAP 的并發(fā)數(shù)。這個實(shí)驗(yàn)的目的就是在一套系統(tǒng)上既跑 OLTP 又跑 OLAP，同時不斷提升 OLTP 和 OLAP 的并發(fā)壓力，從而查看這兩種 workload 是否會互相影響。可以看到在 TiDB 這邊，同時加大 OLTP 和 OLAP 的并發(fā)壓力，這兩種 workload 的性能表現(xiàn)沒有什么明顯變化，幾乎是差不多的。但是，同樣的實(shí)驗(yàn)發(fā)生在 MemSQL 上，大家可以看到 MemSQL 的性能大幅衰減，隨著 OLAP 的并發(fā)數(shù)變大，OLTP 的性能下降比較明顯。

接下來是 TiDB 在一個用戶實(shí)際業(yè)務(wù)場景的例子，在進(jìn)行 OLAP 業(yè)務(wù)的查詢的時候，OLTP 業(yè)務(wù)仍然可以實(shí)現(xiàn)平滑的寫入操作，延遲一直維持在較低的水平。

未來在哪里 Snowflake

Snowflake 是一個 100% 構(gòu)建在云上的數(shù)據(jù)倉庫系統(tǒng)，底層的存儲依賴 S3，基本上每個公有云都會提供類似 S3 這樣的對象存儲服務(wù)，Snowflake 也是一個純粹的計算與存儲分離的架構(gòu)，在系統(tǒng)里面定義的計算節(jié)點(diǎn)叫 Virtual Warehouse，可以認(rèn)為就是一個個 EC2 單元，本地的緩存有日志盤，Snowflake 的主要數(shù)據(jù)存在 S3 上，本地的計算節(jié)點(diǎn)是在公有云的虛機(jī)上。

這是 Snowflake 在 S3 里面存儲的數(shù)據(jù)格式的特點(diǎn)，每一個 S3 的對象是 10 兆一個文件，只追加，每一個文件里面包含源信息，通過列式的存儲落到磁盤上。

Snowflake 這個系統(tǒng)最重要的一個閃光點(diǎn)就是對于同一份數(shù)據(jù)可以分配不同的計算資源進(jìn)行計算，比如某個 query 可能只需要兩臺機(jī)器，另外一個 query 需要更多的計算資源，但是沒關(guān)系，實(shí)際上這些數(shù)據(jù)都在 S3 上面，簡單來說兩臺機(jī)器可以掛載同一塊磁盤分別去處理不同的工作負(fù)載，這就是一個計算與存儲解耦的重要例子。

Google BigQuery

第二個系統(tǒng)是 BigQuery，BigQuery 是 Google Cloud 上提供的大數(shù)據(jù)分析服務(wù)，架構(gòu)設(shè)計上跟 Snowflake 有點(diǎn)類似。BigQuery 的數(shù)據(jù)存儲在谷歌內(nèi)部的分布式文件系統(tǒng) Colossus 上面，Jupiter 是內(nèi)部的一個高性能網(wǎng)絡(luò)，上面這個是谷歌的計算節(jié)點(diǎn)。

BigQuery 的處理性能比較出色，每秒在數(shù)據(jù)中心內(nèi)的一個雙向的帶寬可以達(dá)到 1 PB，如果使用 2000 個專屬的計算節(jié)點(diǎn)單元，大概一個月的費(fèi)用是四萬美金。BigQuery 是一個按需付費(fèi)的模式，一個 query 可能就用兩個 slot，就收取這兩個 slot 的費(fèi)用，BigQuery 的存儲成本相對較低，1 TB 的存儲大概 20 美金一個月。

RockSet

第三個系統(tǒng)是 RockSet，大家知道 RocksDB 是一個比較有名的單機(jī) KV 數(shù)據(jù)庫，其存儲引擎的數(shù)據(jù)結(jié)構(gòu)叫 LSM-Tree，LSM-Tree 的核心思想進(jìn)行分層設(shè)計，更冷的數(shù)據(jù)會在越下層。RockSet 把后面的層放在了 S3 的存儲上面，上面的層其實(shí)是用 local disk 或者本地的內(nèi)存來做引擎，天然是一個分層的結(jié)構(gòu)，你的應(yīng)用感知不到下面是一個云盤還是本地磁盤，通過很好的本地緩存讓你感知不到下面云存儲的存在。

所以剛才看了這三個系統(tǒng)，我覺得有幾個特點(diǎn)，一個是首先都是天然分布式的，第二個是構(gòu)建在云的標(biāo)準(zhǔn)服務(wù)上面的，尤其是 S3 和 EBS，第三是 pay as you go，在架構(gòu)里面充分利用了云的彈性能力。我覺得這三點(diǎn)最重要的一點(diǎn)是存儲，存儲系統(tǒng)決定了云上數(shù)據(jù)庫的設(shè)計方向。

為什么 S3 是關(guān)鍵？

在存儲里邊我覺得更關(guān)鍵的可能是 S3。EBS 其實(shí)我們也有研究過，TiDB 第一階段其實(shí)已經(jīng)正在跟 EBS 塊存儲做融合，但從更長遠(yuǎn)的角度來看，我覺得更有意思的方向是在 S3 這邊。

首先第一點(diǎn) S3 非常劃算，價格遠(yuǎn)低于 EBS，第二 S3 提供了 9 個 9 很高的可靠性，第三是具備線性擴(kuò)展的吞吐能力，第四是天然跨云，每一個云上都有 S3 API 的對象存儲服務(wù)。但是 S3 的問題就是隨機(jī)寫入的延遲非常高，但是吞吐性能不錯，所以我們要去利用這個吞吐性能不錯的這個特點(diǎn)，規(guī)避延遲高的風(fēng)險。這是 S3 benchmark 的一個測試，可以看到隨著機(jī)型的提升，吞吐能力也是持續(xù)的提升。

如何解決 Latency 的問題？

如果要解決 S3 的 Latency 問題，這里提供一些思路，比如像 RockSet 那樣用 SSD 或者本地磁盤來做 cache，或者通過 kinesis 寫入日志，來降低整個寫入的延遲。還有數(shù)據(jù)的復(fù)制或者你要去做一些并發(fā)處理等，其實(shí)可以去做 Zero-copy data cloning，也是降低延遲的一些方式。

上述例子有一些共同點(diǎn)都是數(shù)據(jù)倉庫，不知道大家有沒有發(fā)現(xiàn)，為什么都是數(shù)據(jù)倉庫？數(shù)據(jù)倉庫對于吞吐的要求其實(shí)是更高的，對于延遲并不是那么在意，一個 query 可能跑五秒出結(jié)果就行了，不用要求五毫秒之內(nèi)給出結(jié)果，特別是對于一些 Point Lookup 這種場景來說，Shared Nothing 的 database 可能只需要從客戶端的一次 rpc，但是對于計算與存儲分離的架構(gòu)，中間無論如何要走兩次網(wǎng)絡(luò)，這是一個核心的問題。

你可能會說沒有關(guān)系，反正計算和存儲已經(jīng)分離了，大力出奇跡，可以加計算節(jié)點(diǎn)。但是我覺得新思路沒必要這么極端，Aurora 是一個計算存儲分離架構(gòu)，但它是一個單機(jī)數(shù)據(jù)庫，Spanner 是一個純分布式的數(shù)據(jù)庫，純 Shared Nothing 的架構(gòu)并沒有利用到云基礎(chǔ)設(shè)施提供的一些優(yōu)勢。

比如說未來我們的數(shù)據(jù)庫可以做這樣的設(shè)計，在計算層其實(shí)帶著一點(diǎn)點(diǎn)狀態(tài)，因?yàn)槊颗_ EC2 都會帶一個本地磁盤，現(xiàn)在主流的 EC2 都是 SSD，比較熱的數(shù)據(jù)可以在這一層做 Shared Nothing，在這一層去做高可用，在這一層去做隨機(jī)的讀取與寫入。熱數(shù)據(jù)一旦 cache miss，才會落到 S3 上面，可以在 S3 只做后面幾層的數(shù)據(jù)存儲，這種做法可能會帶來問題，一旦穿透了本地 cache，Latency 會有一些抖動。

這種架構(gòu)設(shè)計的好處：首先，擁有對實(shí)時業(yè)務(wù)的數(shù)據(jù)計算親和力，在 local disk 上會有很多數(shù)據(jù)，在這點(diǎn)上很多傳統(tǒng)數(shù)據(jù)庫的一些性能優(yōu)化技巧可以用起來；第二，數(shù)據(jù)遷移其實(shí)會變得很簡單，實(shí)際上底下的存儲是共享的，都在 S3 上面，比如說 A 機(jī)器到 B 機(jī)器的數(shù)據(jù)遷移其實(shí)不用真的做遷移，只要在 B 機(jī)器上讀取數(shù)據(jù)就行了。

這個架構(gòu)的缺點(diǎn)是：第一，緩存穿透了以后，Latency 會變高；第二，計算節(jié)點(diǎn)現(xiàn)在有了狀態(tài)，如果計算節(jié)點(diǎn)掛掉了以后，F(xiàn)ailover 要去處理日志回放的問題，這可能會增加一點(diǎn)實(shí)現(xiàn)的復(fù)雜度。

關(guān)于“云原生數(shù)據(jù)庫設(shè)計的方法是什么”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“云原生數(shù)據(jù)庫設(shè)計的方法是什么”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。