雲栖幹貨回顧 |“頂級玩家”集結！分布式資料庫專場精華解讀

本專場是阿裡雲分布式資料庫的年度盛會，多位阿裡雲分布式資料庫領域核心專家以及業界專家進行了專題演講，内容涵蓋分布式 POLARDB（DRDS）、AnalyticDB、OceanBase 多款雲上核心分布式資料庫産品，涉獵分布式 SQL 引擎、分布式存儲引擎、分布式事務等多個方向。

從 DRDS 到分布式 POLARDB—— 雲上分布式關系型資料庫的演進

阿裡雲智能資料庫産品事業部進階技術專家君瑜為大家分享了DRDS的演進之路。

DRDS設計理念

DRDS誕生于2008年淘寶“去IOE”時代，過去的十多年中，DRDS經曆了每年的“雙11”并發揮了重要作用。5年前，DRDS正式商用，目前服務了無數企業的核心應用。

對于任何一個産品而言，它的出現以及能力的變化都與其面向的業務相關。對于DRDS而言，可以粗略地把業務場景分為3類。第一類是DRDS從一開始出現就在解決的面向最終消費者的高并發業務資料庫的需求，這也是DRDS能夠很好解決的場景。第二種場景就是DRDS上雲提供服務之後遇到的企業級資料庫需求，它希望資料庫具有綜合負載能力、可持續運維和7*24小時穩定性以及并發、計算和存儲的擴充性。

如今，解決上述某幾個問題的資料庫大緻可分為三類：

• DRDS以及Sharding On MySQL資料庫，主要基于MySQL和分布式計算能力，使得計算存儲高度可擴充，風險可控。

• NewSQL資料庫，核心特點就是存儲與計算分離。

  Cloud Native DB，強調存儲可擴充以及全相容的能力。

• 而通過并發控制、分布式、容災以及計算這四個次元能夠更加深入剖析資料庫能力。

  

目前分布式資料庫領域，HTAP非常火，但又太寬泛了。OLAP和OLTP都能做到HTAP，但兩者側重點卻不同。是以DRDS的目标設定為OLTP optional Analysis，即具有穩定的OLTP能力，還可以逐層向外延伸技術能力。

DRDS産品與核心

下圖是DRDS的全景圖，左邊是資料服務部分，右邊是産品能力和工具。DRDS以分布式SQL引擎為抓手，并對資料引擎進行了“謹慎”又“大膽”的探索，通過産品、工具和服務建構了商業形态。在産品層面則提供了穩定性、可擴充性、持續可運維和安全可控四個特性。

DRDSOn MySQL實作得很好，但在存儲方面則讓人“既愛又恨”。是以，在POLARDB上線後的第一時間，阿裡雲就實作了DRDS On POLARDB。DRDS和POLARDB兩者的布局不同，POLARDB層面側重一寫多讀的能力，DRDS層面則側重事務擴充性。DRDS On POLARDB解決了資料傾斜、主備資料以及RDS資料能力的問題，是以相對比較穩定并且具有面向未來的一些特性。

DRDS标準資料庫核心的發展經曆了從超高并發使用者側服務逐漸轉向了企業級應用場景的轉變。發生這樣轉變的驅動力也有三個，即業務場景、經典資料庫理論以及Benchmark。DRDS标準資料庫核心非常注重分布式的能力，比如OLTP極緻算子Pushdown能力、分區鍵精确裁剪、多種拆分方式、統一架構的2PC和XA分布式事務、全局強一緻二級索引、MPP執行引擎技術、OLTP查詢加速等。

如何使用 DRDS 支撐超大規模線上核心 OLTP 業務

快狗視訊、米讀極速版技術負責人吳雄傑為大家分享了米讀如何基于DRDS支撐超大規模線上核心OLTP業務。

百分百分紅活動的需求和背景

百分百分紅活動的目的在于提高日活，活動規則是每日淩晨0點，根據使用者昨日閱讀有效時長與大盤總時長占比對使用者進行分紅，看越多分越多。使用者隻要參與閱讀即可獲分紅資格，要求0點開始實時發放。活動的特點主要有三個：實時性要求高，金币發放量大，寫并發高，以及要求高可靠性和強一緻性事務能力。

RDS解決方案及痛點

米讀在一周内緊急制定了基于RDS的解決方案，該方案基于單讀寫的RDS執行個體，并在後面根據使用者ID做了分表，該方案上線後當晚就挂掉了。這是因為該方案存在幾個非常明顯的問題，首先讀寫并發存在明顯瓶頸，無法滿足增長需求；其次架構更新能力較差，無法實作更新的無縫銜接；再次，使用和維護成本較高；最後，單執行個體不具備故障遷移能力，點影響面。

DRDS調研及解決方案

針對于這些痛點，米讀團隊進行調研後發現DRDS具備符合米讀需求的6種主要能力，即強擴充能力、強資料遷移能力、高使用效率、強相容性、全局唯一ID以及支援連接配接池。

是以，米讀基于DRDS設計了解決方案。業務層中有賬戶、金币和好友邀請系統，DB層部署了4個DRDS，每兩個DRDS組成“主執行個體-隻讀執行個體”組，每個功能子產品對應一組DRDS，DRDS下面再挂載RDS，這樣就将壓力分散開來。

對DRDS的未來期望

希望未來DRDS能夠支援讀寫分離智能切換，而不是業務方自己去建立主執行個體和隻讀執行個體。希望DRDS能夠實作分區表建立的工具化，提升效率。最後希望DRDS能夠進一步提升全局掃描效率問題。

AnalyticDB 海量資料極速分析背後的分布式計算技術解讀

阿裡雲智能資料庫産品事業部資深技術專家陳哲為大家解讀了AnalyticDB背後的分布式技術。

從曆史的演進角度來看，10年前還沒有出現大資料的時候，人們使用資料庫對資料做一些基本的分析。而當資料庫中的資料量增大到一定體量之後出現了瓶頸，此時就出現了Hadoop體系，它幫我們度過了資料急速膨脹的過程。而如今，Hadoop原生體系出現了一定下滑，其背後是傳統的離線數倉已經跟不上業務發展的需要了。業務發展正在經曆從大資料向快資料的轉變。

上圖右側是AnalyticDB模型圖，存儲引擎層實作了高性能的适配，能夠為不同的使用者帶來不同的體驗。整體通過Raft保證高可用，底層存儲使用了行列混存。計算引擎層面，能夠瞬間彈性擴充至最多2000個Worker，能夠提供大規模ETL能力，并能夠使用阿裡巴巴最新硬體的加速能力。最上層是Multi-Master節點，能夠支援彈性擴充。

AnalyticDB采用了MPP+DAG融合模型的執行引擎，這裡展開介紹一下。傳統MPP模型以Greenplum為代表，Greenplum每個節點收到的執行計劃都是一樣的，這樣的優點在于可以高效地利用本地存儲去打通并做快速計算，但是如果Greenplum超過500個執行個體的規模，性能就會直線下降。是以，在AnalyticDB裡面分為了MPP和DAG模型，能夠根據對SQL的判斷使用不同的模型。在執行内部則是Pipeline模型。對于混合負載而言，如果研發寫了一個非常糟糕的SQL就會拖慢整體運作速度，是以AnalyticDB做了時間片輪轉執行，大大減少了因為慢SQL引起的糟糕情況。

整體的執行過程分為三部分，Pipeline面對的是低延時、高QPS，Stage By Stage面對複雜SQL、高吞吐，統一Runtime支援Operator，并且整體模型是multi-batch結構。

2019年5月份，AnalyticDB通過了TPC的測試，在所有的性能名額方面都排名第一。此外，在Gartner中，AnalyticDB處于Niche Player的角色，并在走向領先的過程當中。

DRDS & ADB 攜手助力城市公交系統智能化

北京啟迪公交科技首席技術專家殷悅為大家分享了如何基于阿裡雲産品實作城市公交系統智能化。

北京啟迪公交科技股份有限公司的主要業務是基于北京公交集團的人、車、場地等資源和資料資源進行資料開發，以提供豐富多樣的資訊服務以及出行服務。從2018年6月至今，啟迪主要做的事情就是北京公交的掃碼乘車。北京的情況與其他城市不同，乘客上、下車時都需要掃碼，類似地鐵的計費方式但更加複雜。而北京公交是全球最大的單體公交公司，内部組織結構極為複雜，并且北京公交業務本身和特征也非常複雜。是以，啟迪的業務需要适配各種特征。

想要改變業務首先要了解業務，了解業務的第一步就是感覺所有資訊。智慧公交感覺網絡會利用物聯網平台将車載裝置産生的資料統一接入資料中心，并利用資料中心做線上交易和大資料分析，這部分就會涉及到DRDS、ADB和TSDB的使用。首先要完成交易類型的工作，其次才可以對資料進行高實時性的分析。隻有把服務元素資訊集合到一起之後，才能進行綜合式分析和業務洞察。需要建構服務元素之間的關聯性，利用關聯性了解業務狀況，最終推動産品形态的創新。進而更好地比對客戶需求和服務供給，進而提升企業效益。

啟迪目前營運車輛達24000輛，日支付行為達1600萬，每秒支付峰值達1500，車載POS日裝置心跳上報達到8900萬條。交易處理方面，經廣泛評估，啟迪選擇了阿裡雲DRDS，這是因為DRDS擁有經過阿裡“雙11”驗證過的能力，并且具有極緻的拓展能力和完善管控能力。

啟迪之是以選擇阿裡雲的産品來實作業務目标，是因為更希望将主要精力放在業務層面，而不是基礎設施上。阿裡雲産品提供了成熟的技術、開箱即用的能力和完整的生态，是以能夠幫助啟迪實作資料上雲驅動未來公交。

分布式關系型資料庫服務DRDS 新一代核心技術揭秘

阿裡雲智能資料庫産品事業部進階技術專家，分布式資料庫服務DRDS核心技術負責人樓江航為大家揭秘了DRDS 新一代核心技術。

DRDS整體介紹

DRDS采用的是基于MySQL的Share Nothing分庫分表架構，是典型的存儲與計算分離的模式。存儲層依賴于MySQL，并且在阿裡雲上具有高可用性保障和擴容能力。計算層是無狀态的，基于SLB能夠實作較好的擴充性。結合以上兩點，解決了MySQL存儲計算的能力問題。

如下是DRDS核心架構的細節圖。整體來看，DRDS核心可以分為MySQL網絡接入層、解析層、優化層、計劃層和執行器層。從右側細節可以看出，DRDS核心類似于MySQL的SQL引擎的實作。總結而言，DRDS核心是面向關系代數的SQL引擎。

核心技術關鍵點

(1)關系代數

前面提到RDS核心是面向關系代數的SQL引擎，那麼什麼是關系代數呢？其實and、or、join都叫做關系代數，針對于同樣想要的結果可能有不同的SQL寫法，這就涉及到關系代數了。資料庫優化器所做的事情就是基于目前計算能力選擇更加好的執行邏輯。業界經過四、五十年的發展，在關系代數方面也有非常深厚的沉澱。

SQL進入DRDS之後會首先進入解析器會轉成AST，AST經過Validator會傳回對應的表是否具有權限以及表列關系是否合理，之後轉成關系算子樹，也是優化器主要工作的對象。優化器會結合統計資訊和RBO和CBO的一些優化将其轉成實體執行計劃。實體執行計劃包含所需的資料存儲位置，以及通路的串并行特征等。DRDS會通過SQL與MySQL進行互動，也會通過RPC與NewSQL進行互動。

(2)DRDS優化器設計

DRDS的優化是RBO+CBO兩階段的過程。RBO是面向規則的啟發式處理方式，CBO則是基于統計資訊進行智能決策。DRDS基于MySQL Sharding的架構，具有分片的特征同時具有存儲與計算分離之後網絡所帶來的開銷。是以，DRDS優化器會引入Partition-Aware的思路來解決因為分片和網絡所帶來的需求。随着上雲過程中，使用者對複雜SQL的需求越來越強烈，DRDS在HTAPWorkload裡面也做了大量的優化。此外，DRDS優化器整體采用了Volcano/Cascades風格。

RBO方面，SQL Writer引入了Rule的核心理念，實作了最小原子化以及編排和分組。在算子下推方面，在DRDS裡面為了屏蔽使用者對實體表的感覺就引入了邏輯表，并引入了LogicalView算子節點來替換TableScan，LogicalView包含對MySQL多張實體表的通路，這樣就将算子下推變成了LogicalView如何和現有的運算符做關系代數的轉化。

CBO方面會有統計資訊的概念，除此之外會将Rule評估變成優先隊列，使得在有限時間内做出盡可能多的優化。統計資訊總體可以分為三層，底層葉子節點代表資料表的統計資訊，分支節點是Cardinality的估算，再上一層就是Cost模型。CBO中另外一個重要能力就是Join Reorder，這是針對複雜SQL所必須的能力。

(3) DRDS執行器設計

DRDS的事務處理是基于MySQL 5.7的XA實作的，并在正常的2PC的事務管理基礎之上做了優化，做了2PC事務減枝。索引是用空間換時間的解決方案，DRDS有了分布式事務的加持之後，會在使用者寫主表的同時，根據分布式事務預設地更新索引表，保證主表和索引表之間的資料一緻性，其次會在執行SQL的時候基于代價在查詢主表和查詢索引中進行選擇。此外，還引入了Online DDL，能夠支援COVERING文法。而對于全局索引而言，本身也有一定代價，是以也需要進行控制。随着使用者對于複雜查詢的訴求越來越強烈，DRDS也在核心層面支援了Parallel Query的能力。

總結和展望

無論是NewSQL還是Sharding，其都要解決分布式中的四個主要問題，即可靠的存儲、分布式事務、分布式查詢以及GMS中繼資料。針對存儲而言，DRDS依賴于MySQL，而MySQL自90年代至今在TP領域深耕近30年，擁有良好的背書。而DRDS在分布式事務、分布式查詢以及GMS中繼資料方面都是建構在經過四、五十年的工程和理論基礎之上的。在早期，DRDS對外呈現的更多是以中間件形态，而經過多年的沉澱和積累，DRDS已經在按照标準資料庫核心重新定義Sharding技術了。

傳統資料庫架構和基于DRDS架構分享

彙付天下資深資料庫DBA趙懷剛為大家分享了如何從傳統資料庫轉向DRDS架構。

為什麼從傳統資料庫轉向DRDS

傳統關系型資料庫已經發展經過了40多年，其在企業級特性、執行效率、資料庫生态及資源層面已經非常成熟。但是關系型資料庫在設計之初并沒有考慮擴充性。是以，當使用傳統關系型資料庫遇到以上問題之後一般會進行垂直更新，增加資源配置，用更強的硬體可以在一定的時間内能夠提升資料庫的容量和性能，但不能解決所有的業務場景，并且成本非常昂貴。

相比傳統資料庫，DRDS在水準擴充和成本方面具有明顯優勢，但在可維護性方面較為複雜。DRDS如今已經能夠提供資料生命周期管理、多種存儲類型、多可用區、SQL審計以及資料恢複等企業級資料庫特性。

DRDS應用實踐探索

DRDS非常重要，是以在應用之前做了壓力測試、功能測試、穩定性測試以及業務驗證。經過測試發現DRDS在響應時間、吞吐量等名額上的表現很好，在業務驗證時将一些試點項目接入到DRDS上并不斷總結經驗，形成規範并完善架構。經過長時間的測試驗證，發現DRDS更加适合混合順序寫密集場景如訂單、日志、流水等資料。

驗證完成之後就着手進行遷移，這個過程分為了資料遷移和流量遷移兩部分。資料遷移完成之後需要做一緻性校驗，之後再進行流量遷移。

DRDS提供了兩種類型的隻讀執行個體，即分析型和并發型，可以根據不同的場景進行選擇。整體架構也會遇到一些問題，比如在不斷發展過程中需要對執行個體規格進行不斷更新，更新過程中可能會存在30秒閃斷，底層存儲節點更新會導緻DRDS叢集不可用。這些問題對于7×24小時的業務而言依舊不夠友好，是以對于架構進行了改進。将單個DRDS叢集拆分成多個，通過智能網關做流量轉發、負載均衡，将流量路由到不同的DRDS叢集。

分布式資料庫設計原則建議

在做分庫分表之前，需要按照業務模型對交易型資料進行簡單劃分，可以将資料劃分為流水型、狀态型、配置型。流水型資料量大并且相對獨立，适合水準分片表。狀态型資料帶有狀态并且生命周期長，适合垂直分片表。配置型資料量比較小，并且是讀多寫少，是以适合全局廣播表。做分庫分表拆分的時候有三點原則，即拆分字段要有固定性、分離性和伸縮性。分庫分表的設計最終是為了達到線性擴充的目标，可以根據邏輯QPS和實體QPS的比值是否接近1來判斷。

分布式資料庫DRDS核心訴求有三點，即透明可擴充、強大的HTAP能力以及全面支援線上DDL。

深入解讀 OceanBase企業級資料庫的分布式技術

螞蟻金服OceanBase 資深技術專家韓富晟為大家深度解讀了OceanBase背後的分布式技術。

金融科技的基礎設施

資料庫行業正在經曆從傳統資料庫向分布式資料庫遷移的過程。分布式資料庫理論早在上世紀80年代就已經提出，經過30年的發展逐漸被應用各個行業中。現在和過去的不同在于，以前資料庫以硬體為中心，而如今資料中心出現了大量标準化的廉價伺服器，資料庫正在轉變為以軟體為中心，這導緻架構選擇和輸出方式的不同。

而在未來，分布式資料庫一定會成為各個金融以及非金融機構的選擇，也希望OceanBase能夠在這一過程中幫助企業解決更多的問題。

OceanBase新版本特性

目前，OceanBase 2.2版本即将對外釋出，該版本在Oracle相容性、事務處理能力以及性能方面都有了較大程度的提升。OceanBase 2.2版本實作了Oracle常用資料類型的全相容，對于各種函數、表達式、視圖、字典、存儲過程以及部分系統包都能夠支援。減少了遷移過程中的再次開發工作，可以甚至做到無縫遷移。

分區管理是大資料量或者長期資料管理過程中一個很重要的功能。OceanBase依賴分區能力在分布式系統做資料擴充，它完全繼承了Oracle等資料庫的分區方式，本次新增的功能可以幫助企業更加友善地管理分區資料。

OceanBase2.2版本提供了新的SQL計劃管理能力，當SQL已經生成的計劃發生變更的時候可以以灰階可驗證的方式進行變更，隻有表現比原有計劃更優秀時才會實作計劃變更，以保證業務的穩定性。

OceanBase2.2提供了更加完善的分布式事務支援能力，如可串行化隔離級别的能力、savepoin/rollback to以及外鍵限制等。

OceanBase 2.2在性能方面也有長足的進步，OLTP業務性能最高能夠提升50%，OLAP業務性能最高能提升100%。在今年的“雙11”， OceanBase将幫助螞蟻金服節省約50%的機器資源。此外，OceanBase 2.2還提供了等保三級的安全能力，并能夠支援更多的字元集以及視窗函數等。

在服務企業資料庫的過程中，OceanBase從最開始自主研發到現在已經過走了9年時間，相較于Oracle、DB2，OceanBase還很年輕，但是有信心可以幫助企業更好地解決業務問題，實作從傳統資料庫架構向分布式資料庫架構的轉型。

分布式存儲引擎X-Engine 的探索之路

阿裡雲智能資料庫産品事業部進階技術專家王劍英為大家介紹了分布式存儲引擎 X-Engine 的探索之路。

阿裡巴巴的技術挑戰

阿裡巴巴體量非常大，每年雙11面量的流量洪峰更大，雙11當天的銷售額會達到平時的數十倍，并且在零點那一刻積蓄了大量的流量，會達到平時的100倍以上，此時資料庫面對的巨大壓力。這也是阿裡巴巴從Oracle轉向MySQL以及後續的RDS和DRDS的原因。雖然可以不停地擴充拆庫，将流量切散，但最終還是要提升單機的能力。是以，阿裡做單機資料庫引擎的動機就是解決流量洪峰的負載問題。此外，因為阿裡的體量巨大，是以會産生大量的資料積累，是以需要更友善地快速讀取索引，這也是一個巨大的挑戰。

而且阿裡的淘寶、天貓等業務的交易資料通路頻次也有明顯的特征，訂單的大量通路出現在交易後的兩三天内，大部分訂單在7天之後将不再被通路，如果将冷熱資料混合一起将不利于性能提升和伺服器資源的使用。綜上所述，阿裡巴巴面對着巨大流量洪峰和巨大資料量的挑戰。

X-Engine引擎的技術特點

之前AliSQL使用InnoDB引擎，而InnoDB存在擴充性瓶頸。X-Engine引擎則采用了LSM-Tree架構，并進行了創新。在架構最上層提供了高度并發的事務處理流水線，中間實作了無鎖記憶體表Memtable。此外，為了解決讀寫沖突，X-Engine将每個Meta資訊作為一個獨立版本。X-Engine對于磁盤存儲層也進行了整體重構，并且還引入了FPGA作為硬體加速器。

X-Engine重新設計了事務送出的流程，在事務送出的時候為了不讓太多的線程等待，會開辟一組等待隊列，事務會在隊列中搶奪成為Leader，借此消減請求。X-Engine還實作了多階段流水線，在Log Buffering和Log Flushing中間設定檢測變量，是以不存在等待。磁盤延遲很高但是吞吐很大，可以讓整個流水線流動起來。這樣就保證事務送出執行過程之中的每一步都沒有等待和睡眠喚醒過程，使得系統吞吐量非常高。

X-Engine在資料結構方面也做了一些創新，在記憶體索引方面實作了多版本的Memtable來存儲新增加的資料。此外，還對于Block Cache的結構進行了優化，降低了緩存失效率。并且為了使得對于熱點資料讀取更快，X-Engine還增加了Row Cache，提高了熱點行的查詢性能。

依靠前面提到對X-Engine的改造，和RocksDB進行性能對比效果如下所示，可以看出X-Engine具有較大的性能提升。

在做Slimming Compactions時存在兩個限制，CPU資源和IO消耗。為了解決上述問題，X-Engine将Extent分為四種類型，即Merge、Reuse、Split和Copy，這樣能夠在很大程度上緩解Compactions的壓力。

分析資料發現CPU上有很多很短的二級索引，在單機存儲裡面效果不好，于是X-Engine引入了新硬體FPGA。正常情況下，計算資源會在前台的使用者處理和背景的Compactions之間配置設定，增加了FPGA之後，背景任務全部交由FPGA處理，而解析、事務執行、加鎖等任務全部交給前台線程。這樣就不存在背景擾動，進而避免了性能抖動，進而提供了穩定的性能。

RDS MySQL (X-Engine)服務

X-Engine引擎預設內建在RDS 8.0版本中的，其屬于和InnoDB同等的引擎，隻需要在建立表時指定即可。X-Engine屬于事務存儲引擎，優點在于節省空間、更好的寫入性能以及冷熱資料分離。對比而言，InnoDB具有較好的Range Scan性能以及更好的相容性。

X-Engine能夠節省空間，在Link-Bench以及淘寶、天貓交易訂單庫資料庫的對比下，相比InnoDB能夠節省3到5倍空間。在阿裡巴巴内部，使用RDS X-Engine，淘寶交易資訊、釘釘消息資訊以及圖檔空間的Meta資訊分别節省了67%、84%和86%的存儲空間。因為LSM-Tree是寫優化的，是以RDS X-Engine能夠獲得極好的寫性能，不僅單線程比InnoDB表現更好，在多線程場景下也具有更好的表現。

POLARDB MySQL (X-Engine)服務

X-Engine除了在公有雲上提供服務，未來也會走向私有雲。X-Engine會接入到POLARDB的Share Everything架構中來，獲得存儲空間的動态擴充能力，并且友善在與全局資料不沖突的隻讀節點上進行資料分析。X-Engine和POLARDB結合之後，将會更好地利用FPGA等資源。