一、概述云原生數據庫

（一）云計算是數字化的基礎設施

眾所周知，目前云計算已經成為數字化的基礎設施，整個社會也在數字化。數字化滲透進我們的日常生活中，除了衣食住行，還包括教育、醫療、游戲等。

以醫療領域為例，早些年去醫院，不管是驗血還是拍胸片，一定是要去取紙質報告，然后打一張塑料的胸片圖。但是最近一兩年，除了三甲醫院，其他醫院也基本是通過網上向患者提供無論是報告還是胸片之類的材料，醫療領域數字化現象十分明顯。

而這些數據全部都數字化以后，面臨一個非常大的問題，它在哪些平臺承載，怎么樣承載？阿里云是其中非常重要的一個環節，數據庫在數字化進程中承載了數據的生產、集成、實時處理和分析的整套流程。在整個數據庫周邊，可能還有硬件、安全、彈性計算等能力，這些大大小小的東西最終組成阿里云這個平臺。

（二）什么是云原生數據庫技術

云計算在重塑數據庫技術與商業。

在數字化背景下，我們有許多思考。

數據庫跟以前那有什么不一樣呢？什么是所謂的云原生數據庫呢？作為使用數據庫的開發者，對數據庫的需求有什么變化？如今使用數據庫我們一般會提什么樣的訴求？

如今，上層的業務變化非常快，包括以前阿里巴巴淘寶內部其實也有同樣的問題。業務的快速變化讓開發者面臨一個非常大的挑戰，就是要非常快速地適應變化。在云普及之前，這個過程其實還是比較慢的，從構建服務器，然后網絡打好，安裝操作系統和數據庫等，整個流程非常長。

對數據庫的訴求，總結起來可能有以下幾個。

第一個就是我們希望更專注在業務開發上，不要把太多時間放在底層的硬件、軟件、機房、網絡等設施的配置上。

第二個是開箱即用的，我們希望數據庫創建好了可以直接使用，不需要再去做配置、優化等非常繁瑣耗時且專業性強的事情。

第三個是安全可信，把數據放在第三方平臺上，安全可信是一個非常基本的要求。

第四個是開放兼容，我們不希望被哪個云廠商鎖定，希望能非常自由地遷移進來和遷移出去。

第五個是海量擴展，隨著業務爆發式的增長，系統壓力很快就會變成原來的數倍甚至數十倍。在這種情況下，如果沒有一個很好的橫向、縱向擴展的數據庫系統，那么很難支撐業務正常運行，處理起來就會非常棘手。

第六個是全球化。中國很多游戲廠商在海外的拓展和推廣做得非常不錯，尤其是在東南亞一帶，另外也有一些游戲在歐美日本獲得了非常大的成功，所以現在有些開發者也面臨著全球化的訴求，作為數據庫的基礎設施，應該思考如何提供全球化的能力。

第七個是持續可用，我們原來自己做一套數據庫系統，持續可用也是核心考慮之一。

除此之外還有可靠性，要求不能發生數據丟失。

最后是低成本，當業務發展到比較成熟的階段，我們會關注低成本。

在這些客戶訴求下，我們思考下一代數據庫或者說新的數據庫要具備哪些特性，也就是云原生數據庫它所具備的產品能力，如下所示。

第一個是全面托管，用戶不再需要去關注安裝、備份、部署、監控、高可用等，可以一鍵創建實例，創建出來的實例具備以上東西。

第二個是按量付費，按量付費可以讓業務起步的成本變得非常低，否則機房、硬件、網絡等一整套設施配置下來，成本非常高昂。

第三個是按需彈性，它分為兩個方面，一方面是要具備往上彈的能力，當業務在快速發展的過程中，數據庫也要能夠快速往上彈。另一方面是往下彈，當業務高峰過去了，需要很快地把資源使用量降下來，達到降低成本的目的。

第四個是生態兼容，無論用戶目前使用的是MySQL，還是Oracle，或者是其他數據庫，我們能遷移進來，也能遷移出去。

上方是我們認為云原生數據庫它所具備的產品能力。

在這些產品能力底下，還是有很多的技術在支持。

六大核心技術分別是智能化、多模、軟硬件一體化、安全可信、HTAP：大數據庫數據庫一體化、云原生+分布式。這六大核心技術支撐了上文的產品能力，解決開發者訴求。

（三）云原生關系型數據庫 PolarDB

PolarDB是阿里巴巴自研的新一代云原生數據庫，在存儲計算分離架構下，利用了軟硬件結合的優勢，為用戶提供具備極致彈性、高性能、海量 存儲、安全可靠的數據庫服務。100%兼容MySQL 5.6/5.7/8.0，PostgreSQL 11，高度兼容Oracle。

PolarDB-X為PolarDB分布式版本，融合分布式SQL引擎與分布式自研存儲X-DB，專注解決海量數據存儲、超高并發吞吐、復雜計算與分析等問題。

（四）云原生關系型數據庫PolarDB產品架構

PolarDB產品架構圖

PolarDB產品有以下特性：

存儲計算分離
1）分鐘級彈性升降級

2）分鐘級新增/刪除只讀節點

智能代理轉發
1）實現數據庫透明擴容

2）多種一致性級別

3）自定義Endpoint

分布式存儲
1）支持100TB

2）快速備份與恢復

3）更高單實例IO能力

libpfs+rdma+optane
1）高性能透明實現三副本 RPO=0

2）高性能寫入：實現高并發的寫入

基于redo復制
1）只讀實例毫秒級延遲

2）解決binlog/redo雙日志一致性與性能問題

并行執行
1）部分場景下的查詢與分析

2）可以自由控制的并行度，保障性能與穩定性

這里主要講一個和開發者使用過程中關系比較大的特性：智能代理轉發。

在數據庫中有一個非常難的點，它跟應用服務器不一樣，當應用服務器系統壓力特別大的時候，還是比較容易做擴展的，可以加一組應用服務器，把相關的流量擴展到新的應用服務器上就可以了。

但數據庫通常做不到，因為數據在查詢和使用上都是相互關聯的，數據不能簡單地做拆分。PolarDB在上層有一個智能代理層叫Proxy，它為開發者解決了這個問題。當數據庫系統壓力特別大的時候，通過智能代理可以自動把一些查詢的Query分發到別的只讀節點上。比如原來是一主一備，可以變成一主三備，就可以把流量自動分發到三個節點。

大家可能想，這個不就跟原來數據庫加幾個備庫是一樣的道理嗎？

PolarDB通過智能代理解決了一個非常關鍵的問題，那就是加了這些只讀節點以后，應用服務器上的連接配置是不需要做任何改動，可以隨時加上去，智能代理收到Query以后會自動轉發過去。

以現實業務場景舉例，比如某天前端的業務系統告訴我們，明天早上10點要做一個促銷活動，請做好數據庫的擴容。

以前如果加了只讀節點，可能遇到的問題是前端應用服務器根本就訪問不到這個只讀節點，或者可以訪問到只讀節點，但要對應用服務器的配置做一些改變，可能導致應用要把應用服務器重啟。現在通過PolarDB的智能代理可以有效解決這個問題，方便快捷地做容量擴展。

二、傳統關系型數據庫向云原生環境遷移

（一）傳統商業數據庫替換的挑戰

如今，如果要從別的商業數據庫遷移到 PolarDB上，比如從Oracle數據庫，一般來說有幾個比較大的挑戰。

第一個挑戰是應用耦合度高。通常情況下，數據庫跟應用的耦合度非常高，如果要對數據庫做一個動作的話，應用前端的應用要配合著一起做，可能會影響前端的可用性，因為通常情況下數據庫底下承載的業務都是比較關鍵的，動數據庫往往意味著動前端應用。

第二個挑戰是穩定性要求高。數據庫一出問題，前端的業務就會出問題，所以數據庫的變更和動作經常會在晚上執行。

第三個挑戰是數據量大。由于現在業務都比較大，因此核心數據庫的數據量通常會比較大。

第四個挑戰是語法兼容要求高。雖然大家使用的都是 SQL，但是不同數據庫的SQL還是不一樣的。如果從Oracle數據庫遷移到PolarDB，SQL要做太多的改造的話，就意味著前端業務系統的改造要非常大，情況也很復雜。

（二）使用云原生數據庫PolarDB替換傳統商業數據庫

是一個科學的標準化、產品化的過程。

遷移流程圖

在阿里云上，我們會提供一套標準化流程和產品幫助用戶從原始數據庫移到PolarDB數據庫。

首先，我們會給用戶一個工具或者腳本，到用戶的系統里面運行一下，它可以采集到用戶數據庫的一些特征，這個特征包括有哪些 SQL、函數、存儲過程跟目標數據庫寫法不匹配，原始的數據庫的特點，比如它是一個系統壓力特別大的數據庫，還是一個熱點數據特別明顯的數據庫。探測到這些點后，會告訴用戶在后期的改造中要注意什么問題。

上方表格就是在實際的業務過程中通過腳本跑出來的。

通過這個表格，我們可以看到原始數據庫如果要遷移到PolarDB的時候，它整體的兼容性還是比較高的。我們一共探測了6029個對象，這個對象可能包括存儲過程、數據表、索引序列，還有一些同義詞等相關的東西，其中不兼容的對象只有兩個，其實是比較少的。報表里會指出具體是哪兩個表，里面也有一些比較具體的修改建議，然后就可以遷移過來了。

下圖是一個比較具體的過程，此處不詳細展開闡述。

目前，阿里云已經把這一套標準化、產品化的流程和中國信通院一起做成了數據庫遷移的標準指南，開發者可以到網上查閱，遵照指南做數據庫遷移。

三、管理PolarDB O引擎（兼容Oracle語法）

（一）PolarDB提供面向Oracle的全棧兼容性

PolarDB提供的Oracle兼容性是包括多個方面的，除了語法層的兼容，還有物理存儲層、邏輯層和接口層。

（二）管理PolarDB O引擎（兼容Oracle語法）：常用工具

如果用戶從Oracle遷移過來，在使用或者管理PolarDB的時候，和原來有哪些不一樣？

在管理工具方面，用戶可以使用阿里云云端的數據管理平臺DMS，在控制臺上找到叫登錄數據庫的入口，就可以登錄到DMS上，如下所示。

第二個是用開源的數據管理平臺叫pgAdmin，在這個平臺上可以做基本的數據管理操作，包括基礎信息的查看，數據查詢，看一些執行計劃、表、對象等，如下所示。

四、PolarDB O引擎（兼容Oracle語法）的開發實踐：數據庫基本規范

管理PolarDB O引擎（兼容Oracle語法）：開發規范（1）

另外，阿里云有一些常用的開發規范，開發規范是阿里云內部探索出來的，也稱為規約，在阿里巴巴內部是比較嚴格遵守執行的，未來會發布在開發者社區和阿里云的文檔體系中。開發規范分成幾個方面，有些地方和開發者在具體使用PolarDB的時候關系會比較大，下面簡單闡述一下。

規范中有一些是我們內部要求強制執行，有一些則是推薦執行，用戶可以根據自己的實際情況進行取舍。

上方為建表規約。比如有一個對字段名的規范，要求必須要用小寫字母和數字，不能用關鍵字，為什么會有這樣的規范？因為字段名的修改是一個代價比較大的事情，通常不能“預發”。

我們發現，在實際的生產過程中改一個字段名是非常麻煩的。因為前面的業務已經在運行，如果改一個字段名，就意味著業務系統不能正常運行。所以以前大多數的做法就是加新的字段，因此我們對字段名提了一些規范，比如只能用小寫字母，不能用關鍵字等。

第二個是表名和字段名，我們要求加create_time和 update_time。這會帶來幾個好處，第一個就是如果數據發生錯誤的時候，你可以很快知道字段的修改情況和時間。第二個是在上下游系統里面，如果要拉取一些變化數據的時候，它也可以非常快地找到哪些數據發生了變化，然后去做對應的處理。

另外，表必須有主鍵。這里有幾個原因，第一個是查詢性能會非常好，第二個是在下游的系統拉取一些變化的數據的時候，它通過主鍵可以比較快速地拿到。

此外還有一系列的索引規約，如上圖所示。

規約中提到，索引的建立要有順序，這個順序的考慮可能會去關注where條件里面有哪些字段，要注意order by條件里面字段的順序，這個順序可能要影響索引建立的字段順序，只有它們兩個比較匹配的時候，整個的性能才會比較好。

另外，如果可以用覆蓋索引查詢的時候，盡量用覆蓋查索引查詢，會大大增加效率。

規約中還有一個推薦項：利用延遲關聯或者子查詢優化超多分頁場景。這也是我們在數據庫的索引優化里面的經驗。當做分頁查詢的時候，比如說當你翻到了第1000頁，或者是第500頁這樣靠后的頁面時，這時候建議的做法是，比如說翻頁要查出10頁的內容，最好先把這10頁內容的主鍵ID先查出來，查出來之后再回表一次，把所有的數據查出來，這是一個比較常見的推薦做法。

另外索引規約里面還提到一條，就是要注意不同字段類型，盡可能少或者不要發生隱式轉換，因為隱式轉換會導致整個索引失效。

管理PolarDB O引擎（兼容Oracle語法）：開發規范（2）

SQL和運維也有許多規約，這里主要講一下運維方面其中幾個點。

首先是數據訂正，開發者如果要去做一些修改數據的話，一定要先把這些數據查詢出來，先看一遍再去做刪除，要不然的話很容易出現誤刪除。

另外推薦使用數據管理產品DMS。如果在DMS上做數據訂正的話，它有一個好處是可以勾選備份，當做數據訂正的時候，它會自動把所有要訂正的數據全部做一個備份。如果發現數據訂正出了問題的時候，可以找到DMS自動備份下來的數據，重新再把這個數據恢復起來。

其他的這些這里不做過多闡述，未來會發布在開發者社區和阿里云的文檔體系中。

五、PolarDB O引擎（兼容Oracle語法）的開發實踐：常見的SQL優化

（一）管理 PolarDB O引擎（兼容Oracle語法）：SQL優化案例一 并行查詢

當查一些帶復雜計算的Query，用并行查詢可以大大加速查詢效率。

上方是一個簡單的例子，在GROUP BY的時候有一個非常簡單的計算，當這個Query要掃描的數據非常多的時候，開一個并行查詢可以讓耗時從原來的100多秒到10秒時間，速度翻了10倍，這是用戶在使用PolarDB的一個小技巧。

（二）管理PolarDB O引擎（兼容Oracle語法）：SQL優化案例二 選擇合適的JOIN方式

我們支持hash join，merge join和nest-loop join，用戶可以根據不同的場景選擇合適的Join方式。

可以看到，在上面這個案例中，選擇nest-loop join是最快的。

六、案例與認可

（一）完整的數據庫生態

雖然PolarDB是一個單獨的產品，但是它有非常完善的產品生態，包括數據管理DMS，數據自治服務DAS，數據傳輸DTS，數據庫備份DBS，數據與應用遷移ADAM等，可以滿足用戶各種場景，帶來全方位的服務。

（二）案例：PolarDB助力PrestoMall平滑從Oracle遷移上云

PrestoMall 是一家成立于2014年的東南亞電商企業，為了應對業務的快速增長，阿里云數據庫PolarDB助力PrestoMall平滑從Oracle遷移上云。

遷移上云主要面臨以下業務挑戰：

業務快速發展，IT 費用也隨之水漲船高，Oracle成本高昂；
業務的快速增長，應對雙十一大促乏力，應用具備水平擴展的能力，但是數據庫彈性不足；
去O復雜度太高，缺乏經驗，希望有專業評估指導；
最優遷移成本，控制風險成為難題。
根據客戶業務需求，我們制定了遷移至PolarDB O（兼容Oracle語法）的方案，原因是：

PolarDB O引擎（兼容Oracle語法） 作為云數據庫，沒有昂貴的license費用；
PolarDB O引擎（兼容Oracle語法）云原生彈性，解決客戶數據庫彈性不足的問題；
ADAM為客戶提供專業的數據庫/應用兼容性評估報告，制定完善的遷移計劃；結合PolarDB O引擎（兼容Oracle語法）對Oracle的高兼容性，大幅提升改造效率；
DTS實時遷移/回流的功能，配合專家服務，大幅縮短割接時間并降低風險。
遷移到PolarDB O引擎（兼容Oracle語法）后，通過最終實現了以下客戶價值：

PolarDB O引擎（兼容Oracle語法）在成功支撐客戶業務的同時，公司整體IT成本降低40%；
雙十二大促PolarDB O引擎（兼容Oracle語法）彈性升級，應對自如；
ADAM + PolarDB O引擎（兼容Oracle語法）幫助客戶代碼改造成本降低93%；
在計劃內順利平穩完成割接，業務穩定運行。

（三）被廣泛認可的云原生關系型數據庫PolarDB

目前，PolarDB在業界受到非常廣泛的認可，頂級學會的論文已經超過了10篇了，獲得了今年中國電子學會的科技進步一等獎，還有一些其他權威榮譽。