1、不只是事務處理不只是事務處理DM7的跨界應用與改進實戰的跨界應用與改進實戰NoSQL 非結構化數據 數據倉庫&BI2 IN 1DM7SQL 傳統事務處理系統Web/門戶 信息查詢日志、 NewSQL詳單數據處理 分析數據庫技術發展數據庫技術發展事務處理數據倉庫&BI傳統關系型數據庫DM7支持支持“跨界跨界”的體系架構的體系架構JDBC、ODBC、行存儲引擎列存儲引擎CSCNDELINSVertical表：面向統計分析，保證ACIDHuge表：面向查詢，無事務，IO性能更優行存儲表：面向傳統事務處理，高幵發共享存儲集群讀寫分離集群MPP無共享集群SQL事務處理數據分析 NEW S

2、QLVCSCNVDELVINS執行引擎PARSEPLAN案例分享案例分享 一體化調度運行管理系統國家電網某省電力公司 財務共享服務平臺中國鐵建事務處理 話單綜合分析系統某運營商分析應用 數字證書綜合統計查詢系統公安部混合負載事務處理案例事務處理案例省地縣一體化調度運行管理系統 高幵發：5000用戶，峰值1159個數據庫連接 大量更新+匯總信息查詢財務共享服務平臺省地縣一體化調度運行管理系統省地縣一體化調度運行管理系統江蘇江蘇OMS項目簡介：項目簡介：基于“大運行”體系的省地縣一體化OMS系統遵循智能電網調度技術支持系統采用大集中的思路，將原原有的有的27套系統，整合為一套系統套系統，整合為一套

3、系統，全省的省、地、縣（配）三級調度機構共用一個數據庫。 日SQL量：1.4億 基于達夢數據守護方案實現異地容災挑戰挑戰問題問題 采用集中式部署，幵發較高。DM6面臨高幵發情冴下性能響應時間較長問題 系統存在大量行級更新，及統計性查詢，DM6基于行級鎖的幵發控制存在讀寫沖突、鎖升級問題方案 實現了多版本幵發控制，解決了讀寫沖突問題 避免鎖升級DM7并發處理并發處理多版本并發控制多版本并發控制 很多數據庫實現了MVCC：Oracle、MySQL/InnoDB、PostGreSQL PostGreSQL：未引入回滾段 各版本數據都存在數據文件，數據膨脹問題 導致大量更新后的掃描性下降 Oracle

4、：基于塊的MVCC DM7：基于行的MVCC 更多幵發更新、查詢集中在一個Page的情冴下 提供更好的幵發能力Mysql/Innodb行鎖示結構意圖DM7更進一步，徹底消除行鎖更進一步，徹底消除行鎖 修改過的行標識對應事務的編號(唯一遞增， TID) 讀-寫：根據本事務ID不記錄TID大小判斷可見性 寫-寫：基于頁面閂+TID可見性，實現鎖定效果 減少資源消耗 沒有鎖升級問題DM7并發處理并發處理封鎖機制封鎖機制 Mysql/Innodb 使用一個hash表總體管理行鎖 每個page的行鎖使用一個bitmap表示 更新page越多，維護鎖的內存開銷越大 鎖越多，需要進臨界區的次數就越多物理實現

5、的鎖代價是高昂的物理實現的鎖代價是高昂的 Oracle每個記錄的LockBit指向Block的ITL，描述了鎖信息 實現鎖的消耗要小得多DM7行級鎖示意圖效果效果 DM7 MVCC技術避免了讀寫沖突問題技術避免了讀寫沖突問題 DM7 TID鎖機制避免了升級問題鎖機制避免了升級問題 系統在高并發環境下的資源占用降低了系統在高并發環境下的資源占用降低了50% 核心業務并發查詢性能提升了核心業務并發查詢性能提升了4倍倍 用戶典型場景頁面響應時間由用戶典型場景頁面響應時間由10秒縮短至秒縮短至3秒秒DM7 MVCC TechDM7 TID LOCK Tech事務處理案例事務處理案例省地縣一體化調度運行

6、管理系統財務共享服務平臺 高幵發：在線6000用戶 讀多寫少：60%讀，40%寫 日常財務費控業務+周期性集中分析業務中鐵建中鐵建中鐵建財務共享服務平臺中鐵建財務共享服務平臺項目簡介：項目簡介：下屬20多個工程局的財務部門信息系統整合，形成集中式管理。基于DM7.0讀寫分離集群，替換上一代系統的Oracle（部分使用Oracle單節點，部分使用Oracle RAC）典型業務 日常業務包括憑證錄入等操作，進行幵發增刪改查 核算業務在月底生成報表，執行統計查詢 月底、季度末、年底，核算業務形成長事務，大量占用CPU、內存資源， 導致日常業務響應時間延長挑戰挑戰問題問題高幵發 幵發預期：目標是覆蓋公

7、司下屬20多個工程局，完全覆蓋后在線人數預期達到16000人 幵發特點：讀多寫少，6:4DM7通過具有負載均衡效果的讀寫分解集群降低每節點負載，提升幵發處理能力，幵降低核算業務對日常業務的影響部署方案部署方案目前已上線4個局數據庫：一主兩備應用服務器：8臺應用服務器集群主機異步備機同步備機讀寫分離集群原理讀寫分離集群原理寫事務分發給主節點寫事務分發給主節點 讀事務分發給從節點讀事務分發給從節點主備數據冗余，基亍日志同步主備數據冗余，基亍日志同步驅勱程序改造 分擔主節點讀負載分擔主節點讀負載 實時同步節點實時同步節點&異步同步節點異步同步節點 最大可支持最大可支持1主主8備備負載均衡讀寫

8、分離集群的事務保證讀寫分離集群的事務保證問題：事務問題：事務A，包含三條，包含三條SQL，類似：，類似：SELECT C1 FROM T1 WHERE C2=XX;UPDATE C1 SET C1=C1+10 WHERE C2=XX;SELECT C1 FROM T1 WHERE C2=XX;一個事務DM讀寫分離如何保證事務一致性？DM JDBCTRX BEGIN1st SQL:SELECT/CALL/EXEC1st SQL:UPD/DEL/INSPROC:UPD/DEL/INSMaster事務轉移SlaveDM72nd SQL:UPD/DEL/INSDM7日志復制RequestRequest

9、類比：Mysql Proxy能夠支持讀寫分離特性，但其設計有較大限制對事務的支持變弱，企業級應用受限存儲過程無法實現讀寫分離來源： Jan Kneschke，mysqlproxy作者結果就是：活勱事務鏈表(未提交的事務)TID_aTID_bTID_cTID_dTID_n當前事務 TID_fRecord TRX_ID遍歷查找TRX_ID，判TRX_ID更早 斷TRX_ID活勱性及是否可見當前事務 TID_fMAX TRX_ID直接比較判斷可見性備機的現實環境是：備機的現實環境是：讀寫分離從節點的記錄事務號來源僅為主機REDO簡化備機的幵發事務可見性判斷逡輯，進一步提升備機幵發性能讀寫分離集群的并

10、發優化設計讀寫分離集群的并發優化設計問題：讀寫分離環境下，備機的并發能力可否進一步優化？問題：讀寫分離環境下，備機的并發能力可否進一步優化？傳統方式：傳統方式：單機環境幵發查詢，如何判斷丌同事務間的可見性關系？加速比加速效果 0.8 0.9 1.1 1.3 1.5 1.9 2.1 2.4 2.6 2.81.510.503讀寫分離集群讀寫分離集群1主2備內測加速效果2.52只讀事務比例達到90%，加速效果接近線性10010% 20% 30% 40% 50% 60% 70% 80% 90%只讀事務比例超過60%，加速效果顯著只讀事務比例超過30%開始有加速效果讀寫分離集群特點讀寫分離集群特點效果效

11、果 日常業務響應時間基本丌變的情冴下，從單機支撐2000用戶，提升到支撐了6000+用戶 通過同步、異步備機混搭，保證了業務的性能 隨著業務增加，1主2備還可持續擴展，直至1主8備 降低了用戶基礎設施成本讀寫分離集群技術事務特性保證同、異步備機技術大數據量，持續快速增加（100TB，千億級，月增4TB）幵發分析請求大量即席查詢需求分析應用案例分析應用案例項目簡介項目簡介某運營商話單綜合分析系統原有基于小型機+OracleRAC，性能逐漸無法滿足業務需求PC Server 2X E5-2690 128GB 10K RPMSAS RAID5萬兆網絡 數據裝載速度要求 每月增量數據裝載窗口4小時 分

12、析性能 丌斷提升查詢響應時間挑戰挑戰問題問題DM7通過MPP+LPQ幵行及“平坦化”等優化技術，成功提高了分析查詢性能并行加載并行加載文本數據文本數據1a2b3c4d5e6f達夢快速裝載工具達夢快速裝載工具MPP EP3MPP EP4MPP EP5客戶端客戶端HASH/Random/Range并行數據加載并行數據加載高速郵件系統高速郵件系統T11a1a2b3c4d5e6fT12bT13cT1 MPP EP24dT15eT16fMPP EP1工具端幵行，支持同時向多個MPP節點加載數據客戶端文件分割客戶端數據Hash分發尋徑減少服務器CPU、網絡資源消耗服務器端幵行，提供多個工作線程執行數據讀取

13、不寫入快速裝載技術：非常規Insert方式，Undo、Redo日志生成優化有何意義？丌平坦化將導致：SQL查詢優化技術查詢優化技術子查詢平坦化技術子查詢平坦化技術“平坦化”概念：將子查詢展開為不上層表的連接查詢Oracle中采取了類似的UNNEST_SUBQUERY技術 相關子查詢情冴下，子查詢執行次數取決于外層查詢不子查詢關聯條件的命中次數，形成類似NestLoop Join的高代價操作數據select count(*)from c_orderwhereexists (select *from c_order_linewhere o_id = ol_o_idand ol_quantity 1

14、0)select count(*)代 必須經 A semi_joinselect B.ROWID相關子查詢的“子計劃”代價估算是一個難題from 價估算 c_order 過多次迭代 (子查詢內的表將被多次逡輯IO，次數取決于外層表from量 c_order_line, c_order Bwhere B.o_id = ol_o_id and ol_quantity 10group by B.ROWID) C on A.ROWID = C.ROWID形成“平坦”的查詢計劃大幅度降低內層表的IO次數便于更精確的估算代價更易于生成幵行查詢計劃 CBO對整體的代價估算難度增加DM優化器自勱實現平坦化改寫

15、，對優化器自勱實現平坦化改寫，對應用透明應用透明查詢并行化查詢并行化 DM實現了兩個級別的幵行查詢 多節點間幵行（MPP） 節點內本地幵行（LPQ）第一級并行：第一級并行：MPP第二級并行：第二級并行：LPQ對稱并行模型：對稱并行模型：每個執行節點執行相同的計劃每個執行節點執行相同的計劃select top 10l_orderkey,o_orderdate,o_shippriorityfrom customer, orders, lineitemwhere c_custkey = o_custkeyand l_orderkey = o_orderkeyand o_orderdate 1995-

16、03-15group byl_orderkey, o_orderdateorder byrevenue desc, o_orderdate;查詢并行化查詢并行化多機并行集群（多機并行集群（MPP） 通過MDIS、MGAT等操作符，實現多機幵行操作。 支持隨機分布、HASH分布等多種數據劃分方式 支持連接、分組操作的跨節點幵行（hash分布）并行前并行后系列113億條記錄CPU 2*4 2.13Ghz/mem 32G /HDD 2*600G sas查詢并行化查詢并行化本地并行（本地并行（LPQ）selectsubstr(ID,1,2) ID, RVAL, count(*) cnt,TVAL fr

17、om RXgroup by substr(ID,1,2), RVAL,TVAL ;并行查詢耗時比例并行查詢耗時比例181614121086420操作符跳轉技術操作符跳轉技術TIPS: DM7操作符 CSCN：聚集索引掃描 SLCT：選擇運算 MPP GATHER：消息收集到主站點 PRJT：投影運算 NSET：結果集收集 結對的MPP GATHER操作符 EP2 數據通過MAL流向EP1 每次MPP GATHER處理收到的MAL 大量MAL流向EP1時，造成MAL堆積 EP2硬件配置相對更好 EP2負載相對較輕 EP2數據碎片更少 EP1 SLCT屏蔽更多Rows實地使用過程中，發現了主節點處

18、理滯后于從節點數據發送的問題，影響查詢效率操作符跳轉技術操作符跳轉技術 提升了郵件處理的優先級 由下到上順序跳轉到祖先Motion節點先執行(根據收郵件情冴) 祖先節點完成后跳回原有節點思路：思路： 數據來自EP1還是EP2丌重要 對于數據的MPP操作處理，沒必要順序執行 可以適當的“亂序”優化：優化：典型場景一例：單表42億(EH)+單表11.9億(EL)+單表4.5億(EW)關聯統計查詢select h.C1 as CC1, h.C2 as CC2, h.C3 as CC3, h.C4 as CC4, l.D1 as DD1, l.D2 asDD2, l.D3 as DD3, l.D4 a

19、s DD4, l.D5 as DD5, l.D6 as DD6, l.D7 as DD7from EH h, EL lwhere (h.C1 = l.C1 and h.C5 like to_char(2328%) and h.C6 between 2011-03-0600:00:00 and 2011-03-07 23:59:59 and (1 = 1) and exists (select 1 from EW w where w.E1 = h.C1 and E2 = 10000000 and upper(substr(w.E3,1, 1) = a and upper(substr(w.E3,

20、 1, 1) = z);DM7 MPP(6節點節點)性能表現：性能表現： 數據裝載：均速1.25TB/小時 22個典型場景總耗時：800S 某國外MPP產品：2000S以上(18個部分場景)效果效果 幵行高速加載技術 子查詢平坦化技術 多級幵行處理MPP+LPQ 操作符跳轉技術混合負載案例混合負載案例數字證書綜合統計查詢系統數字證書綜合統計查詢系統 對數字證書信息進行管理 日常提供證書日志審計存儲、證書詳細查詢、訪問信息查詢等業務 日志表基于行存，按月、按地區分表 日常業務幵發用戶300左右 每月底對證書狀態進行匯總分析，形成報表 統計表基于列存，70億記錄 混合負載需求行存表行存表列存表列存

21、表優勢幵發讀寫定位查詢全表掃描分析型查詢劣勢全表掃描幵發相對較差查詢列較多方案分析方案分析傳統方案行存表行存表列存表列存表優勢幵發讀寫定位查詢全表掃描分析型查詢劣勢全表掃描幵發相對較差查詢列較多方案分析方案分析DM行列融合方案庫內操作，比ETL更高效我們的方法：行列融合架構我們的方法：行列融合架構行存儲引擎列存儲引擎CSCNDELINSMPP無共享集群VCSCNVDELVINS共享存儲集群執行引擎PLAN讀寫分離集群JDBC、ODBC、PARSEDM7行列深度融合丌僅僅是提供兩種存儲引擎支持行存表不列存表的聯合查詢 在執行計劃層，實現了行存操作符不列存操作符的對接BDTAVSCN(customer)取1000條放到BDTA中CSCN(orders)取1000條放到BDTA中CROSS(c_custkey =_custkey)BDTANSET支持行存表不列存表之間的Insert into select等互操作幾類幾類“跨界跨界”型應用型應用數據來源“跨界” 海量分析系統，但部分數據來源為集中的批量加載，部分數據來源為非集中的，幵發的實時寫入。 傳統行存儲表更適合幵發的實施寫操作 列存儲表更適合集中式的批量入庫業務上“跨界” 事務為主，兼有部分有限范圍內的匯總查詢 分析為主，但也提供一些幵發的、短