從2008年到2018年，阿里巴巴的數(shù)據(jù)庫(kù)技術(shù)已經(jīng)發(fā)展了10年的時(shí)間，10年的時(shí)間從AliSQL到RDS，再到自研POLARDB，阿里巴巴數(shù)據(jù)庫(kù)技術(shù)得到了極大的提升。那么在阿里云自研新一代企業(yè)云數(shù)據(jù)庫(kù)POLARDB背后有哪些技術(shù)呢？本文中，阿里云數(shù)據(jù)庫(kù)事業(yè)部總經(jīng)理鳴嵩就為大家進(jìn)行分享。?

阿里巴巴數(shù)據(jù)庫(kù)發(fā)展的十年歷程

首先介紹一下阿里巴巴數(shù)據(jù)庫(kù)發(fā)展的十年歷程。阿里巴巴數(shù)據(jù)庫(kù)技術(shù)發(fā)展源于2008年所做的去“IOE“這件事情。之前阿里巴巴所使用的是商用數(shù)據(jù)庫(kù)比如Oracle，阿里巴巴之所以要做“去O”是因?yàn)轳R老師看了財(cái)務(wù)報(bào)表之后發(fā)現(xiàn)如果繼續(xù)使用Oracle等商用數(shù)據(jù)庫(kù)，阿里巴巴的盈利就會(huì)補(bǔ)不上數(shù)據(jù)庫(kù)的費(fèi)用。于是，從2008年開(kāi)始進(jìn)行“去O”，當(dāng)時(shí)使用的是MySQL開(kāi)源分支上自建的一個(gè)分支——AliSQL，在其上放了電商場(chǎng)景中的像秒殺之類的各種補(bǔ)丁。基于AliSQL數(shù)據(jù)庫(kù)內(nèi)核，阿里巴巴在2011年開(kāi)始研發(fā)云RDS產(chǎn)品，最開(kāi)始只有MySQL服務(wù)，后來(lái)增加了SQL Server等數(shù)據(jù)庫(kù)服務(wù)。在2018年，阿里云數(shù)據(jù)庫(kù)團(tuán)隊(duì)推出了自研的POLARDB數(shù)據(jù)庫(kù)產(chǎn)品，POLARDB在2014年開(kāi)始研發(fā)，2017年在北京宣布開(kāi)始公測(cè)，在2018年4月份正式商業(yè)化。與此同時(shí)RDS數(shù)據(jù)庫(kù)實(shí)例數(shù)正式突破20萬(wàn)，占國(guó)內(nèi)云數(shù)據(jù)庫(kù)市場(chǎng)份額的50%。

因?yàn)榘⒗镌芌DS具有20萬(wàn)數(shù)據(jù)庫(kù)實(shí)例，在服務(wù)這個(gè)20萬(wàn)實(shí)例以及背后的8萬(wàn)客戶的過(guò)程中，阿里云也發(fā)現(xiàn)了用戶使用數(shù)據(jù)庫(kù)過(guò)程中的痛點(diǎn)和需求。因此，阿里云設(shè)計(jì)了POLARDB下一代數(shù)據(jù)庫(kù)產(chǎn)品來(lái)解決用戶的這些痛點(diǎn)和需求。用戶的痛點(diǎn)一部分和數(shù)據(jù)庫(kù)的能力和容量有關(guān)，比如數(shù)據(jù)庫(kù)在單機(jī)上最大規(guī)模是3T，這還是因?yàn)橐慌_(tái)機(jī)器所能插下的SSD盤有限，當(dāng)用戶的數(shù)據(jù)存儲(chǔ)量超過(guò)3T，那么用戶就需要自己做分布式以及分庫(kù)分表這些事情，這使得用戶開(kāi)發(fā)的要求大大提高。過(guò)去的MySQL寫性能大概是2萬(wàn)TPS，而這樣的性能對(duì)于很多用戶而言是不夠的，那么如何使一臺(tái)數(shù)據(jù)庫(kù)擁有更多的寫入吞吐和讀吞吐成為了需要解決的問(wèn)題。此外還有并發(fā)的問(wèn)題，因?yàn)橛脩粼谠粕峡赡苡袔装賯€(gè)ECS客戶端共同訪問(wèn)一個(gè)數(shù)據(jù)庫(kù)，那么如何解決這種幾百個(gè)并發(fā)之下的數(shù)據(jù)庫(kù)性能也是一個(gè)問(wèn)題。

此外，主從復(fù)制也是一個(gè)問(wèn)題，在云上需要兩個(gè)實(shí)例做主從復(fù)制，但是基于Binlog的主從復(fù)制卻帶來(lái)了很多問(wèn)題，比如DDL同步時(shí)間過(guò)長(zhǎng)，主從復(fù)制中斷會(huì)造成數(shù)據(jù)不一致。第三大類問(wèn)題與備份相關(guān)，當(dāng)數(shù)據(jù)庫(kù)的容量達(dá)到一定程度，備份就成為一個(gè)難題，因?yàn)閷?duì)于塊進(jìn)行備份需要進(jìn)行上鎖然后拷貝出來(lái)，這樣的過(guò)程非常慢。復(fù)雜SQL，用戶數(shù)據(jù)量增大之后，一些報(bào)表的需求就會(huì)需要執(zhí)行很長(zhǎng)時(shí)間，而希望這樣的復(fù)雜SQL變成分鐘級(jí)的操作。

而今天，阿里云是帶著用戶對(duì)于數(shù)據(jù)庫(kù)的需求來(lái)設(shè)計(jì)下一代數(shù)據(jù)庫(kù)POLARDB的。POLARDB是阿里云新一代企業(yè)級(jí)云原生關(guān)系型數(shù)據(jù)庫(kù)，100%兼容MySQL協(xié)議，最大容量可以達(dá)到100T。其彈性擴(kuò)展能力非常強(qiáng)，可以從10G擴(kuò)展到100T，可以從4核擴(kuò)展到60核，可以從1個(gè)節(jié)點(diǎn)擴(kuò)展到16個(gè)節(jié)點(diǎn)，是一個(gè)擴(kuò)展性非常強(qiáng)的數(shù)據(jù)庫(kù)集群。

POLARDB的架構(gòu)設(shè)計(jì)

POLARDB整體架構(gòu)可以分為四層，第一層是POLAR Proxy層，這一層解決的問(wèn)題就是POLARDB是一寫多讀的數(shù)據(jù)庫(kù)，最多可以達(dá)到16個(gè)節(jié)點(diǎn)，但是讓用戶去管理16個(gè)節(jié)點(diǎn)就變得非常復(fù)雜了。POLAR Proxy層就是讓用戶只看到一個(gè)endpoint，只看到一個(gè)VIP去訪問(wèn)數(shù)據(jù)庫(kù)。讀寫分離等都可以在這一層實(shí)現(xiàn)。第二層就是關(guān)系數(shù)據(jù)庫(kù)引擎層，第三層和第四層就是存儲(chǔ)層，第三層是文件系統(tǒng)，第四層是存儲(chǔ)擴(kuò)展能力。

接下來(lái)將會(huì)自底向上介紹POLARDB的設(shè)計(jì)，最底下是分布式存儲(chǔ)和文件系統(tǒng)層，這一層是為了解決容量問(wèn)題。因?yàn)閱螜C(jī)容量有限，但是如果想要實(shí)現(xiàn)100T的數(shù)據(jù)庫(kù)就必須將數(shù)據(jù)存儲(chǔ)到多臺(tái)機(jī)器上面，這就是為什么需要分布式存儲(chǔ)層的原因。數(shù)據(jù)庫(kù)不僅僅使用存儲(chǔ)，還需要使用文件，因此在存儲(chǔ)層之上還需要構(gòu)建一層文件系統(tǒng)。在存儲(chǔ)層里面，數(shù)據(jù)使用了三副本，提升了數(shù)據(jù)的可靠性和可用性。在存儲(chǔ)層還是用了新的硬件，這使得優(yōu)勢(shì)更加明顯，使得數(shù)據(jù)庫(kù)性能能夠?qū)崿F(xiàn)數(shù)量級(jí)上的提升。軟件方面也做了操作系統(tǒng)、用戶態(tài)文件系統(tǒng)以及用戶態(tài)網(wǎng)絡(luò)協(xié)議棧等優(yōu)化。

分布式存儲(chǔ)層使得容量最高可以擴(kuò)展到100TB，可以使數(shù)據(jù)庫(kù)文件分布在幾十臺(tái)機(jī)器里面，可以用這些機(jī)器的SSD來(lái)存儲(chǔ)數(shù)據(jù)和提高I/O吞吐。其次，共享存儲(chǔ)實(shí)現(xiàn)了Serverless計(jì)費(fèi)。之前購(gòu)買數(shù)據(jù)庫(kù)時(shí)就需要預(yù)定存儲(chǔ)容量，但是在POLARDB上，因?yàn)榇鎯?chǔ)時(shí)分布式的，因此可以做到存儲(chǔ)按照使用付費(fèi)，幫助用戶節(jié)省了存儲(chǔ)開(kāi)銷。實(shí)現(xiàn)了無(wú)鎖備份，之前的數(shù)據(jù)庫(kù)備份是邏輯備份，有可能鎖表也有可能鎖頁(yè)，所以性能很慢。而POLARDB是在存儲(chǔ)層實(shí)現(xiàn)快照備份，在決定備份的時(shí)候直接生成一個(gè)只讀快照，一分鐘之內(nèi)就實(shí)現(xiàn)了百T數(shù)據(jù)庫(kù)的備份。

數(shù)據(jù)庫(kù)引擎層所實(shí)現(xiàn)的核心功能是基于一份存儲(chǔ)實(shí)現(xiàn)多節(jié)點(diǎn)掛載的，一寫多讀能力。這里介紹一下“一寫多讀”，大家都知道讀寫分離技術(shù)，其是說(shuō)數(shù)據(jù)庫(kù)主實(shí)例負(fù)責(zé)寫，為了線性擴(kuò)展讀能力只能在主實(shí)例上掛載多個(gè)只讀實(shí)例，通過(guò)將讀邏輯復(fù)制到只讀實(shí)例中，在只讀實(shí)例中提升寫性能，只讀實(shí)例越多，整個(gè)集群的讀能力就越強(qiáng)，其缺點(diǎn)是每個(gè)只讀實(shí)例都需要一個(gè)存儲(chǔ)副本，實(shí)例之間通過(guò)Binlog復(fù)制實(shí)現(xiàn)數(shù)據(jù)拷貝。而在POLARDB中實(shí)現(xiàn)了突破，在主實(shí)例和多個(gè)讀實(shí)例之間共享一份存儲(chǔ)，這就意味著存儲(chǔ)成本大大降低，并且只讀實(shí)例越多，節(jié)省的成本就越多。此外，還使得只讀實(shí)例的節(jié)點(diǎn)擴(kuò)充變得更快，因?yàn)樵谏芍蛔x實(shí)例的時(shí)候不需要進(jìn)行數(shù)據(jù)拷貝，也就是通過(guò)技術(shù)帶來(lái)了極速的彈性擴(kuò)展能力。

接下來(lái)介紹如何實(shí)現(xiàn)多個(gè)節(jié)點(diǎn)共享一份數(shù)據(jù)庫(kù)存儲(chǔ)，其實(shí)類似的技術(shù)在全球也沒(méi)有幾家公司擁有。首先回顧一下數(shù)據(jù)庫(kù)原理，假設(shè)原本有5個(gè)事務(wù)在執(zhí)行，他們是T1~T5，他們?cè)谔峤坏臅r(shí)候會(huì)同步地寫，代表事務(wù)的提交。但是之后更新到內(nèi)存中后并不會(huì)立刻刷新到磁盤文件中，也就是說(shuō)數(shù)據(jù)文件的更新是異步的。在POLARDB中，由于刷新數(shù)據(jù)文件是異步的，因此在共享存儲(chǔ)中僅刷新了T1的狀態(tài)，其他的事務(wù)仍然存在于主實(shí)例的Buffer Pool里面。

只讀實(shí)例會(huì)不斷地從磁盤中拉取RedoLog，將狀態(tài)不停地拉到內(nèi)存當(dāng)中去，將事務(wù)保存到內(nèi)存的Hash表中去，這時(shí)候如果有請(qǐng)求下來(lái)，如果命中Buffer Pool就讀取，否則會(huì)到磁盤中讀取較老的數(shù)據(jù)文件中的版本號(hào)，然后與內(nèi)存表中的狀態(tài)合并之后放到Buffer Pool并返回給用戶。簡(jiǎn)單而言，只讀實(shí)例通過(guò)讀取共享存儲(chǔ)中的Redo文件在內(nèi)存中維護(hù)一個(gè)數(shù)據(jù)庫(kù)，這個(gè)內(nèi)存數(shù)據(jù)庫(kù)只維護(hù)近期的更新，而又會(huì)從存儲(chǔ)中讀取老數(shù)據(jù)，在內(nèi)存中完成實(shí)時(shí)合并，并最終返回給用戶。

前面的過(guò)程較為通用，有些邊緣情況是數(shù)據(jù)庫(kù)系統(tǒng)所必須考慮的。所謂邊緣情況就是過(guò)去5分鐘內(nèi)緩存了RedoLog，這些會(huì)占據(jù)內(nèi)存空間，所以需要定期刪除數(shù)據(jù)。那么這就出現(xiàn)了一個(gè)問(wèn)題，如果只讀節(jié)點(diǎn)刪除數(shù)據(jù)的頻率過(guò)高，就有可能導(dǎo)致部分RedoLog的丟失。為了避免以上情況的發(fā)生，就需要主實(shí)例定期將自己Checkpoint的LSN發(fā)送給所有的只讀實(shí)例，只讀實(shí)例就會(huì)注意不能夠刪除Checkpoint后的任何RedoLog，避免產(chǎn)生數(shù)據(jù)空隙。

第二個(gè)問(wèn)題就是主庫(kù)寫數(shù)據(jù)文件也不能過(guò)于頻繁，因?yàn)橹鲙?kù)寫數(shù)據(jù)過(guò)于頻繁，也會(huì)導(dǎo)致只讀庫(kù)快照隔離出現(xiàn)問(wèn)題。為此，從庫(kù)需要定期將自己Snapshot的狀態(tài)發(fā)送給主庫(kù)，主庫(kù)將所有只讀節(jié)點(diǎn)的Snapshot版本取最小作為自己刷臟的閾值，如果某一個(gè)只讀實(shí)例的Snapshot版本太老了就可以將其踢掉。

基于共享存儲(chǔ)實(shí)現(xiàn)“一寫多讀”不僅帶來(lái)了只讀實(shí)例的橫向擴(kuò)展能力，此外還大大地減少了在主實(shí)例上執(zhí)行DDL，只讀實(shí)例上執(zhí)行DDL的時(shí)間間隔。今天，POLARDB可以做到僅需要極短的時(shí)間就可以將DDL同步到所有只讀實(shí)例上，主庫(kù)在執(zhí)行DDL的同時(shí)，共享存儲(chǔ)中的數(shù)據(jù)文件也在不斷地進(jìn)行修改，當(dāng)主庫(kù)執(zhí)行完DDL之后，只需要將自己庫(kù)的元信息進(jìn)行修改，從庫(kù)就立即可見(jiàn)，能達(dá)到低于10毫秒的延遲。

在“一寫多讀”之上就是智能的接入層，也就是Proxy層。因?yàn)镻OLARDB可以有多個(gè)節(jié)點(diǎn)，但是只希望用戶看到一個(gè)端口進(jìn)行訪問(wèn)，這時(shí)候就需要Proxy層發(fā)揮作用了。Proxy層將負(fù)責(zé)負(fù)載均衡、連接管理以及安全管理。通過(guò)Proxy層實(shí)現(xiàn)了統(tǒng)一的集群入口，一個(gè)endpoint訪問(wèn)所有的數(shù)據(jù)節(jié)點(diǎn)，并且可以在其上實(shí)現(xiàn)白名單的安全機(jī)制。

POLARDB產(chǎn)品進(jìn)展

最后為大家釋放三個(gè)重磅信息。
首先，從POLARDB 2017年在北京發(fā)布到2018年宣布正式商業(yè)化，經(jīng)過(guò)一年的發(fā)展時(shí)間，POLARDB的寫入時(shí)間已經(jīng)比AWS速度快2倍，在各個(gè)數(shù)量?jī)?nèi)核的情況下寫入的TPS都是AWS的2倍。

其次，在Proxy層實(shí)現(xiàn)了會(huì)話單調(diào)一致性讀寫分離，這個(gè)功能使得用戶感受不到讀寫分離所帶來(lái)的主庫(kù)和從庫(kù)之間的延遲，使得用戶就像使用一個(gè)數(shù)據(jù)庫(kù)一樣地使用POLARDB。

第三個(gè)亮點(diǎn)就是SQL加速，這是POLARDB團(tuán)隊(duì)在過(guò)去一年的時(shí)間內(nèi)服務(wù)了200多家企業(yè)用戶后得到的需求。因?yàn)橛脩舻臄?shù)據(jù)庫(kù)容量變大了，數(shù)據(jù)表和數(shù)據(jù)量都變大了，也需要查詢變得更快。在這樣的需求的啟發(fā)下，POLARDB就實(shí)現(xiàn)了SQL加速。其原理就是在多個(gè)POLARDB只讀實(shí)例中并發(fā)地加載同一個(gè)Snapshot數(shù)據(jù)，在中間層完成MPP運(yùn)算。目前的效果是對(duì)于TPC-H和TPC-DS可以完美地支持，對(duì)于SQL查詢速度提升了8到14倍，而未來(lái)將會(huì)進(jìn)一步加快SQL查詢速度。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的阿里云自研新一代企业云数据库POLARDB背后的技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。