阿里雲自研新一代企業雲數據庫POLARDB背後的技術

摘要： 從2008年到2018年，阿里巴巴的數據庫技術已經發展了10年的時間，10年的時間從AliSQL到RDS，再到自研POLARDB，阿里巴巴數據庫技術獲得了極大的提高。那麼在阿里雲自研新一代企業雲數據庫POLARDB背後有哪些技術呢？本文中，阿里雲數據庫事業部總經理鳴嵩就爲你們進行分享。

從2008年到2018年，阿里巴巴的數據庫技術已經發展了10年的時間，10年的時間從AliSQL到RDS，再到自研POLARDB，阿里巴巴數據庫技術獲得了極大的提高。那麼在阿里雲自研新一代企業雲數據庫POLARDB背後有哪些技術呢？本文中，阿里雲數據庫事業部總經理鳴嵩就爲你們進行分享。

阿里巴巴數據庫發展的十年曆程
首先介紹一下阿里巴巴數據庫發展的十年曆程。阿里巴巴數據庫技術發展源於2008年所作的去「IOE「這件事情。以前阿里巴巴所使用的是商用數據庫好比Oracle，阿里巴巴之因此要作「去O」是由於馬老師看了財務報表以後發現若是繼續使用Oracle等商用數據庫，阿里巴巴的盈利就會補不上數據庫的費用。因而，從2008年開始進行「去O」，當時使用的是MySQL開源分支上自建的一個分支——AliSQL，在其上放了電商場景中的像秒殺之類的各類補丁。基於AliSQL數據庫內核，阿里巴巴在2011年開始研發雲RDS產品，最開始只有MySQL服務，後來增長了SQL Server等數據庫服務。在2018年，阿里雲數據庫團隊推出了自研的POLARDB數據庫產品，POLARDB在2014年開始研發，2017年在北京宣佈開始公測，在2018年4月份正式商業化。與此同時RDS數據庫實例數正式突破20萬，佔國內雲數據庫市場份額的50%。

由於阿里雲RDS具備20萬數據庫實例，在服務這個20萬實例以及背後的8萬客戶的過程當中，阿里雲也發現了用戶使用數據庫過程當中的痛點和需求。所以，阿里雲設計了POLARDB下一代數據庫產品來解決用戶的這些痛點和需求。用戶的痛點一部分和數據庫的能力和容量有關，好比數據庫在單機上最大規模是3T，這仍是由於一臺機器所能插下的SSD盤有限，當用戶的數據存儲量超過3T，那麼用戶就須要本身作分佈式以及分庫分表這些事情，這使得用戶開發的要求大大提升。過去的MySQL寫性能大概是2萬TPS，而這樣的性能對於不少用戶而言是不夠的，那麼如何使一臺數據庫擁有更多的寫入吞吐和讀吞吐成爲了須要解決的問題。此外還有併發的問題，由於用戶在雲上可能有幾百個ECS客戶端共同訪問一個數據庫，那麼如何解決這種幾百個併發之下的數據庫性能也是一個問題。此外，主從複製也是一個問題，在雲上須要兩個實例作主從複製，可是基於Binlog的主從複製卻帶來了不少問題，好比DDL同步時間過長，主從複製中斷會形成數據不一致。第三大類問題與備份相關，當數據庫的容量達到必定程度，備份就成爲一個難題，由於對於塊進行備份須要進行上鎖而後拷貝出來，這樣的過程很是慢。複雜SQL，用戶數據量增大以後，一些報表的需求就會須要執行很長時間，而但願這樣的複雜SQL變成分鐘級的操做。

而今天，阿里雲是帶着用戶對於數據庫的需求來設計下一代數據庫POLARDB的。POLARDB是阿里雲新一代企業級雲原生關係型數據庫，100%兼容MySQL協議，最大容量能夠達到100T。其彈性擴展能力很是強，能夠從10G擴展到100T，能夠從4核擴展到60核，能夠從1個節點擴展到16個節點，是一個擴展性很是強的數據庫集羣。

POLARDB的架構設計
POLARDB總體架構能夠分爲四層，第一層是POLAR Proxy層，這一層解決的問題就是POLARDB是一寫多讀的數據庫，最多能夠達到16個節點，可是讓用戶去管理16個節點就變得很是複雜了。POLAR Proxy層就是讓用戶只看到一個endpoint，只看到一個VIP去訪問數據庫。讀寫分離等均可以在這一層實現。第二層就是關係數據庫引擎層，第三層和第四層就是存儲層，第三層是文件系統，第四層是存儲擴展能力。

接下來將會自底向上介紹POLARDB的設計，最底下是分佈式存儲和文件系統層，這一層是爲了解決容量問題。由於單機容量有限，可是若是想要實現100T的數據庫就必須將數據存儲到多臺機器上面，這就是爲何須要分佈式存儲層的緣由。數據庫不只僅使用存儲，還須要使用文件，所以在存儲層之上還須要構建一層文件系統。在存儲層裏面，數據使用了三副本，提高了數據的可靠性和可用性。在存儲層仍是用了新的硬件，這使得優點更加明顯，使得數據庫性能可以實現數量級上的提高。軟件方面也作了操做系統、用戶態文件系統以及用戶態網絡協議棧等優化。分佈式存儲層使得容量最高能夠擴展到100TB，可使數據庫文件分佈在幾十臺機器裏面，能夠用這些機器的SSD來存儲數據和提升I/O吞吐。其次，共享存儲實現了Serverless計費。以前購買數據庫時就須要預約存儲容量，可是在POLARDB上，由於存儲時分佈式的，所以能夠作到存儲按照使用付費，幫助用戶節省了存儲開銷。實現了無鎖備份，以前的數據庫備份是邏輯備份，有可能鎖表也有可能鎖頁，因此性能很慢。而POLARDB是在存儲層實現快照備份，在決定備份的時候直接生成一個只讀快照，一分鐘以內就實現了百T數據庫的備份。

數據庫引擎層所實現的核心功能是基於一份存儲實現多節點掛載的，一寫多讀能力。這裏介紹一下「一寫多讀」，你們都知道讀寫分離技術，其是說數據庫主實例負責寫，爲了線性擴展讀能力只能在主實例上掛載多個只讀實例，經過將讀邏輯複製到只讀實例中，在只讀實例中提高寫性能，只讀實例越多，整個集羣的讀能力就越強，其缺點是每一個只讀實例都須要一個存儲副本，實例之間經過Binlog複製實現數據拷貝。而在POLARDB中實現了突破，在主實例和多個讀實例之間共享一份存儲，這就意味着存儲成本大大下降，而且只讀實例越多，節省的成本就越多。此外，還使得只讀實例的節點擴充變得更快，由於在生成只讀實例的時候不須要進行數據拷貝，也就是經過技術帶來了極速的彈性擴展能力。

接下來介紹如何實現多個節點共享一份數據庫存儲，其實相似的技術在全球也沒有幾家公司擁有。首先回顧一下數據庫原理，假設本來有5個事務在執行，他們是T1~T5，他們在提交的時候會同步地寫，表明事務的提交。可是以後更新到內存中後並不會馬上刷新到磁盤文件中，也就是說數據文件的更新是異步的。在POLARDB中，因爲刷新數據文件是異步的，所以在共享存儲中僅刷新了T1的狀態，其餘的事務仍然存在於主實例的Buffer Pool裏面。只讀實例會不斷地從磁盤中拉取RedoLog，將狀態不停地拉到內存當中去，將事務保存到內存的Hash表中去，這時候若是有請求下來，若是命中Buffer Pool就讀取，不然會到磁盤中讀取較老的數據文件中的版本號，而後與內存表中的狀態合併以後放到Buffer Pool並返回給用戶。簡單而言，只讀實例經過讀取共享存儲中的Redo文件在內存中維護一個數據庫，這個內存數據庫只維護近期的更新，而又會從存儲中讀取老數據，在內存中完成實時合併，並最終返回給用戶。

前面的過程較爲通用，有些邊緣狀況是數據庫系統所必須考慮的。所謂邊緣狀況就是過去5分鐘內緩存了RedoLog，這些會佔據內存空間，因此須要按期刪除數據。那麼這就出現了一個問題，若是隻讀節點刪除數據的頻率太高，就有可能致使部分RedoLog的丟失。爲了不以上狀況的發生，就須要主實例按期將本身Checkpoint的LSN發送給全部的只讀實例，只讀實例就會注意不可以刪除Checkpoint後的任何RedoLog，避免產生數據空隙。第二個問題就是主庫寫數據文件也不能過於頻繁，由於主庫寫數據過於頻繁，也會致使只讀庫快照隔離出現問題。爲此，從庫須要按期將本身Snapshot的狀態發送給主庫，主庫將全部只讀節點的Snapshot版本取最小做爲本身刷髒的閾值，若是某一個只讀實例的Snapshot版本太老了就能夠將其踢掉。

基於共享存儲實現「一寫多讀」不只帶來了只讀實例的橫向擴展能力，此外還大大地減小了在主實例上執行DDL，只讀實例上執行DDL的時間間隔。今天，POLARDB能夠作到僅須要極短的時間就能夠將DDL同步到全部只讀實例上，主庫在執行DDL的同時，共享存儲中的數據文件也在不斷地進行修改，當主庫執行完DDL以後，只須要將本身庫的元信息進行修改，從庫就當即可見，能達到低於10毫秒的延遲。

在「一寫多讀」之上就是智能的接入層，也就是Proxy層。由於POLARDB能夠有多個節點，可是隻但願用戶看到一個端口進行訪問，這時候就須要Proxy層發揮做用了。Proxy層將負責負載均衡、鏈接管理以及安全管理。經過Proxy層實現了統一的集羣入口，一個endpoint訪問全部的數據節點，而且能夠在其上實現白名單的安全機制。

POLARDB產品進展最後爲你們釋放三個重磅信息。首先，從POLARDB 2017年在北京發佈到2018年宣佈正式商業化，通過一年的發展時間，POLARDB的寫入時間已經比AWS速度快2倍，在各個數量內核的狀況下寫入的TPS都是AWS的2倍。其次，在Proxy層實現了會話單調一致性讀寫分離，這個功能使得用戶感覺不到讀寫分離所帶來的主庫和從庫之間的延遲，使得用戶就像使用一個數據庫同樣地使用POLARDB。第三個亮點就是SQL加速，這是POLARDB團隊在過去一年的時間內服務了200多家企業用戶後獲得的需求。由於用戶的數據庫容量變大了，數據表和數據量都變大了，也須要查詢變得更快。在這樣的需求的啓發下，POLARDB就實現了SQL加速。其原理就是在多個POLARDB只讀實例中併發地加載同一個Snapshot數據，在中間層完成MPP運算。目前的效果是對於TPC-H和TPC-DS能夠完美地支持，對於SQL查詢速度提高了8到14倍，而將來將會進一步加快SQL查詢速度。