閱讀716 返回首頁    go 阿裏雲 go 技術社區[雲棲]

PolarDB · 新品介紹 · 深入了解阿裏雲新一代產品 PolarDB

背景意義

雲計算為如今的互聯網時代提供了更多的計算能力，乃至創造能力，關係型數據庫作為所有應用不可或缺的重要部件，開箱即用，高性價比特性的雲數據庫深受開發者的喜愛。作為一線的開發和運維人員，在阿裏雲的線上值班中，我們經常會碰到以下經典的客戶抱怨。

“你好，你們RDS的產品很棒，但是就是有點小貴，尤其是我要買隻讀實例的時候，成本是線性增加的，你們什麼時候能便宜點？”

“我在4天前，手工做了一個備份，數據庫比較大，3T，你們說差不多要70個小時備份，這個。。有沒有什麼辦法加快一點，我老板還著急要數據呢”

“我昨天花錢買了一個隻讀實例，但是實例到今天還沒創建好，3T數據量是大了一點，有沒有方法能加快一點？”

“我拿你們的RDS MySQL測試了一下性能，但是貌似不太給力，跟我之前用的Oracle/SQL Server等一些商業數據庫差的有點多，有什麼辦法提高性能麼？如果不行，我還是遷回自建的數據中心吧”

“你好，我們公司有個數據庫，想遷到阿裏雲RDS上，對RDS的產品品質我們很滿意，隻是我們的數據庫有10T，請問一下，支持這麼大的實例麼？”

“你好，我用了你們的MySQL數據庫，最近幾天在做活動，主庫壓力比較大，隻讀實例就延遲了，現在看過去貌似很難跟上，有什麼辦法麼？”

MySQL數據庫早期的版本，對早期的係統/硬件做了很多優化，但是並沒有考慮到現代主流的係統/硬件的優秀特性，在高並發環境下，性能還有很大的提升空間。此外，與其他關係型數據庫不同，MySQL為了兼容性，需要寫兩份日誌(事務日誌和複製日誌)，與其他商業數據庫相比，性能相對較差。
上述抱怨/吐槽都來自用戶真實的案例，總結起來，傳統的雲數據庫由於自身架構原因，會遇到如下問題：

  1. 讀寫實例和隻讀實例各自擁有一份獨立的數據，用戶購買隻讀實例，不僅需要付出計算的成本，也需要付出存儲資源的成本。
  2. 傳統備份技術，由於也涉及到拷貝數據，並上傳廉價存儲，速度因此也受網絡影響。
  3. 讀寫實例和隻讀實例各自擁有一份獨立的數據，新建一個隻讀實例需要重新拷貝數據，考慮到網絡限流，速度不會很快。
  4. MySQL數據庫早期的版本，對早期的係統/硬件做了很多優化，但是並沒有考慮到現代主流的係統/硬件的優秀特性，在高並發環境下，性能還有很大的提升空間。此外，與其他關係型數據庫不同，MySQL為了兼容性，需要寫兩份日誌(事務日誌和複製日誌)，與其他商業數據庫相比，性能相對較差。
  5. 由於物理機磁盤限製以及備份等策略，數據庫的數據大小不能太大，太大的實例是運維的災難。
  6. 讀寫實例和隻讀實例通過增量邏輯數據同步，讀寫實例上所有的SQL需要在隻讀實例上重新執行一遍(包括SQL解析，SQL優化等無效步驟)，同時，複製並發讀最高是基於表維度，導致主備延遲非常普遍，進而影響各種切換任務。

隨著數據庫數據量的增大，這些小麻煩會不斷的加劇，給DBA，開發乃至CTO帶來困惱。
如今，這些困擾大家已久的問題，在阿裏雲即將推出去的PolarDB中將得到解決，注意，是從本質上解決，而不是想個trick繞過去。

PolarDB是阿裏雲ApsaraDB數據庫團隊研發的基於雲計算架構的下一代關係型數據庫(暫時僅支持MySQL，PostgreSQL正在緊鑼密鼓的開發中)，其最大的特色是計算節點(主要做SQL解析以及存儲引擎計算的服務器)與存儲節點(主要做數據塊存儲，數據庫快照的服務器)分離，其次，與傳統的雲數據庫一個實例一份數據拷貝不同，同一個實例的所有節點(包括讀寫節點和隻讀節點)都訪問存儲節點上的同一份數據，最後，借助優秀的RDMA網絡以及最新的塊存儲技術，PolarDB的數據備份耗時可以做到秒級別(備份時間與底層數據量無關)，這三點相結合，我們可以推斷出PolarDB不但滿足了公有雲計算環境下用戶業務快速彈性擴展的剛性需求(隻讀實例擴展時間與底層數據量無關)，同時也滿足了互聯網環境下用戶對數據庫服務器高可用的需求(服務器宕機後無需搬運數據重啟進程即可服務)。

架構分析

image.png
image.png

圖1是PolarDB公測版本的總體架構圖。圖2是PolarDB數據庫內核上的架構。
解釋一下圖1中的各個組件。
上部分三個黑色框表示三台計算節點，下部分三個藍色框表示三台存儲節點。
在計算節點上，主要有三個重要部件：

DB Server: 即數據庫進程(Polar DataBase, 簡稱PolarDB)。PolarDB數據庫內核區分實例角色，目前包括三種角色，Primary，Standby和Replica。Primary即為擁有讀寫權限的讀寫庫，Replica即為隻讀實例，僅僅擁有讀取數據的權限(後台線程也不能修改數據)，Primary和Replica采用Shared Everything架構，即底層共享同一份數據文件和日誌文件。StandBy節點擁有一份獨立的數據和日誌文件(如圖2所示)，雖然用戶線程依然隻有讀取數據的權限，但是後台線程可以更新數據，例如通過物理複製的方式從Primary節點更新增量數據。StandBy節點主要用來機房級別的容災以及創建跨可用區的隻讀實例，公測階段暫時不開放。由於隻讀實例的擴展不需要拷貝數據，創建新的隻讀實例不但速度快，而且很便宜，用戶隻需要支付相應計算節點的成本即可。我們稱StandBy和Replica節點為Slave節點，Primary節點也可稱為Master節點。

User Space File System: 即用戶態文件係統(Polar File Sytem, 簡稱PolarFS)。由於多個主機的數據庫實例需要訪問塊存儲上的同一份數據，常用的Ext4等文件係統不支持多點掛載，PolarDB數據庫團隊自行研發了專用的用戶態文件係統，提供常見的文件讀寫查看接口，便於MySQL和相關的外圍運維工具使用文件係統支持類似O_DIRECT的非緩存方式讀寫數據，還支持數據頁原子寫，IO優先級等優秀的特性，為上層數據庫的高性能提供了結實的保障。傳統的文件係統，由於嵌入在操作係統內核中，每次係統文件讀寫操作都需要先陷入內核態，完成後再返回用戶態，造成效率低下。PolarFS以函數庫形式編譯在MySQL中，因此都運行在用戶態，從而減少了操作係統切換的開銷。

Data Router & Cache: 即塊存儲係統客戶端(Polar Store Client, 別名PolarSwitch)。PolarFS收到讀寫請求後，會通過共享內存的方式把數據發送給PolarSwitch，PolarSwith是一個計算節點主機維度的後台守護進程，接收主機上所有實例以及工具發來的讀寫塊存儲的請求。PolarSwith做簡單的聚合，統計後分發給相應的存儲節點上的守護進程。由此可見PolarSwitch是一個重資源的進程，如果處理不好，對計算節點上的數據庫實例有很大的影響，因此我們的管控程序對其使用了CPU綁定，內存預分配，資源隔離等一些手段，並且同時部署了高效可靠的監控係統，保證其穩定運行。

Data Chunk Server: 即塊存儲係統服務器端(Polar Store Server, 別名ChunkSever)。上述三個部件都運行在計算節點上，這個部件則運行在存儲節點上。主要負責相應數據塊的讀取。數據塊的大小目前為10GB，每個數據塊都有三個副本(位於三台不同的存儲節點上)，兩個副本寫成功，才給客戶端返回成功。支持數據塊維度的高可用，即如果一個數據塊發生不可用，可以在上層無感知的情況下秒級恢複。此外，PolarStore使用了類似Copy On Write技術，支持秒級快照，即對數據庫來說，不管底層數據有多大，都能快速完成全量數據備份，因此PolarDB支持高達100T的磁盤規格。

計算節點和存儲節點之間通過25G RDMA網絡連接，保證數據的傳輸瓶頸不會出現在網絡上。

此外，PolarDB還有一套完善的基於docker的管控係統，處理用戶下發的創建實例，刪除實例，創建賬號等任務，還包括完善詳細的監控，以及可靠的高可用切換。管控係統還維護了一套元數據庫，用以記錄各個數據塊的位置信息，提供給PolarSwitch，便於其轉發。
可以說，PolarDB整個項目用了很多很多的新技術黑科技，給用戶直接的感受是，又快(性能是官方MySQL6倍)又大(磁盤規格支持高達100T)又便宜(價格隻有商業數據庫的1/10)。

接下來，我們重點分析PolarDB在MySQL內核方麵的功能增強、性能優化以及未來的規劃。便於讀者了解PolarDB數據庫內部運行的機製。

功能增強

物理複製

簡單的想，如果讀寫實例和隻讀實例共享了底層的數據和日誌，隻要把隻讀數據庫配置文件中的數據目錄換成讀寫實例的目錄，貌似就可以直接工作了。但是這樣會遇到很多問題，隨便列舉幾條：

  1. 如果讀寫實例上對某條數據進行了修改，由於Buffer Pool緩存機製，數據頁可能還沒有被刷新到磁盤上，這個時候隻讀實例就會看不到數據，難道每次都刷盤，那跟文件有什麼區別。
  2. 再仔細想一想事務，一個讀寫事務，修改了3個數據頁，2個數據頁刷下去了，但是1個數據頁還沒有刷盤，這個時候隻讀節點因為需要查詢也需要這幾個數據頁，然後數據就不一致了？也就是說隻讀節點上的MVCC機製似乎會被破壞。
  3. 考慮一下DDL，如果在讀寫實例上把一個表給刪除了，萬一隻讀實例上還有對這個表的查詢呢？隻讀實例去哪裏查詢數據哈？要知道IBD文件已經被讀寫實例這個家夥幹掉了，可憐的隻讀實例隻能coredump以示不滿？
  4. 如果讀寫實例正在寫一個數據頁，然而剛好隻讀實例也要讀取這個數據頁，然後隻讀實例有可能讀了一個寫了一半的數據頁上來，然後checksum校驗不過，數據庫crash。

所以，仔細思考一下，多個數據庫實例共享同一份數據不是一件容易的事情。為了解決上述問題，我們需要隻讀實例也按照讀寫實例更新數據的節奏來更新數據並且需要一套完善的髒頁刷盤機製。現代關係型數據庫中其實已經有一份記錄數據頁更新的Redolog事務日誌了，在MySQL中，就是ib_logfileXX類似這種文件，因此參考Binlog複製框架，PolarDB使用這種事務日誌構建了一套數據複製方法，在隻讀實例上隻需要順序應用讀寫實例產生的日誌即可，StandBy節點和Replica節點兩者都需要更新內存中的數據結構，但是StandBy節點由於獨立維護一份數據和日誌，所以需要把更新的增量數據寫入到自己的數據文件和日誌中，而Replica則不需要。由於MySQL的Redolog相比於Binlog記錄的都是物理的數據頁(當然也有邏輯部分)，所以我們把這種複製稱為物理複製。

由於Redolog並沒有記錄用戶的SQL，僅僅記錄了最終的結果，即這個SQL執行後造成的數據頁變化，所以依賴這種複製架構，不需要SQL解析SQL優化，MySQL直接找到對應的文件中的數據頁，定位到指定偏移，直接更新即可。因此性能上可以做到極致，畢竟並發粒度從之前的表級別變為了數據頁級別。當然也會帶進來很多新的問題，簡單列舉幾個：
物理複製中的MVCC。MySQL的MVCC依賴Undo來獲取數據的多版本，如果Primary節點需要刪除一個Undo數據頁，這個時候如果Replica節點還在讀取的話就會有問題，同理，StandBy節點也有這個問題，因此我們給客戶提供兩種方式，一種是所有Slave定期向Primary匯報自己的最大能刪除的Undo數據頁，Primary節點統籌安排，另外一種是當Primary節點刪除Undo數據頁時候，Slave接收到日誌後，判斷即將被刪除的數據頁是否還在被使用，如果在使用則等待，超過一個時間後直接給客戶端報錯。此外，為了讓Slave節點感知到事務的開始和結束以及時間點，我們也在日誌中增加了不少邏輯日誌類型。

物理複製中的DDL。Primary節點刪除一個表之後，Replica可能還會有對此表的請求。因此，我們約定，如果主庫對一個表進行了表結構變更操作，在操作返回成功前，必須通知到所有的Replica(有一個最大的超時時間)，告訴他們，這個表已經被刪除了，後續的請求都失敗吧，具體實現上可以使用MDL鎖來控製。當然這種強同步操作會給性能帶來極大的影響，後續我們會對DDL做進一步的優化。

物理複製中的數據複製。除了複製引擎層的數據之外，PolarDB還需要考慮MySQL Server層表結構的一些文件複製，例如frm, opt文件等。此外，還需要考慮一些Server層的Cache一致性問題，包括權限信息，表級別的統計信息等。
物理複製中的日誌並發應用。既然物理日誌可以讓我們按照數據頁的維度來支持並發，那麼PolarDB需要充分的利用這個特性，同時保證在數據庫奔潰後也能正確的應用日誌和回滾事務。其實這部分的代碼邏輯與MySQL崩潰恢複的邏輯很像，PolarDB對其進行了複用和改造，做了大量的性能上的優化，保證物理複製又快有穩。

物理複製中的Change Buffer問題。Change Buffer本質上是為了減少二級索引帶來的IO開銷而產生的一種特殊緩存機製。當對應的二級索引頁沒有被讀入內存時，暫時緩存起來，當數據頁後續被讀進內存時，再進行應用，這個特性也帶來的一些問題，例如Primary節點可能因為數據頁還未讀入內存，相應的操作還緩存在Change Buffer中，但是StandBy節點則因為不同的查詢請求導致這個數據頁已經讀入內存，發生了Change Buffer Merge操作，從而導致數據不一致，為了解決這個問題，我們引入shadow page的概念，把未修改的數據頁保存到其中，將change buffer記錄合並到原來的數據頁上，同時關閉該Mtr的redo log，這樣修改後的Page就不會放到flush list上了。此外，為了保證Change Buffer merge中，不被用戶線程看到中間狀態，我們需要加入新的日誌類型來控製。

物理複製中的髒頁控製。Primary節點不能毫無控製的刷髒頁，因為這樣Replica會讀取到不一致的數據頁，也會讀取到未提交事務的數據頁。我們給出了一個策略，replica需要緩存所有未刷盤的數據變更(即RedoLog)，隻有primary節點把髒頁刷入盤後，replica緩存的日誌才能被釋放。采用這個策略後，replica內存的使用率與primary的刷髒速度就相關量起來，所以需要對primary節點的刷髒算法進行調整，同時也要考慮一些頻繁更新的數據頁導致primary節點刷髒緩慢的問題。

物理複製中的Query Cache問題，discard/import表空間問題，都需要考慮。

此外，在兼容性方麵，由於PolarDB存儲引擎暫時隻兼容InnoDB數據表，Myisam和Tokudb暫時都不兼容，而係統表很多都是Myisam的，所以也需要轉換。

物理複製能帶來性能上的巨大提升，但是邏輯日誌由於其良好的兼容性也並不是一無是處，所以PolarDB依然保留了Binlog的邏輯，方便用戶開啟。

實例角色

傳統的MySQL數據庫並沒有實例角色這個概念，我們隻能通過查詢read_only這個變量還判斷實例當前的角色。PolarDB中引入三種角色，滿足不同場景下的需求。Primary節點在初始化的時候指定，StandBy和Replica則通過後續的配置文件指定。

故障切換。

目前支持三種類型的切換，Primary降級為StandBy，StandBy提升為Primary以及Replica提升為Primary。每次切換後，都會在係統表中記錄，便於後續查詢。Primary節點和StandBy節點由於擁有各自的數據文件，在異步複製的模式下，容易造成數據不一致，我們提供了一種機製，保證新StandBy的數據一定與新Primary的數據一致。想法很簡單，當新StandBy再次啟動時，去新Primary查詢，回滾掉多餘的數據即可，隻是我們這裏不使用基於Binlog的SQL FlashBack，而是基於Redolog的數據頁FlashBack，更加高效和準確。Primary節點和Replica節點，由於共享同一份數據，不存在數據不一致的分享，當發生切換的時候，新Primary隻需要把老Primary未應用完的日誌應用完即可，由於這個也是並行的操作，速度很快。

這裏簡單提一下，目前公測階段的故障切換邏輯：首先是管控係統檢測到Primary不可用(或者發起主動運維操作)，則連接上Primary(如果還可以)，kill所有用戶連接，設置read_only，設置PolarStore對此IP隻讀(Primary節點和Replica節點一定在不同的計算節點上)，接著，連接到即將升級的Replica上，設置PolarStore對此IP讀寫，MySQL重新以讀寫模式掛載PolarFS，最後執行Replica提升為Primary的語句。正常情況下，整個過程時間很短，30秒內即可切換完成，但是當Primary和Replica延遲比較大的時候，需要更多的時間，但是相比於之前Binlog的複製，延遲時間至少下降2個數量級。後續我們會對這塊繼續進行深度優化，進一步提高實例可用性。

複製模式

傳統的Binlog複製模式隻有異步複製和半同步複製兩種。在PolarDB中，我們還增加了強同步複製，即要求Slave節點應用完數據才返回成功，這個特性對複製特別敏感的用戶來說，是個好消息，能保證隻讀實例查詢出來的數據一定與讀寫庫上查詢出來的一樣。此外，PolarDB還支持延遲複製功能，複製到指定事務，複製到指定時間點等，當然這幾個特性主要是提供給災備角色StandBy的。此外，為了進一步減少複製延遲，如果Replica發現自身延遲超過某個閾值，就會自動開啟Boost模式(會影響實例上的讀)，加速複製。如果Primary節點發現某個Replica延遲實在太大，出於安全考慮，會暫時把這個Replica踢出複製拓撲，這個時候隻需要重新啟動一下Replica即可(由於Replica不需要做奔潰恢複，重啟操作很快)。PolarDB還支持複製過濾功能，即隻複製指定的幾個數據庫或者指定幾個表，這樣由於不需要複製查詢不感興趣的數據，從而可以進一步降低複製延遲。這裏提到的各種有趣的特性，在公測階段還暫時不支持，在不久的將來，會陸續開放給大家。

日誌管理

類似Binlog的日誌管理，PolarDB也提供了類似的機製和工具來管理Redolog。首先，與傳統MySQL循環使用Redolog不同，與Binlog類似，PolarDB中Redolog也是以文件編號遞增的方式來管理，並提供相應的刪除命令給管控係統使用。PolarDB依據PolarStore的全量備份和Redolog增量日誌為客戶提供還原到任意時間點的功能。PolarDB還有一個專門用來解析Redolog日誌的工具mysqlredolog，類似Binlog解析工具mysqlbinlog，這個工具在係統診斷中非常有用。Redolog中，PolarDB也增加了不少獨特的日誌類型，為了做到兼容性，Redolog也有版本管理機製。傳統的MySQL僅僅數據文件支持O_DIRECT，PolarDB為了適配新的文件係統，Redolog日誌也支持O_DIRECT方式寫入。

此外，PolarDB對Undo日誌也進行了深度的開發，目前支持Online Undo Truncate，媽媽再也不用擔心我的ibdata數據文件過大啦。

監控信息

PolarDB增加了那麼多功能，自然也會提供很多新的命令，例如用戶可以使用SHOW POLAR STATUS來查看相關信息，使用SHOW POLAR REPLICAS來查看所有已經連接的replica節點。使用START POLAR SLAVE來啟動複製，使用SHOW POLAR LOGS來查看產生的Redolog文件，等等等。PolarDB在information_schema中也增加了好多表，有興趣的讀者可以去看一下，這裏麵到底存的是什麼。

實例遷移

目前數據庫內核支持(大概再過幾個月會提供給用戶使用)從RDS 5.6遷移到PolarDB上，流程主要如下，首先在RDS 5.6上使用xtrabackup做個全量的數據備份，接著在計算節點上，xtrabackup做恢複，成功後，通過PolarFS提供的運維工具把所有的數據文件放到PolarStore上，然後使用特定的參數啟動PolarDB，PolarDB會把RDS 5.6日誌文件格式轉換成PolarDB的Redolog，接著可以使用Binlog方式追增量數據，當追上RDS 5.6的讀寫庫且到達用戶指定的切換時間，設置RDS 5.6讀寫庫隻讀，並且PolarDB做一次重啟，關閉Binlog複製，最後把VIP切換到PolarDB上即可完成遷移工作。

周邊工具

除了上文提到的解析Redolog日誌工具外，由於對源碼進行了大幅度的改動，PolarDB還對MySQL原生的TestCase Framework進行了改動，保證在共享數據日誌的場景下(Local FS/Disk and PolarFS/PolarStore)所有的Testcase能通過。

性能優化

PolarDB除了擁有大量新的特性外，我們還做了很多性能上的優化，這裏簡單列舉一些：

  1. 在高並發的場景下，PolarDB對很多latch做了優化，把有些latch分解成粒度更小的鎖，把有些latch改成引用計數的方式從而避免鎖競爭，例如Undo segment mutex, log system mutex等等。PolarDB還把部分熱點的數據結構改成了Lock Free的結構，例如Server層的MDL鎖。
  2. 針對用戶在SQL語句中直接指定主鍵的SQL語句，PolarDB也做了相應的優化，這樣可以減少一些優化器的工作，從而得到更好的性能。
  3. PolarDB中物理複製的性能至關重要，我們不僅通過基於數據頁維度的並行提高了性能，還對複製中的必要流程進行了優化，例如在MTR日誌中增加了一個長度字段，從而減少了日誌Parse階段的CPU開銷，這個簡單的優化就能減少60%的日誌Parse時間。我們還通過複用Dummy Index的內存數據結構，減少了其在Malloc/Free上的開銷，進一步提高複製性能。
  4. Redolog的順序寫性能對數據庫性能的影響很大，為了減少Redolog切換時對性能的影響，我們後台采用類似Fallocate的方式預先分配日誌文件，此外，現代的SSD硬盤很多都是4K對齊，而MySQL代碼還是按照早期磁盤512字節對齊的方式刷日誌的，這樣會導致磁盤做很多不必要的讀操作，不能發揮出SSD盤的性能，我們在這方麵也做了優化。
  5. PolarDB的Replica節點，日誌目前是一批一批應用的，因此當新的一批日誌被應用之前，Replica上的讀請求不需要重複創建新的ReadView，可以使用上次緩存下來的。這個優化也能提高Replica上的讀性能。
  6. PolarDB對臨時表也做了一些優化，例如在臨時表上可以把Change Buffer關掉，臨時表的修改可以少做一些操作，例如在應用日誌的時候可以不對索引加鎖等。
  7. PolarDB也繼承了AliSQL幾乎所有的性能優化點，例如，日誌核心函數log_write_up_to的優化， LOCK_grant鎖的優化，jemalloc內存分配庫的使用，日誌Group Commit的優化，Double RedoLog Buffer的優化，Buffer Pool Hazard Pointer的優化，自適應concurrency tickets的優化，隻讀事務的優化等等，詳情可以參考GitHub上的AliSQL首頁。
  8. 我們實現了一套按需應用日誌的控製算法，即隻有在Buffer Pool中的數據頁才需要應用日誌，同時，不僅僅是後台線程會應用日誌，用戶線程也會應用日誌，這兩點相結合，大大減少了應用日誌緩慢而造成的延遲。此外，由於使用了自研的PolarFS文件係統，刷髒的延遲和吞吐量與傳統的Ext4文件係統有很大的不同，我們對page cleaner和double write buffer(雖然PolarFS支持原子寫，但依然可以開啟)都進行了優化，例如增加dblwr個數以及調整page cleaner線程的算法和優先級等。

展望未來

PolarDB目前已經公測，但是未來我們還有很多有趣的特性可以做，在性能方麵也有很多的優化點，例如：

  1. 目前PolarDB高可用切換和實例可用性檢測都需要依賴外部的管控係統，另外一方麵，由於Primary和Replica共享數據和日誌，如果Replica和Primary之間的通信中斷，Replica就感知不到數據文件的狀態，在這種情況下，Replica將會不可服務，為了解決這兩個問題，PolarDB也會引入類似Raft協議下的自製集群機製，自動檢測可用性，自動發起切換。具體實現可以參考RDS金融版三節點實例自製集群的方案。
  2. 可以在Replica節點上引入類似Materialized view的特性，當然這裏不是指數據庫概念中的視圖，而是PolarDB中的ReadView。
  3. 上文提到過，目前的DDL是個強同步點，因此我們需要進一步優化DDL，例如引入文件多版本來解決Replica讀的問題。另外，Online DDL很多情況下依然需要拷貝整個數據文件，也許我們可以參考PolarStore COW的思想，把這部分拷貝數據的IO壓力分攤到後續的DML中。
  4. 在阿裏雲，用戶有很多上雲遷移數據的需求，物理遷移的方式畢竟隻能服務MySQL數據庫，邏輯的SQL導入才是最通用的解決方法，因此我們需要盡量提高在導入大量數據時的性能。一個簡單的優化就是數據按照主鍵順序排序，我們記錄最後一次插入的BTree頁節點位置，後續插入就不需要再從Root節點開始掃描了。我們也可以在導入數據的時候，暫時關閉Redolog日誌寫入，也能提高性能，類似Oracle Nologging機製。
  5. 在存儲引擎的鎖機製上，PolarDB也還可以做更多的優化，使用更多的lock free結構，減少鎖衝突。我們也考慮使用最新的Futex來取代效率低下的Spinlock，當然這些功能需要經過完善縝密的測試，才能上線。
  6. 由於PolarFS/PolarStore能提供16K數據頁維度的原子寫支持，所以我們不需要類似double write buffer的機製，並對寫數據頁的操作進一步優化，例如通過某些機製可以釋放數據頁在刷盤時hold住的讀鎖。PolarDB也可以使用PolarFS提供的IO優先級功能，保證日誌是以第一優先級刷入磁盤。這些改動能大幅度提升性能，但是與鎖機製類似，我們需要做充足的測試。
  7. 此外，我們也會Port官方MySQL 8.0的最新的數據字典結構，因為MySQL支持事務性DDL需要這些必要的改動。

寫在最後

總之，PolarDB是阿裏雲數據庫團隊為雲計算時代定製的數據庫，擁有很多優秀的特性，是雲計算2.0時代產品進化的關鍵裏程碑之一，也是開源數據庫生態的積極推動力。我們將在9月下旬開放公測，期待大家的反饋。

參考文獻：

https://www.infoq.com/cn/news/2017/08/ali-polardb
https://www.percona.com/live/data-performance-conference-2016/users/zhai-weixiang
https://www.percona.com/live/17/users/zhai-weixiang

image.png

最後更新：2017-09-21 09:03:20

  上一篇：go  HybridDB · 最佳實踐 · 阿裏雲數據庫PetaData
  下一篇：go  我的第一篇博客