雲棲乾貨回顧 |「頂級玩家」集結！分佈式數據庫專場精華解讀

本專場是阿里雲分佈式數據庫的年度盛會，多位阿里雲分佈式數據庫領域核心專家以及業界專家進行了專題演講，內容涵蓋分佈式 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寫法，這就涉及到關係代數了。數據庫優化器所作的事情就是基於當前計算能力選擇更加好的執行邏輯。業界通過4、五十年的發展，在關係代數方面也有很是深厚的沉澱。

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元數據方面都是構建在通過4、五十年的工程和理論基礎之上的。在早期，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等資源。

---

本文做者：Roin123

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。