1、基于分布式數(shù)據(jù)庫的OLTP高性能方案分布式數(shù)據(jù)庫在解決什么問題應用開發(fā)簡單，無需分庫分表，支持ACID，傳統(tǒng)MySQL兼容運維方式簡單，一個人管理幾百臺服務器集群，自動化運維操作傳統(tǒng)交易型數(shù)據(jù)庫單庫承載能力有限云計算不斷發(fā)展，平臺化數(shù)據(jù)服務PaaS層替換煙囪式部署架構信息科技的發(fā)展，數(shù)據(jù)量爆炸在線交易業(yè)務的發(fā)展應用程序開發(fā)從煙囪式架構向分布式的轉型應用前端數(shù)據(jù)庫中間件微 服 務數(shù)據(jù)庫微 服 務微 服 務微 服 務數(shù)據(jù)庫微 服 務微 服 務微 服 務數(shù)據(jù)庫微 服 務微 服 務傳統(tǒng)架構向微 服務轉型應用前端數(shù)據(jù)庫如何應對微服務應用框架集中式 關系型 數(shù)據(jù)庫MySQLMySQLPGSQLS3對象 存

2、儲分布式數(shù)據(jù)庫MySQLMySQL實例實例PGSQLS3實例 實例 集中式存儲數(shù)據(jù)緊耦合無法彈性擴張單點故障碎片化存儲數(shù)據(jù)碎片化數(shù)據(jù)無共享運維成本高分布式存儲微服務對應獨 立實例物理分散存儲邏輯集中管理聯(lián)機交易業(yè)務需要什么樣的分布式數(shù)據(jù)庫？ACID的支持：事務、一致性等，處理OLTPSQL完整支持：MySQL/PostgreSQL語法的完整兼容分布式與擴展性：分布式是新一代架構的基礎，擴展性能應對變化的數(shù)據(jù)量Multi-model與多租戶: multi-model多模數(shù)據(jù)庫引擎，同一引擎處理多種 數(shù)據(jù)應用場景，符合微服務和云數(shù)據(jù)庫的架構理念HTAP: 混合事務和分析場景，適應更多數(shù)據(jù)應用需求傳

3、 統(tǒng) 技 術 兼 容 性新 技 術 前 瞻 性Applicationclusterclusterclustercluster核心信貸CRM票據(jù)分庫分表將不同模塊的數(shù)據(jù)表分庫存儲，庫間 不相互關聯(lián)查詢，如果有，必須通過 數(shù)據(jù)冗余或在應用層二次加工來解決， 對應用程序侵入較大。通過分布式中間件進行用戶ID的路由分發(fā)，保 證用戶的一類操作涉及的表在一個節(jié)點上完成， 避免分布式事務。如果有跨節(jié)點的事務，則通 過中間件保證其一致性。原生分布式數(shù)據(jù)庫將表分布到不同機器的庫上，減輕數(shù)據(jù)庫的壓 力物理機的CPU、內(nèi)存、網(wǎng)絡IO負載分攤。支持 分布式事務。Application分布式中間件（路由分發(fā)MQ）用戶組

4、1用戶組2用戶組3用戶組4XXXclusterclusterclustercluster核心核心DB1核心DB2核心DB3核心DBn信貸信貸DB1信貸DB2信貸DB3信貸DBnCRMCRM-DB1CRM-DB2CRM-DB3CRM-DBn票據(jù)Applicationclusterclusterclustercluster核心核心DB1核心DB2核心DB3核心DBn信貸信貸DB1信貸DB2信貸DB3信貸DBnCRMCRM-DB1CRM-DB2CRM-DB3CRM-DBn票據(jù)票據(jù)DB1票據(jù)DB2票據(jù)DB3票據(jù)DBnXXX票據(jù)DB1 X 票據(jù)DB2 X票據(jù)DB3 X 票據(jù)DBn分布式交易型數(shù)據(jù)庫技術發(fā)

5、展體系應用垂直分庫垂直分庫分庫分表原生分布式數(shù)據(jù)庫起點比較早，應用控制能力強，可進行深度定制化對于底層數(shù)據(jù)庫沒有任何特殊要求， 完全在應用程序內(nèi)部進行分庫構建中間SQL解析層，盡可能將標準 SQL拆分成多個子查詢下壓到下層數(shù) 據(jù)庫，在SQL層進行結果拼裝對于底層數(shù)據(jù)庫無特殊要求，在中間件進行SQL切分（支持XA即可）部分兼容傳統(tǒng)SQL，應用程序開發(fā)難 度小于垂直分庫數(shù)據(jù)庫內(nèi)部處理分布式事務與數(shù)據(jù)切 分邏輯，對于應用程序完全透明，不 需感知底層數(shù)據(jù)分布數(shù)據(jù)庫內(nèi)部原生支持分布式事務，性能遠遠高于分庫分表高可用與容災能力由數(shù)據(jù)庫內(nèi)核原生 支持，不需額外輔助工具應用程序邏輯侵入性極強，應用程序 需要進

6、行復雜邏輯才能進行合理數(shù)據(jù) 分布拓撲結構調(diào)整或擴容時非常痛苦，幾 乎不可能完成在線擴容很難支持跨庫事務應用程序邏輯侵入性較強，應用程序 需感知底層數(shù)據(jù)分布結構，才能設計 出優(yōu)化后的查詢邏輯中間件實現(xiàn)分布式事務，跨庫事務使 用XA機制，性能大幅度下降作為單點向新型分布式數(shù)據(jù)庫轉型的 過渡階段，技術延續(xù)性堪憂技術較新，業(yè)界成熟案例相對較少輔助工具相對較少，生態(tài)環(huán)境有待完 善優(yōu) 勢劣勢分布式數(shù)據(jù)庫技術發(fā)展體系對比分布式數(shù)據(jù)庫實現(xiàn)OLTP高性能MySQL主從復制架構MySQL服務（主）MySQL解析器InnoDBAPPMySQL服務（備）MySQL解析器InnoDBMySQL服務（備）MySQL解析器

7、InnoDBAPPAPP讀寫只讀只讀binlogshippingSequoiaDB MySQL 100%兼容，彈性擴張，多活架構MySQL服務（主）MySQL解析器APPMySQL服務（主）MySQL解析器MySQL服務（主）MySQL解析器APPAPP讀寫讀寫讀寫SequoiaDB分布式數(shù)據(jù)庫SequoiaDB 分布式數(shù)據(jù)庫架構計算分布+存儲分布SequoiaDB 分布式數(shù)據(jù)庫架構SequoiaDB數(shù)據(jù)存儲層采用分布式架構，實現(xiàn)了彈性水平擴展以及高性能和高可用，靈活適應不同規(guī)模企業(yè)及不同作業(yè)方式的需要。數(shù)據(jù)切分：系統(tǒng)提供垂直切分和水平切分的多 維分片管理方式，數(shù)據(jù)可以按多種條件切分， 均勻分

8、布到集群中的各個數(shù)據(jù)節(jié)點。高可用：數(shù)據(jù)在系統(tǒng)中至少保留三個副本，高 可用機制，保證了數(shù)據(jù)的持續(xù)安全使用。彈性擴容：SequoiaDB的存儲節(jié)點可按需彈性擴展，系統(tǒng)支持在線擴容硬件成本降低：分布式架構均采用通用x86服務 器+高密度硬盤，相比傳統(tǒng)的“小機+高端存儲” 的配置，大大節(jié)省了用戶投資費用。SequoiaDB MySQL 分布式數(shù)據(jù)庫架構SQL解析區(qū)數(shù)據(jù)存儲區(qū)元數(shù)據(jù)管理區(qū)協(xié)調(diào) 節(jié)點協(xié)調(diào) 節(jié)點協(xié)調(diào) 節(jié)點協(xié)調(diào) 節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)1數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)2數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)3數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)4數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)5數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點分區(qū)6

9、MySQL服務MySQL服務MySQL服務編目節(jié)點 編目節(jié)點 編目節(jié)點主副本1從副本2從副本3每個服務均可 進行讀寫操作Sequoia DB分 布 式 存 儲 引 擎分布式交易設計悲觀鎖讀已提交能力MySQL/PGSQL/SparkSQL保持100%兼容原生 MySQL/PGSQL/SparkSQL 解析與執(zhí)行引擎，不需 擔心語法兼容訪問計劃流水類數(shù)據(jù)按時間與ID 二維切分，避免數(shù)據(jù)搬 遷余額類數(shù)據(jù)按ID散列， 保證均衡無熱點傳統(tǒng)二段提交機制保證數(shù)據(jù)跨節(jié)點一致性二段提表設計交2PC原則兼容性鎖機制支持多活架構讀寫只讀讀寫容災和多活方案，同城方案1、主備機房使用可靠高速光纖直連2、每個分區(qū)主節(jié)點

10、在主中心3、平時使用強一致同步策略保障數(shù)據(jù)不丟4、故障發(fā)生時使用takeover工具進行集群分離 備集群獨立運行5、故障恢復后使用merge工具進行集群合并雙活方案1、應用程序直連本地數(shù)據(jù)中心數(shù)據(jù)庫協(xié)調(diào)節(jié) 點2、應用程序不需要關注底層數(shù)據(jù)存儲主備中心復制和通訊策略兩地三中心1、遠程數(shù)據(jù)中心使用異步機制進行數(shù)據(jù)復制2、數(shù)據(jù)中心之間可進行流量控制保證不會占用過多帶寬異構數(shù)據(jù)源復制策略異步數(shù)據(jù)復制策略1、使用JSON或CSV格式定期將異構數(shù)據(jù)源的原始數(shù)據(jù) 進行導出為文本文件 2、通過FTP等方式將文件傳輸至巨杉數(shù)據(jù)庫的客戶端3、通過sdbimprt工具將文本文件導入巨杉數(shù)據(jù)庫4、滿足異構數(shù)據(jù)源T+1

11、的數(shù)據(jù)復制策略，簡單可靠準實時數(shù)據(jù)復制策略1、異構數(shù)據(jù)源使用相關的工具將日志文件實時解析并寫入管道2、通過Apache Storm對管道信息監(jiān)聽并轉換為標準DML/DDL命令 3、指令分發(fā)至多線程處理服務進行巨杉歷史數(shù)據(jù)庫的 增刪改查4、滿足異構數(shù)據(jù)源T+0的數(shù)據(jù)復制策略，秒級延時5、當前支持Oracle Golden Gate（對應Oracle數(shù)據(jù) 源）、IBM CDC（對應IBM DB2）、IIE（對應IBM Informix）、以及Cannel（對應MySQL）6、對于當前不支持的數(shù)據(jù)庫需要尋找開源的日志解析工具或進行獨立開發(fā)OracleDB2InformixMySQL導 入 工 具歷史

12、庫異 步 數(shù) 據(jù) 復 制 策 略OracleDB2InformixMySQL歷史庫準 實 時 數(shù) 據(jù) 復 制 策 略定期任務實時推送日志解析格式轉化任務處理多租戶與業(yè)務隔離核心交易域信貸業(yè)務域信用卡業(yè)務域協(xié)調(diào)節(jié)點組1協(xié)調(diào)節(jié)點組2數(shù) 據(jù) 存 儲 區(qū)核心業(yè)務信貸業(yè)務信用卡業(yè)務風控系統(tǒng)審計系統(tǒng)客戶畫像系統(tǒng)全文檢索索引支持sd 運行架構SequoiaDBSearch Engine Connectorsearch engineroute agentsearch engine agentshard session managerdata cappeddata cappeddatadataroute age

13、nt index session managerAssync session and Assync session managershard sessionshard sessionshard sessionindex sessionindex sessionindex sessionshard sessionTCPlistenerIndexer readershard session agent sessionagent sessionexternal data source managerCB managerMain loopEDSEDSEDS對象存儲S3+文件系統(tǒng)支持22SequoiaD

14、B提供全面 的圖形化集群監(jiān)控功能集群健康狀態(tài)資源使用狀態(tài)SequoiaDB提供圖形化 操作界面集群部署、擴容集群管理數(shù)據(jù)CURD操作數(shù)據(jù)管理，切分、均 衡等平臺統(tǒng)一管理監(jiān)控方案交易型業(yè)務場景替換 MySQL、PGSQL 等傳統(tǒng)關系型數(shù)據(jù)庫數(shù)據(jù)中臺數(shù)據(jù)服務與高頻只讀類業(yè)務提供比 Hbase 更加 友好的開發(fā)接口以及 更加簡便的運維能力音視頻、圖片、文件等對象存儲類業(yè)務提供比 Ceph 更優(yōu)的 實時容災能力以及更 加豐富的內(nèi)容管理特 性內(nèi)容管理聯(lián)機交易分布式關系型數(shù)據(jù)庫主要適用場景分布式存儲層支持分布式事務能力；支持RU、RC、RR、以及Serializable四種隔離級別；支持讀已提交的MVCC特性；在線數(shù)據(jù)Rebalance；多租戶數(shù)據(jù)物理隔離能力；HTAP交易分析業(yè)務的物理隔離能力；基于Raft協(xié)議的高可用能力；基于Logshipping機制的數(shù)據(jù)