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

本專場是阿里雲分散式資料庫的年度盛會，多位阿里雲分散式資料庫領域核心專家以及業界專家進行了專題演講，內容涵蓋分散式 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等資源。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。