支付寶支撐2135億成交額的數據庫架構原理

OceanBase的SQL優化器和分佈式並行執行
摘要：本文主要介紹螞蟻金服自主研發的通用關係型數據庫OceanBase，OceanBase採用了分佈式架構，其經過技術創新在普通PC服務器集羣上實現了更好的可靠性、可用性和可擴展行。本文中，螞蟻金服OceanBase團隊資深技術專家潘毅（花名：柏澤）爲你們介紹了OceanBase，並分享了SQL優化器，分佈式事務的執行邏輯等內容，爲你們全面展示OceanBase底層事務引擎的技術創新。

1、OceanBase簡介

OceanBase是螞蟻金服自主研發的通用關係型數據庫，其採用了分佈式架構，目前支撐了螞蟻金服所有核心鏈路系統。

爲何要開發OceanBase
數據庫做爲基礎軟件，研發耗時較長且投入較大，那麼，螞蟻金服爲何不能採用現成的方案，如商業數據庫或者開源數據庫呢？曾經，阿里巴巴擁有亞洲最大的Oracle集羣，可是隨着互聯網業務的發展，尤爲是近十年的發展很是迅速，阿里每一年的流量呈指數型上升，並且在某些特定日期流量會出現激增，這也是互聯網行業與傳統銀行、電信等行業在數據庫應用方面的不一樣。傳統行業能夠制定將來幾年的規劃，如客戶規模、業務量等，這些在必定程度上都是可預測的。可是互聯網行業則不一樣，互聯網行業的流量變化很是快，一方面使用商用數據庫很難進行迅速擴展來應對阿里巴巴飛速增加的規模；另外一方面，傳統數據庫的可靠性、高可用性等都須要依靠極其昂貴的硬件來實現，成本將會很是高昂。同時，阿里巴巴在高峯和平峯流量差異巨大，所以經過硬件實現特殊日期的高流量支持會形成嚴重的資源浪費。綜上所述，現有的商業數據庫並不能很好的支持阿里巴巴的整個互聯網產業。而採用開源數據庫一樣也會致使一系列的問題，以MySQL爲例，第一點，互聯網產業的業務流量大，且併發高，須要每個查詢都要在極短的時間內執行，所以對於通用數據庫而言，必需要掌握核心的代碼才能保證穩定的業務需求。第二點，金融行業須要具有強大的分析、查詢能力的數據庫，而MySQL在分析查詢方面的能力比較薄弱，沒法知足業務需求。出於以上緣由，螞蟻金服須要開發一款數據庫來知足自身的業務需求。

2、OceanBase架構

該部分將從集羣拓撲、分區&分佈式協議、存儲引擎三個部分介紹OceanBase的架構設計。
1. 集羣拓撲
多副本：通常部署爲三個子集羣，每一個子集羣由多臺機器組成，數據存儲在不一樣的集羣中。
全對等節點：每一個節點的功能對等，各自管理不一樣的數據分區。
不依賴共享存儲：共享存儲的價格較爲昂貴，故採用本機存儲的方式。

2．分區&分佈式協議
數據分區：支持數據分區，每個數據以分區爲單位做爲管理組，各分區獨立選主，寫日誌。
高可用&強一致：經過PAXOS協議保證數據（日誌）同步到多數機器，發生故障時自動切主。

3. 存儲引擎
OceanBase採用的存儲引擎是經典的LSM-Tree架構，數據主要分爲兩個部分，分別是是存儲於硬盤的基線數據（SSTable）以及存儲於內存的增量數據（MenTable）。在該存儲引擎中，全部數據的增刪改操做都會在內存中進行，並造成增量數據，每隔一段時間將增量數據和基線數據進行合併，來避免對於SSD的隨機寫。由於對於數據庫的操做爲全內存操做，因此DML操做的效果很是好，但若是某一段時間的數據修改操做很是多，數據量過大，致使內存溢出，在這種狀況下OceanBase提供了相應的解決方案，即轉儲操做，轉儲會將數據移動至硬盤上，但不會進行數據的合併操做，在後續合併時，會同時對增量數據，基線數據和轉儲數據一塊兒進行合併。能夠看出這個架構會面臨一個很大的挑戰，即在進行增刪改的操做後，再進行查詢操做，可能須要對基線數據和增量數據進行融合，所以在該架構下，讀操做可能會受到必定的時間懲罰，這也是SQL優化器須要進行考慮的問題。事實上若是優化器不是基於自身架構和業務需求來進行開發的，可能不會得到良好的效果，這也是爲何要自研數據庫的另外一個理由。

3、SQL優化器

SQL優化的目標是最小化SQL的執行時間（計劃生成+計劃執行），該部分主要會從OLTP（Online Transaction Processing）和OLAP（Online Analytical Processing）兩個方面進行SQL優化的介紹。對於數據量巨大的查詢來講，計劃執行每每佔據大部分的時間，可是對於不少數據量較小的查詢，更多的要考慮計劃生成的優化方案。

1.基於LSM-Tree結構的代價優化器
OceanBase優化器是基於經典的System R模式，主要進行兩個階段的優化。第一階段是生成基於全部關係都是本地的最優計劃，主要考慮的是CPU和IO的代價；第二階段是並行執行優化，考慮的是CPU，IO，Network和Overhead的代價。同時，代價模型也須要考慮LSM-Tree結構的特色，好比進行MemTable和SSTable的數據融合，不一樣表的代價可能不一樣，所以代價須要採用動態採樣計算；系統爲分佈式share nothing系統；索引回表操做會有額外的代價開銷，使用的是邏輯的rowkey而不是物理的rowid，所以回表的時間消耗會增長等，這些都是優化器須要考慮的因素。

2.優化器的基本能力
優化器主要包括兩種類型，分別是邏輯優化器和物理優化器，邏輯優化器主要作查詢改寫等操做的優化，好比基於規則和基於代價的優化，物理優化器主要對鏈接順序，鏈接算法，訪問路徑進行優化，同時會考慮到Meta Data，好比統計信息，表分區信息。當有了統計信息和代價模型後，就能估算出模型的執行代價，而後選擇出代價最好的模型進行相應的操做。而計劃管理模塊，對於OLTP的意義更加劇要，能夠更好的對短查詢進行優化。

3.優化器的統計信息
OceanBase優化器實現了很是完備的統計信息，包括表（avg rowlen, # of rows），列（column NDV, null value, histogram， min/max），分區／行級的統計信息。爲了防止引入額外的開銷，統計只會在數據進行大版本合併的時候進行。存儲引擎對於某些謂詞能夠提供較精準的數據量Cardinality估計，好比經過謂詞能夠推算出掃描索引的開始和結束區間，在SStable中每一個block都有metadata統計行數，在MemTable中能夠統計關於insert，delete，update操做的metadata。在OceanBase中，若是數據在合併過程當中進行了修改，會致使數據不夠精準，此時將採用動態採樣的方式來解決該問題。

4.訪問路徑
由於OLTP的SQL查詢計劃比較簡單，通常來講每每是單表，單索引的查詢，因此訪問路徑對於OLTP很是重要。所以進行SQL查詢時要進行相應的選擇，例如主鍵掃描仍是索引掃描，採用單列索引仍是多列索引。選擇的標準主要基於規則模型和代價模型，規則模型包括決定性規則（如主鍵全覆蓋則採用主鍵掃描進行查詢）和剪枝規則（運用skyline剪枝規則，多個維度比較，選擇更好的索引）。以後再經過代價模型的比較選出最優模型進行查詢。模型主要考慮的因素包括：掃描範圍，是否回表，過濾條件，Interesting order等。

5.計劃緩存
計劃緩存是指在一個計劃生成以後，後續若是出現同一個查詢或者類似的查詢，可使用現有的計劃而無需從新生成計劃，計劃緩存經過高效的詞法解析器匹配輸入的查詢語句，使用參數化查詢優化進行匹配。下面爲一個計劃查詢的例子。

能夠看到，在計劃緩存中對於查詢語句會進行參數的模糊匹配，但對於特定含義的參數會加入限定條件，好比order by 3中的參數3表明是第三列，該參數的修改可能會致使計劃緩存的不適用，所以存儲計劃緩存時加入了限定條件@3 = 3。

6.自適應共享計劃
對於一個查詢語句只要參數類似就必定能進行計劃緩存的匹配嗎？答案是否認的，舉一個例子，在一個查詢語句中對於salesman由於數據量較大，會採用全表掃描的方式進行查詢，而對於president，由於數據量很是少，可能經過索引的方式進行查詢的代價要比全表掃描的代價更好，所以對於這種狀況，一樣須要加入相應的限定條件。但從新生成的計劃可能和原有計劃相同，發生這種狀況後，便會對於原有的限定條件進行修改，方便以後的查詢語句進行計劃匹配，以此來達到自適應計劃共享。

7. Hint/Outline
在OceanBase中若是對於自動化生成的計劃不滿意，也能夠經過建立Outline的方式來綁定自定義的計劃，也就是經過Hint來制定計劃的生成，Hint的類型十分豐富，包括：access path, join order, join method, parallel distribution等，下面是Outline綁定的兩個例子。

8.SQL計劃管理及演進
不少用戶特別是企業級用戶對於穩定性的要求很是高，所以OceanBase在進行系統升級，統計信息更新，硬件更新後會自動進行一個流量的演進，即同時運行新計劃和老計劃，當肯定新計劃相較於老計劃無性能回退時，纔會逐漸將老計劃替換成新計劃。

9.分區及分區裁剪
OceanBase支持多種分區類型，包括Range，Hash，Key，List。對於二級分區支持Range/Range, Range/Hash, Range/List, Hash/Hash, Hash/Range等。對於靜態或動態分區裁剪支持inlist， 函數表達式，join filter等多種方式。

10.查詢改寫
查詢改寫主要包括基於規則的改寫以及基於代價的改寫，基於規則的改寫主要包括視圖合併，子查詢展開，過濾條件下推， 鏈接條件下推，等價條件推導，外鏈接消除等。基於代價的改寫主要包括OR-expansion，Window function等，查詢改寫對於OLAP的優化效果很是好。下圖爲基於代價模型的改寫框架。

4、SQL執行引擎

優化器和執行引擎是相輔相成的，優化器所能優化的計劃取決於執行引擎的執行計劃。
1.並行執行
並行執行的概念就是分治，分治包括垂直分治（好比拆分計劃爲子計劃單元）和水平分治（好比GI(Granule Iterator)獲取掃描任務），並行執行主要用於OLAP場景中，解決查詢RT時間的問題，這在不少在線分析的場景下是十分必要的。RT時間對於RDBMS查詢是一個重要指標，傳統的Map-Reduce的執行性能並不能知足OLAP的性能需求，所以如何找到高效的執行計劃及數據流水線很是關鍵。在OceanBase中採用兩級調度，自適應的子計劃調度框架，各節點獨立的任務切分等方案來進行並行執行。對於數據重分佈，OceanBase支持大多數常見的數據分佈，包括Hash， Broadcast/Replicate,，Round Robin，Merge Sort等。

2.兩級調度
在OceanBase中經過下面所述的方式造成兩級調度。即將查詢涉及到的各個機器上分別建立一個執行節點（SQC），來讓主控節點（QC）控制SQC，其中QC爲機器級的控制，SQC爲線程級的控制。QC進行全局調度，依據總並行度分配各節點各子計劃並行度， SQC進行本機調度，其中各節點獨立決定水平並行粒度及執行。

3.計劃動態調度
計劃動態調度是指根據用戶指定或系統資源自適應決定在容許的資源使用範圍內，減小中間結果緩存，構建2組或以上計劃子樹的執行流水線(垂直並行)，這種方式能夠有效的避免物化，減小物化算子對並行執行所形成的不良影響。該功能正在開發測試中。

4.並行執行計劃
OceanBase中擁有全部主要算子的並行執行方法，包括nested-loop join, merge join, hash join,aggregation, distinct, group by,window function, count, limit等，同時支持豐富的重分佈方法和多種候選計劃，例如partition-wise join, partial partitionwise join,broadcast, hash, sort(for distributedorder by)等。
事實上，並行查詢的優化技術在MPP架構下產生了新的問題，好比分區鏈接要求各表的分區從邏輯上和物理上都是同樣的，這也是一個須要考慮和優化的方向。

5.編譯執行
傳統執行方式如類型檢查，多態(虛函數)對於內存操做很低效。OceanBase考慮採用LLVM 動態生成執行碼，SQL表達式能夠支持動態生成執行碼，存儲過程採用直接編譯執行的方式，來進行性能提高。

整理：楊德宇