《從 TP 到 AP _ OceanBase SQL 引擎的探索和實踐_朱濤.pdf》由會員分享,可在線閱讀,更多相關《從 TP 到 AP _ OceanBase SQL 引擎的探索和實踐_朱濤.pdf(15頁珍藏版)》請在三個皮匠報告上搜索。
1、從從TPTP到到AP:AP:OceanBase SQLOceanBase SQL引擎的探索和實踐引擎的探索和實踐朱濤OceanBase 高級研發專家Contents01OceanBase SQL 引擎02互聯網 TP 業務03傳統 TP 業務04AP 業務目 錄OceanBase SQL 引擎概要介紹查詢請求(上海差旅到北京)解析優化規則改寫計劃管理計劃緩存灰度演進統計信息代價模型代價改寫基表路徑選擇連接順序連接算法其他代數算口分配執行靜態引擎向量化并口化內存管理硬件優化DAS購票候車行駛飛行值機到站落地達到高鐵站出發地機場北京酒店地鐵Xxx航班打車打車(堵車)打車(堵車)Gxxxx(時長較長
2、)地鐵(錯過末班車)02讓互聯網 TP SQL 跑的快單表短查詢 選準索引就是一切運維解決方案改查詢綁索引 HintVS自動改寫自動選擇自動汰換OceanBase 單表短查詢:過濾性很強的條件/Limit分頁控制,實際返回數據很少 性能挑戰:必須選準索引。但過濾條件復雜,表上索引很多的時候會有難度。單表上有 30 個索引案例一:案例二:SELECT id,value1,value2 FROM T1WHERE key1=1 or key2=2SELECT FROM T1WHERE STATUS IN(FAIL,UNKNOWN)ORDER BY gmt_create limit 20;03讓傳統業
3、務 TP SQL 跑的快多表(外)連接 連接次序至關重要 多表外連接普遍存在,復雜場景出現過17張表的外連接.性能挑戰:生成一個好的連接次序運維解決方案業務修改SQL 語句多數系統僅支持內連接的次序調整Others自 動 調 整 連接 次 序,改寫連接類型OceanBaseVSVS簡化案例SELECT.FROM t1 -10行LEFT JOIN t2 -1w行ON t1.c1=t2.c1LEFT JOIN t3 -10行ON t1.c1=t3.c1LEFT JOIN t4 -10行ON t1.c1=t4.c1ORDER BY t1.c1LIMIT 1000;無處不在的子查詢 子查詢用法更任意(
4、FROM,WHERE,HAVING,SELECT,UPDATE SET 等),數量更多(含十幾個子查詢)性能挑戰:相關子查詢容易跑的慢運維解決方案業務改造 SQL 語句,改連接VS支持豐富的子查詢優化策略,覆蓋更全面的場景,將子查詢改寫為連接。OceanBase案例一,賦值操作中的子查詢UPDATE t1SET value1=(SELECT sum(x.value1)FROM t1 x.),WHERE;案例二,OR 謂詞中的子查詢SELECT.FROM t1WHERE c1=1 OR EXISTS(SELECT 1 FROM t2 WHERE t1.1=t2.c1);案例三,大量子查詢SELE
5、CT DISTINCT(SELECT Count(ri.value1)FROM t1 ri.)s1,(SELECT Sum (ri.value2)FROM t1 ri.)s2,(SELECT Count(ri.value3)FROM t1 ri.)s3,(SELECT Sum(cc.value1)FROM t2 cc.)s4,(SELECT Sum(value2)FROM t2.)s5,(SELECT Sum(value1)FROM t3.)s6,.FROM t4 cr,t5 coi,t6 cmolLEFT JOIN t7 cc on.LEFT JOIN t8 cce on.WHERE .OR
6、DER BY cmol.m_opsn_seq;04讓 AP 業務 SQL 跑的快數據傾斜/負載傾斜 協同工作,拒絕摸魚 數據傾斜:一張大表數十個分區,某分區存在一個大賬號(行數達到總體的90%以上)性能挑戰:一個線程干活,其他線程圍觀REP_TAB_DATA partition by range(DBSID,QUEUEID)SELECT dbsid,queueid,COUNT(DISTINCT mid),FROM rep_tab_dataGROUP BY dbsid,queueid是是是場景是否支持是是JoinGroup ByTable ScanWindow Function運維解決方案調整分
7、區模式和 SQLVS針對數據/負載傾斜進行系統優化,加并行就能更快OceanBase是Ins/Del/Upd傾斜原因存儲單元間數據傾斜連接鍵上有高頻值分組鍵上有高頻值分組組合數量過少分組組合數量過少寫入數據有聚集性簡化案例:大表聚合 “聰明”的執行引擎 大表聚合:對幾十億規模的表進行聚合 性能挑戰:聚合下壓 or 不下壓,這是個問題分組數量 預聚合分組數量 行數=不預聚合支持支持支持自適應下壓場景是否支持支持支持Group by+去重聚合函數RollupDistinctGroup by+普通聚合函數Window Function運維解決方案沒辦法變量控制下壓與否Others執行自適應選擇下壓o
8、r 不下壓OceanBaseVSVS簡化案例SELECT year(sold_date)AS yearDate,code,name,SUM(value0)AS total_valueFROM tWHERE sold_date=2021-01-01AND sold_date2022-06-01 GROUP BY year(sold_date),code,name多語句跑批任務 讀取和寫入并重 AP 任務會產生大量結果集,在臨時結果集上繼續分析:單個任務包含多條10億級別的INSERT INTO SELECT 操作單條SQL一拆多,業務側加并發運維解決方案支持并行寫入,加并行讀的更快也寫的更快Oc
9、eanBaseVS每跑完一條查詢后收集一次統計信息運維解決方案在批量寫入的時候就把統計信息收集了OceanBaseQ1:INSERT INTO TMP1 /*10 億規模*/SELECT C1,C2,D2,D3 FROMA JOIN B LEFT JOIN C LEFT JOIN D;Q2:INSERT INTO TMP2 /*10 億規模*/SELECT SUM(C1),SUM(C2),SUM(C3)FROMTMP1 JOIN E GROUP BY Q3:INSERT INTO FINAL_TABLE/*10 億規模*/SELECT.FROMTMP2 JOIN F JOIN G LEFT J
10、OIN 簡化案例 性能挑戰 I:讀取量大,寫入量也大;性能挑戰 II:臨時生成數據的統計信息哪里來,Q2/Q3如何優化VS分區化,并行化帶來的復雜性運維解決方案改造分區方式,連接鍵作為分區鍵忽略分區存在,產生一個最好的計劃后并行化Others直接枚舉分布式計劃找出一個最優解OceanBaseVS15sT1查詢 RT2s分區表(15分區)單分區 AP 請求訪問的大表一般經過分區;分區模式是查詢優化的重點考慮因素 性能挑戰:分區大大增加了計劃選擇的難和復雜性簡化案例:SELECT.FROM(SELECT MAX(id)AS maxId,count(id)AS callNumFROM T1GROUP
11、 BY call_list_id)grINNER JOIN T1ON gr.maxId=em.id總結OceanBase OceanBase 版本版本1.X 2.X1.X 2.X2.X 3.X2.X 3.X3.X4.X3.X4.X服務業務 互聯網 TP 場景 互聯網 TP 場景 傳統 TP 場景 部分 AP 場景 互聯網 TP 場景 傳統 TP 場景 更多 AP 場景優化器基礎改寫能力索引選擇連接選擇兩階段分布式優化改寫能力豐富代價改寫能力新型連接枚舉框架非基表下推分布式計劃生成強化 改寫能力進一步豐富 輕量化改寫框架 一階段分布式優化 統計信息/估行整體增強 完整的計劃控制能力 執行計劃灰度演進 執行器弱數據類型計算全內存、不支持算子落盤分布式執行引擎新型并行引擎強數據類型計算靜態內存預分配算子落盤向量化引擎硬件特性挖掘并行下壓和自適應技術自適應算子內存管理Cache-Aware 優化基于編碼 filter 下壓Q&AGitHub:/oceanbase/服務號:OceanBase數據庫星球論壇: