新一代雲原生資料庫暢想

雲與分散式是資料庫發展的兩大趨勢，那雲時代下新一代資料庫會是什麼樣的呢？騰訊雲資料庫專家工程師竇賢明講師給大家分享了自己的暢想， 基於冷熱分級儲存與ServerlessDB結合的新一代資料庫 。基於騰訊雲資料庫TDSQL-C PostgreSQL在雲原生這條路上的一些探索，重點從Serverless 資料庫和分級儲存（冷熱分離）的設計與實現兩個方面進行分享。內容主要分為四個部分：

第一部分：介紹雲時代的資料庫的背景；

第二部分：探討雲上資料庫進化的邏輯是什麼、方向是什麼；

第三部分：描述Serverless資料庫具體是什麼樣子；

第四部分：雲原生資料庫在儲存方向上的進一步演進，分級儲存所達到的效果、在冷熱分級等場景下的一些用例。

公眾號福利 ：本期講師課件獲取方式， 騰訊雲資料庫 公眾號後臺回覆“ 5.7核心課件 ”即可。

雲時代的資料庫

在過去一二十年間，整個關係型資料庫行業最大的變化只有兩個，一個是 雲 ，一個是 分散式 。

雲時代，對資料庫產生了一個非常大的一個衝擊，或者說變化。就Gartner近期資料，雲上資料庫的份額也已經趕上並即將超過on promise（傳統方式）的產值。

那雲時代的資料庫是一個什麼樣子呢 ？以騰訊雲的TencentDB for PostgreSQL為例。雲資料庫的第一個階段，其實是在將傳統資料庫搬到雲上來。首先，最開始部分是基礎環境，比如說硬體資源、網路、儲存之類；在此基礎上，進行一些虛擬化，這些是雲本身具備的能力；在使用者側，資源準備好了之後，是一個資源的管理分配和執行環境的準備；然後是做雲資料庫託管的一些事情，包括部署、HA、備份恢復等，還有監控這些；那整體上還是一個PaaS平臺這麼一個事情。這個過程中，整體來講還是將傳統的主備搬到一個雲環境這麼一個過程，其實並沒有對資料庫的核心或者說資料庫的架構產生一些根本性的變化。

這其實是在過去幾年雲資料庫或雲的一個演進的第一階段，把原來的資料庫運維，以雲的方式託管起來、在雲上使用起來。

那在這期間是怎樣一個實現方式呢？首先，會有一個雲資料庫的一個部署，即例項程序執行在虛擬機器裡面、儲存則放在一個雲盤儲存上；然後會建立一個備庫，主備之間通過Replication實現資料的複製，通過兩份完整的資料節點實現高可用。這一點，與當前物理環境並沒有什麼本質上的變化，即 一主一備 的方式。

即使如此（簡單的實現），雲資料庫相比傳統資料庫仍然會有很多的優點。

第一， 成本更低 ，當前主要是雲本身的特質帶來的；第二點就是 擴容能力更好 ，比如說它擴容能力好的是在於說儲存這裡可以動態擴容，計算這裡可以更為輕量的擴縮容；第三點，是 體驗上也有非常大的提升 。

然而，仍然有些問題沒有解決，尤其是在站在雲的視角來看。當有越來越多的資料庫例項跑在一起的時候，發現這個 成本的增長是線性 的，成本上是沒有去得到一些根本性的降低。

就一主一備的情況來說，有兩份完全一樣的資料；當我們再新加一個RO（Read Only節點，僅用於讀請求）的時候，還會再加一份完整的資料。儲存成本沒有根本性的收斂，根據RO的數量線性增長。

而另外一種情況， 網路儲存 成為一個瓶頸。再拿這個例子來說，每次讀寫都會對網路形成一個吞吐，且隨著RO數量增加也是一個線性增長，對網路總流量造成較大的壓力。

RO節點（Replica）的建設時間成本也是一個問題 。多新增一個RO節點，就是多一份資料，是完整的一個複製（對應儲存上的三副本），複製時間較長。

雲原生進化

雲原生資料庫（ Cloud Native Database ）的提出，是 為了解決原來傳統架構下無法解決的這些問題 ，基於雲基礎設施重新設計與實現所提出的一個解決思路。

那其中核心的解決思路是什麼？答案就是 存算分離 。

可以思考一個問題：主節點和 RO 節點各自有一份完整的儲存，且各自都有三副本。為什麼我們這些節點不共用同一份資料呢？這裡很容易就想到一點，就是我們把所有節點的資料都放在遠端分散式儲存上，不再本地存放。這樣的話，儲存就可以實現僅有一份資料（三個副本），而計算仍然是多節點。

把資料庫內部拆開來看，基本上來講分為兩部分：一個是 儲存層 ，一個是 計算層 。計算層一般包含詞法解析、語法解析、語義解析、查詢重寫、優化器等。下一層則是資料快取，相對設計邏輯比較簡單一些，這部分一般不單獨列；中間這個事務層，保證資料儲存、讀取的正確性；最下層storage層負責跟實際的儲存硬體打交道。

既然要把所有節點的資料放在同一個分散式儲存（租戶）上，就需要將資料庫核心的引擎和儲存部分拆開到兩個地方執行，儲存的部分放在分散式儲存系統內執行，把引擎的部分放在計算節點中執行。表現為所有的RW、RO都沒有實際的資料，只需要記憶體和CPU的資源拉起來即可，這個時候RO啟動的效率就非常高，本身就很輕。RO則通過Replication從RW拿到更新的修改，去更新它記憶體中的快取。

那前面也有講到網路成為瓶頸的問題，需要分別針對 RW和RO來說明。

針對 RW ，有一個 WAL的概念，即Write Ahead Log，所有資料的變更都會記錄在這裡。這裡做一個極端假設，假如從資料庫被初始化之後所有的WAL都被保留、且有一臺非常非常強大的計算機，在每次讀取資料時，都將最開始到最新的所有WAL全部重放到當前時刻，其實是可以得到與當前資料庫中完全一致的資料。這一點，可以描述為Log is Database。

如果 WAL 能夠對應一份完整的資料，那麼在寫入儲存時，可以不寫入資料部分、僅寫入 WAL。儲存層在收到WAL之後，基於儲存上已有的資料部分，對WAL進行不斷的重放，就可以實現資料不斷的更新，保證資料的一致性。這裡具體的實現較為複雜，不再作展開。 達到的效果就是，至少減少一半的網路流量 。

RO 剛才已經簡單說過一些，在通過 Replication獲取到WAL之後，會對快取中資料進行更新。當需要從儲存上讀取資料時，根據該資料頁的時間戳，將其後的WAL更新上去，也因此，RO需要在記憶體中快取一份近期的WAL，得到一個保證一致性的最新資料頁。

整體來講，通過以上的機制，實現資料儲存在分散式儲存上主備節點採用同一份儲存，達到RO節點增加儲存成本不變的效果。也因此，RO的數量支援最大到15個。

儲存計算分離之後，剛開始優勢未必特別明顯，在使用上和前面的雲資料庫沒有本質的區別，使用者體驗基本一致。效果會隨著使用的加深而逐步體現出來。

第一， 擴縮容的效率完全不一樣 ，原本在擴容的時候，有可能出現空間不夠需要遷移，導致時間成本非常高。計算變得特別輕，可以快速拉起、關閉，遷移效率極高，不用擔心擴容時需要遷移的情況。

可用性、可靠性 等方面，因為所有的狀態都儲存在分散式儲存中，計算節點的啟停（可用性），不會影響儲存上資料的可靠性，因此在計算節點出現故障時，可以隨意關閉老節點、啟動新節點，不用擔心會丟失資料，可用性方面達到了較高的保證；儲存上資料有三副本，保證了資料的可靠性；且多個節點共用同一份儲存，整體成本也更低。

針對計算來說，計算節點被做得輕量、可以便捷地啟停，當這份便捷性達到一定水平的時候，就會引起質變。

極致彈性

正常來講，業務有高峰低谷，比如訂餐系統。一家餐飲公司的訂單系統，肯定是有高峰和低谷，基本上是三餐的時候比較高，夜裡幾乎為零。那沒有業務在執行的時候，為什麼還要這個計算節點付錢？在傳統方式下，需要準備一臺物理機； 在雲資料庫形勢下，則以例項為單位，計費的粒度仍然較粗。那怎麼去做呢 ？

這裡可以考慮這樣的產品形態，在使用者端呢， 計算節點在不用時不計費，在真正使用時再拉起並開始計費；且擴容也不再需要使用者操作，由後端自動根據負載來做調整，在不用時自動將資源佔用降為0 。儲存空間也類似。原本客戶在購買了一個100GB的儲存空間，會一直按100GB來計算費用，但實際可能並沒有真正用到那麼多。這裡可以實現為僅僅為實際佔用的空間付費。

正常情況下，資料庫例項處於休眠狀態；當SQL到達時，將計算節點拉起來，然後執行SQL。同時，RO也可以加進去一起參與，就是可以一次拉起一個或者多個計算節點，在這些節點上做負載均衡。當沒有SQL在執行超過一定時間，比如超過五秒鐘、十秒鐘沒有SQL在執行，計算節點可以直接關閉，也因為業務沒有在執行，也感知不到負面影響。而 計費成本上，則獲得較大的降低 。

舉例來說，比如餐廳運營的高峰時間段（如中午時間），SQL會一直進來一直使用，後端計算節點則持續存在。當資源用滿達到一定閾值，將自動升配；那中午過後，不再有請求，計算節點則會被關閉、也不再計費，計算成本降為0。

演進到當前， 計算節點最細粒度可以做到一秒級別的計費 。據內部資料來看，有不少客戶的業務一天只花可能不到幾塊錢、甚至幾毛錢都有，一個月可能就花幾十塊錢。而像傳統物理機的方式起碼十萬起，雲資料庫也要每月幾百、幾千塊。這是一個巨大的飛越！

分級儲存

花分兩朵，各表一支。前面是計算節點的演進， 儲存節點又該如何演進 ？

儲存的演進持續在進行，比如效能、壓縮等。此處僅針對資料的儲存成本。資料大致可以分為幾層：熱資料、溫資料、冷資料。熱資料放在記憶體快取裡，價格最貴、效能最好。然後，大量的資料放在分散式儲存上，那冷資料該如何處理？

熱、溫、冷的劃分，主要基於的是訪問頻率、量和效能要求。冷資料，一般定義不經常訪問的資料，比如歷史訂單、歷史日誌等。當前 TDSQL-C PostgreSQL的儲存規模支援最高128TB，絕大部分情況下足夠業務使用。冷資料比較多、不常訪問，放在 TDSQL-C PostgreSQL的儲存中又較貴，該如何處理？

答案是COS。COS是騰訊雲的 物件儲存服務 ，資料儲存成本要低於TDSQL-C PostgreSQL的高效能儲存盤。溫熱的資料，或者說時刻需要用到的資料，還是要放在分散式儲存上正常使用，但針對時間較老、不大訪問的冷資料，可以放在COS中，並通過同樣的一套SQL語言、表結構來訪問。

為實現這一點，TDSQL-C PostgreSQL 封裝了COS的訪問介面 ，通過與常規資料表完全一樣的使用方式，達到對COS上資料檔案進行訪問的目的。

這裡舉一個具體的例子：第一步，建立一個Server，指定COS的資訊，包括id、key、endpoint、檔案等；第二步，在該Server上建立表；然後就可以通過讀這張表實現對COS上檔案的讀取。異構儲存的訪問，基本上分為三部分，計算、元資料（表結構等）、儲存格式。Server/表定義這裡，即實現了元資料的維護，儲存格式上當前支援CSV。具體的執行邏輯可以通過執行計劃檢視。

另外一個例子，是更復雜的一些用法，比如：Table a和Table b都是本地表，資料存放在儲存上，再建一張COS表，就可以直接對這三張表做關聯運算。這比較適合報表類的場景，比如以賬戶資訊為維度統計歷史訂單類的報表。

還有一個例子，就是 分割槽表 。還是Table a和Table b，放在分散式儲存上，一張 COS表，三張表放在一起作為一張分割槽表的三張子表。PostgreSQL有非常強大的分析能力，當基於分割槽欄位做過濾的時候，會根據分割槽欄位做裁剪；再配合分割槽表的Time to live的功能，比如Table a和Table b是正常的按時間分割槽，Table c則是 COS 表，可以實現同樣一張（分割槽）表，部分放在儲存、部分放在COS 上的效果。

專家答疑

1. 儲存計算分離之前PostgreSQL用的什麼高可用方案？

答：原先一主一備形態下，高可用方案是內部自研的一套，基本分為探測、策略和執行三個步驟。

2. 主庫和備庫要做到同步，那資源豈不是很浪費？

答：主庫和備庫的資料同步，主要是為了解決 RO、備庫上記憶體中熱資料的持續更新，一定程度上是為了提升備庫的效能和資料一致性。如果不在RO上保持快取，效能會較為糟糕；若保留了快取，則需要對這些快取持續更新，以保證資料一致。

3. 更新操作多的情況呢？

答：主備間複製採用的是物理複製的方式，只是將資料頁上的變更部分發送到備庫上，在資料頁上重做，這種方式較為高效、延遲較低。

4. RO先讀取資料頁，再應用WAL，會不會出現讀延遲？

答：會有一定延遲，但這不會成為一個問題。

主備方式在當前硬體、網路情況下，必然會存在一定延遲，收斂在一定範圍內即可。若要保證完全無延遲，也不是做不到，代價過於高昂、不值得；

WAL 的重放改為以頁為單位，相比原來的方式更為高效，延遲反而更低；

主備間應該通過 Proxy 實現全域性一致性；

通過以上措施綜合解決主備延遲帶來的影響。

5. 目前是一個RW，多個RO，怎麼才能擴充套件寫能力呢？

答：當前寫能力很多時候不會成為一個瓶頸。在僅寫入 WAL 之後，網路IO是制約寫能力的核心因素之一，當前最新可以到達 100Gb/s 網路，在儲存側又被分發到多臺機器上，少有多業務能將這兩個地方都打到瓶頸上。當趨勢出現的時候，我們也可以考慮採用多寫的方式來承接，這就是另外一個故事了。

6. 既然是share儲存了，為什麼還要master到replica的複製？

答：參考問題二，主要是為了解決RO上的查詢效能問題，需要在快取中保持資料。

7. 存算分離後怎麼解決謂詞下沉技術和儲存節點計算瓶頸問題？所有資料都從儲存拉到計算節點計算？

答：這裡其實不用過於擔優效能的問題。比如，現在有一個RW15個RO，一臺機器機器大約 96vCore，16臺加起來一共1536，很難有業務能吃掉這麼多CPU，計算資源在很多時候是足夠的。

但謂詞下推確實也適合這種架構，減少網路開銷，實現的方式是將where條件的描述下發到儲存層，儲存層在返回資料之前對資料進行過濾。其中比較難的課題是儲存上計算資源的排程問題，這時候要看儲存機的硬體條件。這也是儲存計算分離一個價值點，儲存層可以針對儲存層定製相關的機型，可能就要去配合一些新硬體，比如FPGA、GPU之類的

8. 沒明白存算分離的意思，儲存單獨儲存，計算的話指的是每次查詢都需要新拉起一個例項去儲存中拉取資料麼？

答：是也不是。這裡可以保持一個例項一直執行，這樣有部分資料是在記憶體中，沒有用到儲存上的資料時不用從儲存上讀取，沒有的時候從儲存上讀。缺點是，計算節點會持續計費。

核心還是成本。

這裡比較好的玩法，是在每次執行SQL的時候才拉起例項，在超過閾值時間不再使用後，將其關閉，以節省資源。Serverless形態解決的是計費和排程的問題，儲存和計算分離之後，儲存層可以單獨計費、計算成本按實際用量計算，可以極大節省成本。

對於很多業務來講，尤其是有高峰低谷的業務，有非常大的成本降低的效果。並且，也解決了雲資料庫架構上沒有解決的問題，從而實現更高可用性、更好的使用者體驗。

9.分級儲存，如果資料放到物件儲存上面，這種儲存方式只適合儲存歸檔資料，不適合有update，delete的資料。

答：這個問題比較專業。 分 級儲存只解決一類的場景，資料量比較大、不改不刪、偶爾讀取，比如歸檔類的資料，放在資料庫內這種高效能儲存上成本又高，說到底還是成本問題。 比如有很多行業有安全性的要求，要求至少保留兩年以上的歷史資料； 而這些資料都不會訪問，但時不時的還會查一下。

這個時候，如果用另外一套儲存、另外一套引擎、另外一套機器，維護成本是相當高的。我們提供這種方式，一部分相對冷的資料放到COS來，但資料的管理和維護還是在資料庫中。因此，不適合刪改較多的場景。

10.計算節點下的儲存是不是有優化的方向，比如WAL放在計算節點上，用高速裝置進行優化？

答：存算分離方案實現的一個核心思想，就是 Log is Database。通過將 WAL 寫到儲存、並在儲存中存放，達到資料寫入儲存的目的。

我理解這裡的問題是，是否可以先把 WAL 寫入本地、然後非同步化寫入儲存中？這是一個有意思的思路，但這假設了一個前提，就是本地盤比分散式儲存的吞吐能力更強。在當前的網路、硬體條件下，這個假設已經不一定成立了。畢竟現在100Gb/s的網路已經可以作為標配，再有RDMA的加持，網路吞吐已經高於本地盤；且儲存側的寫入會分佈在多個節點上，也提升了吞吐。

關於作者

竇賢明，騰訊雲資料庫專家工程師，從事雲資料庫產品研發多年，從零到一主導研發多款雲資料庫、雲原生資料庫。目前負責 TDSQL-C PostgreSQL、TencentDB For PostgreSQL 的全棧研發工作，和TDSQL-C MySQL 的產品化研發工作。

﹀

﹀

﹀

-- 更多精彩 --

↓ ↓ 點選 閱讀原文 ，瞭解更多優惠