專場2.1-分布式數據庫選型與實戰-林春（脫敏版）.pdf

《專場2.1-分布式數據庫選型與實戰-林春（脫敏版）.pdf》由會員分享，可在線閱讀，更多相關《專場2.1-分布式數據庫選型與實戰-林春（脫敏版）.pdf（23頁珍藏版）》請在三個皮匠報告上搜索。

1、金融分布式數據庫的應用與實踐林林 春春太平洋保險數智研究院首席數據庫專家QQ:1819442969支付寶APP微信云閃付F5/LVSF5/LVS高可用APPAPPAPPAPP.應用分布式應用負載均衡支付寶APP微信云閃付F5/LVSF5/LVS高可用APPAPPAPPAPP.應用分布式應用負載均衡業務數據業務_1業務_2業務_4業務_3業務數據 N業務數據 3業務數據 2業務數據 1分布式事務數據庫業務_1業務_2業務_4業務_3集中式Oracle/DB2分布式事務數據庫高可用分布式事務數據庫計算節點分布式事務數據庫存儲節點（MySQL企業）.數據庫瓶頸明顯分布式事務數據庫水平擴展Oracle

2、/DB2為多進程模式，為多進程模式，MySQL為單進程多線程模式，分布式架構更好支撐海量連接、海量并發、海量吞吐的業務場景。為單進程多線程模式，分布式架構更好支撐海量連接、海量并發、海量吞吐的業務場景。分布式數據庫對金融業的意義分布式數據庫產品現狀 分布式數據庫產品尚需金融業務場景打磨，尚無100%成熟的分布式數據庫產品。主要體現在數據庫產品BUG數量較多、金融業非功能性需求適配、數據庫開發及運維管理平臺不夠友好和數據庫周邊工具功能不足等方面。存量Oracle數據庫遷移改造存在痛點，主要體現在應用適配評估工具需提升、存儲過程改造工作量較高、遷移工具性能及穩定性需提升等。不同的分布式數據庫各有優

3、劣，需根據具體業務場景適配。面上主流的分布式數據庫分為基于proxy的分布式數據庫和原生分布式數據庫。原生分布式數據庫產品具有對應用侵入性少等優點，但是比起基于proxy的分布式數據庫需要有更多的代碼研發和改動，數據庫產品可靠性方面需要更多的驗證；而基于proxy的分布式數據庫也面臨如何將底座集中式數據庫新版本的新特性整合的問題。分布式數據庫產品處于可用向好用的演進中間狀態。后期分布式數據庫廠商的服務及支持、數據庫生態、數據庫產品底層掌控能力、軟硬件成本、服務成本及應用改造成本需要關注。分布式數據庫產品呈現多條技術路線同時快速發展的態勢。在分布式數據庫選型上和使用上需要采取高度兼容的策略，結合

4、業務場景需求，在選擇通用性兼容及生態較好的分布式數據庫產品后，需要考慮在應用開發中簡化、優化、標準化SQL，在適配分布式數據庫特點、提升應用性能的同時，做到技術產品靈活可控。1.異步復制2.半同步復制3.MGR組復制高可用集群讀寫分離集群讀MySQL從庫MySQL主庫寫分布式數據庫集群MySQL分片1主從主從主從MySQL分片2MySQL分片N業務業務1業務業務3業務N業務業務2SQL變化和分發MySQL主庫MySQL從庫數據量較小，單庫控制在1TB以內單表記錄數控制在5000W以內數據量較小，單庫控制在1TB以內，單表記錄數控制在5000W以內讀寫比差別大，可達到5:1以上數據量較大，數據庫

5、單庫數據量1TB以上，單表記錄數超過1億條高并發寫入，要求較高TPS分布式數據庫適用條件分布式數據庫的功能性主要考察分布式數據庫的基礎功能、SQL 語法標準、數據庫對象支持情況、單庫事務及分布式事務支持情況、數據切片算法等分布式數據庫的性能分布式數據庫讀寫性能、TPCC、多表關聯JOIN 查詢的性能等分布式數據庫的可靠性7*24 小時穩定性測試、模擬故障節點測試、斷電斷網測試等分布式數據庫的安全性數據庫鑒權、訪問控制、安全審計、高危 SQL 攔截、數據傳輸加密、備份加密及等保等級分布式數據庫的兼容性及可移植性支持國產芯片、國產操作系統、國產處理器、國產服務器及國產中間件分布式數據庫的可擴展性自

6、動化的擴縮容操作、水平擴容對業務的無感知、擴容支持自動化的數據重分布分布式數據庫的維護性故障分析、性能監測、故障自治自愈分布式數據庫的易用性運維管理支持可視化方式、自動化運維及智能化分析、自動化巡檢等12345678分布式數據庫選型考量信創數據庫工作推進思路2345知識庫體系化建設建設信創數據庫專業隊伍制定信創數據庫培訓策略制定信創數據庫技術支持策略16建設相關工具、平臺聚焦信創數據庫核心攻堅，培養全棧能力，建設專業隊伍。實現信創數據庫效率大幅提升降低應用改造難度與成本。建設信創數據庫知識庫體系，固化我司最佳實踐降低信創數據庫學習曲線，快速提升內部人員相應技能提供覆蓋架構、開發、運維的全生命周

7、期的數據庫技術支持跟進行業最新動態，研究新技術在我行應用的可行性行業動態研究信創數據庫知識體系構建建立一套完備的、先進的信創數據庫知識結構體系，是培養太保信創數據庫人才隊伍、構建數據庫服務能力的重中之重。構建時需要兼顧太保信創整體目標，同時又要融入攻堅過程積累的實戰經驗。遷移驗證遷移改造和驗證遷移規劃遷移規劃和準備上線切換切割上線和風險保障運維保障維護系統穩定運行架構設計類性能優化類運維技術類交付技術類信創流程詳解信創最佳實踐數據遷移工具及最佳實踐PL引擎的設計和最佳實踐架構及產品特點深度剖析數據庫選型最佳實踐存儲引擎高級技術運維技術及最佳實踐SQL監控和優化運維、監控與異常處理高級日志分析技

8、術性能優化與案例分享SQL引擎、事務高級技術以項目實戰談信創最佳實踐開發規范及最佳實踐兼容性改造最佳實踐上線流程詳解項目實戰談架構設計高可用高級技術容災、備份恢復高級技術參數最佳配置安全及權限回退的方法及實踐分布式事務原理內存管理及內存分配*紅色字體部分為高級技術紅色字體部分為高級技術內存原理執行計劃原理及最佳實踐索引的設計及最佳實踐項目實戰談數據遷移方案太保OB應用改造評估工具-“指南針”能夠依托知識庫沉淀對存儲過程代碼進行掃描分析，并初步給出問題原因、代碼位置。評估項全面、有效，提升了項目組問題排查的效率，從而降低應用改造的成本。能夠輔助識別冗余大表、冗余索引，有助“數據庫減負”。用以抓取

9、高負載時間段大事務SQL，便于遷移到OB或TD前提前優化以小時為維度，一天什么時間段日志負載最大以周為維度，一周周幾最繁忙以月為維度，一個月那天最繁忙用于識別未使用索引，進行瘦身實例啟動以來，從未使用過的索引超過5個索引的表識別未帶主鍵表識別全局索引識別識別實例啟動以來未修改過的表識別實例啟動以來未訪問過的表識別僅有插入、沒有更新、修改的大表無效索引識別失效對象識別長查詢畫像高CPU開銷SQL畫像高IO開銷SQL畫像高排序開銷SQL畫像數據庫畫像SQL畫像表瘦身畫像索引畫像表負載畫像日志負載畫像失效對象畫像前20位大表每日更新、插入、刪除記錄數（按更新記錄數排序）、記錄總數、平均記錄長度、表空

10、間大小、索引空間總大小更新排名前20位表每日更新、插入、刪除記錄數、記錄總數、平均記錄長度、表空間大小、索引空間總大小分布式數據庫遷移前數據庫畫像腳本功能SQL畫像表瘦身畫像索引畫像表負載畫像日志負載畫像失效對象畫像Oceanbase架構及性能優化關鍵點OCP集群可以管理多個OB集群，管理OBserver節點總數上限約為200個。單個OB集群OBserver節點總數不建議過多，通常不超過20個。OceanBase數據副本是以分區為單位。OceanBase 數據庫存儲引擎基于 LSM-Tree 架構，基線數據和增量數據分別保存在磁盤（SSTable）和內存（MemTable）中。對數據的修改都是

11、增量數據，只寫內存。讀的時候，數據可能會在內存里有更新過的版本，在持久化存儲里有基線版本，需要把兩個版本進行合并，獲得一個最新版本。Oceanbase系統架構Oceanbase存儲架構Oceanbase架構及性能優化關鍵點（續）設計集群時核心業務系統集群應獨立部署，控制集群租戶數量、合理利用分區優化數據生命周期管理，以最小化容災、備份數據集，減少轉儲次數進而減少非計劃合并次數，避免性能毛刺現象。非關鍵、低容量、沒有頻繁沒有頻繁DMLDML操作操作的數據庫可共用一個共享集群，租戶互相隔離，集群采用高配以節省軟件成本。freeze_trigger_percentage決定轉儲的內存閾值，minor

12、_freeze_times參數決定租戶的轉儲多少次觸發合并，在集群規劃時，租戶的負載、memstore內存大小需要考慮，以避免由于個別租戶頻繁轉儲導致整個集群合并，導致其他租戶成為受害者，盡可能避免寫放大對性能影響。OceanBase應用總設計原則是盡可能讓數據訪問、操作在內存中完成，減少轉儲造成讀延遲毛刺，每天定期合并釋放memstore內存及刪除記錄空間，最大限度減少寫放大、讀放大。租戶轉儲頻度需要巡檢中檢查，并評估內存大小、內存閾值設置、慢SQL開銷，從gv$memstore可以查詢租戶轉儲相關信息。優化SQL避免對不必要數據操作，否則會導致轉儲增多從而讀取時延出現明顯增大；優化SQL避

13、免請求讀取過多SSTable；盡可能避免對相同記錄做頻繁更新，否則查詢會在事務鏈表讀取更多事務節點，目前OB底層讀操作時，當鏈表的長度大于18時，寫操作時，當鏈表的長度大于6時會觸發compact。Oceanbase架構及性能優化關鍵點（續）OceanBase合并是以集群為維度，需要控制集群容量規模，以避免合并耗時過長，MemStore內存釋放不及時，導致MemStore滿而數據寫入失敗。major_freeze_duty_time參數控制定時合并時間，在關鍵業務日期或者重大變更時段，需要調整定時合并時間窗口或者暫停合并。OMS遷移數據前，建議先做合并，以最大騰出memstore內存空間用于遷

14、移。設計時需考慮盡可能同一租戶的表或分區數據放在相同OBserver上，數據訪問或修改盡可能避免跨OBserver。OceanBase備份是以整個集群為維度，不能單獨對某個租戶，因此需要集群規劃需要考慮備份時間窗口能否對集群完成備份，如果備份時間過長，需要在白天業務時間備份，需要考慮對備份進行流控，例如：使用backup_concurrency參數控制數據備份的并發參數，使用以下語句控制備份流量backup net limit for whole clusterRange:0M,max)；。目前OceanBase分布式死鎖僅能通過平臺手工檢測死鎖，死鎖無法通過圖算法自動改出死鎖，需要依賴ob_

15、trx_lock_timeout參數，默認參數為-1，建議生產環境設置該參數為建議生產環境設置該參數為10301030秒秒。OceanBase大事務需要做拆分。對相同記錄頻繁更新后，查詢需要有額外操作，會有一定讀延遲。TDSQL架構及性能優化關鍵點CN節點負責數據的分發和查詢規劃，每個CN節點都提供相同的數據庫視圖;DN節點處理存儲本節點相關的元數據，每個節點還存儲業務數據的分片。此外，DN節點負責完成執行協調節點分發的執行請求;GTM負責管理集群事務信息，同時管理集群的全局對象，比如序列等。TDSQL-PG通過GTM保證讀一致性，TDSQL-PG使用邏輯時鐘替代快照優化了帶寬和CPU開銷。T

16、DSQL-PG的分布鍵選擇對性能非常關鍵，交易場景不帶分布鍵會檢索所有DN節點數據，性能會有明顯下降，TDSQL-PG分布鍵需要盡可能避免跨節點檢索、操作數據,通常從主鍵、表連接字段、where條件中篩選度較好的字段中選取。TDSQL-PG系統架構DN、CN節點數據庫系統架構分布式數據庫使用建議01對數據類型、SQL特殊類型例如hint、外鍵、觸 發 器、sequence、db link、存儲過程等進行梳理；對業務系統中大表、訪問頻繁的表、表連接條件、where搜索條件進行梳理。SQL類型及關鍵信息梳理及SQL改造02基于proxy的分布式數據庫需根據業務類型特點、數據量，選擇分表、廣播表、單

17、表；原生分布式數據庫需注意表組設計、全局索引設計、復制表設計、分區鍵選擇等。表設計的選擇03盡可能使分片數據在數據節點均勻分布；避免無差別濫用分片；分片鍵字段必須是主鍵以及所有唯一索引的一部分；不要更新分片鍵字段的值；訪問的數據盡量包含分片鍵字段，否則不帶分片鍵字段的SQL語句會路由到所有節點，將消耗較多資源。分片方案設計04數據遷移方案制定及數據遷移模擬演練；數據要能實現異構數據庫回寫；并發對增量數據記錄做比對數據遷移方案的制定及演練基于PG的分布式數據庫表膨脹優化建議PG未使用UnDO表空間實現MVCC，在更新時對原記錄做刪除標記，然后在相同數據文件再插入新的記錄實現。對于有頻繁更新的表，

18、需要關注“表膨脹問題”。更新頻繁的表如果平均記錄長度較長或包含clob字段，可以考慮應用層面對表做拆分。在Oracle數據庫遷移到TDSQL前，需要識別前20位大表中更新頻繁的表以及更新頻繁程度排在前20位的表，在遷移之前將相應表fillfactor設為80（默認100）在PG監控中，監控閾值評估時需要增加對表膨脹的監控（以天為維度）在做了大批量DML操作后，隨即執行vacuum analyze操作如果系統存在頻繁更新的大表、長查詢、長事務，空間回收問題也需要關注，Vacuum full需要固定較長維護窗口及兩倍表的空間。DML類型類型并發并發tps維護時間窗口維護時間窗口空間回收清理分析空間

19、回收清理分析查詢為主，DML較少不存在“表膨脹”問題DML主要以insert為主，僅存在少量update不存在“表膨脹”問題查詢為主，存在一定量DML操作并發量不大非7*24應用，有足夠維護時間窗口每天有維護窗口進行VACUUM FULL操作DML較多，存在長查詢、長事務并發量較大非7*24應用，有足夠維護時間窗口每天有維護窗口進行VACUUM FULL操作DML較多，存在長查詢、長事務并發量不大7*24場景，存在較為空閑的維護窗口定期在非業務高峰期進行VACUUM FULL，需對數據量及VACUUM FULL時間做評估DML較多，存在長查詢、長事務并發量較大7*24場景，存在業務量較小時間段

20、窗口 需要進行評估，避免VACUUM FULL操作影響業務DML較多且數據量較大，存在長查詢、長事務 并發量較大7*24場景，維護窗口時間較短需對應用做評估，使用需要對應用做一定改造分布式數據庫優化案例一問題：Oracle側19秒，分布式數據庫側超時未跑出結果陷阱：/*+parallel(6)*/分布式數據庫側3分鐘跑出結果select p_contact_cd|b.ext_policy_no|a.case_report_no|a.case_report_no|c.sms_type_cd|e.code|to_char(c.act_start_dttm,yyyy-mm-dd hh24:mi:ss

21、)|from t_cc_l2_pi_vehicle_claim aleft join t_cc_l0_srt b on b.srt_id=a.srt_idleft join t_cc_l2_sms_send c on c.rel_obj_id=b.srt_idleft join t_cc_l2_organ d on d.organ_party_id=b.sub_company_idleft join v_4s_info_list e on e.name=a.fours_namewhere trunc(c.act_start_dttm)=to_date(20220401,yyyy-mm-dd);

22、分布式數據庫優化案例一-優化前執行計劃執行計劃如下：=|ID|OPERATOR|NAME|EST.ROWS|COST|-|0|HASH RIGHT OUTER JOIN|21809|10776678|1|SUBPLAN SCAN|V_4S_INFO_LIST|1574|612748|2|MERGE GROUP BY|1574|612724|3|NESTED-LOOP JOIN|12329|611942|4|TABLE SCAN|TV|1574|569665|5|TABLE SCAN|EV|8|25|6|HASH RIGHT OUTER JOIN|21809|10148423|7|TABLE S

23、CAN|D|21849|8452|8|HASH RIGHT OUTER JOIN|21809|10114605|9|TABLE SCAN|C|758060|293222|10|HASH OUTER JOIN|4361791|7029401|11|TABLE SCAN|A|502323|194301|12|PX COORDINATOR|4471269|3643345|13|EXCHANGE OUT DISTR|:EX10000|4471269|1729508|14|PX PARTITION ITERATOR|4471269|1729508|15|TABLE SCAN|B|4471269|1729

24、508|=分布式數據庫優化案例一優化思路：select p_contact_cd|b.ext_policy_no|a.case_report_no|a.case_report_no|c.sms_type_cd|e.code|to_char(c.act_start_dttm,yyyy-mm-dd hh24:mi:ss)|from t_cc_l2_pi_vehicle_claim aleft join t_cc_l0_srt b on b.srt_id=a.srt_id left join t_cc_l2_sms_send c on c.rel_obj_id=b.srt_idleft join t

25、_cc_l2_organ d on d.organ_party_id=b.sub_company_idleft join v_4s_info_list e on e.name=a.fours_namewhere c.act_start_dttm between to_date(20220331,yyyy-mm-dd)and to_date(20220402,yyyy-mm-dd);分布式數據庫優化案例一-優化后執行計劃優化后：分布式數據庫側3秒跑出結果，為Oracle側用時的15.79%=|ID|OPERATOR|NAME|EST.ROWS|COST|-|0|HASH RIGHT OUTER

26、JOIN|35470|11158762|1|SUBPLAN SCAN|V_4S_INFO_LIST|1574|5228166|2|HASH GROUP BY|1574|5228142|3|HASH JOIN|12329|5221937|4|TABLE SCAN|TV|1574|569665|5|TABLE SCAN|EV|5765961|2230301|6|HASH RIGHT OUTER JOIN|35470|5906226|7|TABLE SCAN|D|21849|8452|8|MERGE JOIN|35470|5863532|9|TABLE SCAN|A|502323|194301|10

27、|SORT|36360|5644101|11|HASH JOIN|36360|5545652|12|TABLE SCAN|C(I_T_CC_L2_SMS_SEND_N2)|4293|16593|13|PX COORDINATOR|4471269|3643345|14|EXCHANGE OUT DISTR|:EX10000|4471269|1729508|15|PX PARTITION ITERATOR|4471269|1729508|16|TABLE SCAN|B|4471269|1729508|分布式數據庫優化案例二問題描述：問題描述：hibernate框架版本為3.3.2.GA版本，調用s

28、pring-data-jpa進行update和query時訪問Oracle系統視圖v$session出錯。困難點：困難點：數據庫監控工具無法定位問題SQL，應用側也未在應用代碼及框架代碼中發現問題SQL位置。解決思路：解決思路：1、在Oracle源庫通過sql跟蹤，抓取問題SQL如下：SELECT MACHINE,TERMINAL,SYS_CONTEXT(USERENV,IP_ADDRESS),SYS_CONTEXT(USERENV,OS_USER)FROMV$SESSION A,(SELECT*FROM V$MYSTAT WHERE ROWNUM=1)B WHERE A.SID=B.SID AND ROWNUM=12、分析應用SQL目的：是用作審計，將登錄當前用戶的用戶名、ip記錄。設法將語義層面報錯轉換為SQL引擎層面拋出異常。3、設法根據問題SQL字段，構造同名偽表、偽視圖，但是不放任何數據。4、調用框架，騙過優化器，觸發SQL引擎層拋出NO_DATA_FOUND異常同時提供模塊名稱，定位是一個觸發器模塊。5、改寫對應觸發器邏輯，提供對應解決方案。