1、技術創新，變革未來Oracle TimesTen Scaleout下代向OLTP的分布式內存數據庫詳解AgendaTimesTen 簡介為什么要做分布式系統架構設計臨的挑戰性能如何結12345持久性和可恢復性 數據庫和事務志件持久化到本地磁盤或速存儲設備關系型數據庫純粹的內存計算遵循 ACID標準 SQL數據庫全量加載到內存極速性能微秒級響應超吞吐量可性可和容災持Active-Standby 和多主復制基于并復制的速復制Oracle TimesTen In-Memory DatabaseTimesTen Application-Tier Database CacheFor Oracle Dat

2、abaseTelco Services Financial ServicesReal-Time Analytics Dashboard, Scorecard Data MarteCommerce, Personalization利TimesTen 緩存Oracle Database熱數據提升響應時間Read-write 緩存事務在TimesTen中執并持久化Read-only 緩存事務在 Oracle Database 執應層具備可和容災能ApplicationApplicationApplication使最泛的關系型內存數據庫全球上千家型企業客戶的選擇Oracle TimesTen 關系型內

3、存數據庫版本演進20+ 年極致性能體驗1998年全球款商 關系型內存數據 庫產品！Oracle ClusterwareIntegrationODP .NET SupporttypesPL/SQL and OCI Support Parallel ReplicationIn-Memory AnalyticsColumnar CompressionCache Grid for Scale Out Index AdvisorOracle R SupportBLOB, CLOB, NCLOB data In-Memory Star JoinOracle Golden Gate IntegrationP

4、arallel data import from Oracle DatabaseParallel database restartHighly concurrent range indexesParallel Replication with commit order optimizationOracle RAC integrationNational Language SupportOracle Data Types supportSQL Developer IntegrationEnterprise Manager integrationTimesTen 6TimesTen 7Pre-Or

5、acle acquisitionTimesTen 11g 11.2.1TimesTen 11g 11.2.2TimesTen 11.2.2.x Enhancements1996|2005TimesTen 18.1.12018年全新的持SQL 的、分布式、關系型內存數據庫新版問 世！2006|20082009|20112012|20132014|20172018AgendaTimesTen 簡介為什么要做分布式系統架構設計臨的挑戰性能如何結12345過去20年來硬件發展趨勢1996 的服務器:Sun E4504 cpus4 hardware threads480 MHz4 GB RAM728 G

6、B disk100 Mbit/sec Ethernet2016 的服務器:Oracle SPARC T7-44 processors 256 倍以上!128 cores (1024 hw threads)9 倍以上!1024 倍以上!13 倍以上!4.13 GHz4 TB RAM9.6 TB disk10 Gbit/sec Ethernet100 倍以上!開發數據庫在單機的縱向擴展能是充分利多核CPU的最有效式相同實例內存訪問比跨實例訪問數據更效要求: 細粒度的并發控制機制、效的進程訪問、效的內存使、并 IO算法, 某些數據庫由于縱向擴展的限制，要求必須在相同主機內有多實例該要求需要數據消息共

7、享：效率不理想情況: 臺主機一個實例Scale-Up單機內的縱向擴展能Single DB Instance per server: EfficientMultiple DB Instances per server: InefficientMemory AccessCross instance messagingSingle InstanceInstance #1Instance #2TimesTen專注于 Scale-Up 架構二年過去每個時代的主機都強調持更多的CPU核數、更的內存容量 專注于越來越強的多核擴展能：優化并發訪問下的并發索引并發志成 (多軌 redo)點對點的并發、并復制我們

8、專注于 scale-up 的性能表現，像這樣 TimesTen In-Memory Database讀擴展 每秒三千兩百萬次查詢TPTBM 100% Read E7-8890 v3 2.50GHz4 sockets, 18 cores/socket,2 threads/coreTimesTen .0 (100M rows, 17GB)32 Million Queries per SecondTimesTen In-Memory DatabaseTPTBM 100% MixedWorkload (80-10-5-5) E7-8890 v3 2.50GHz1 socket, 18

9、cores/socket, 2 threads/coreTimesTen .0 (100M rows, 17GB)80-10-5-5 Workload = 80% select, 10% updates, 5% inserts, 5% deletes每個處理器每秒四百六萬筆事務4.6 Million Transactions Per SecondMixed Workload Throughput Per Processor來我們客戶的實際模型TimesTen 擁有常優秀的性能，但是數據庫容量受限于單機物理內存容量數據增速度于物理內存容量的增吞吐量受限于單機盡管物理服務器變得越來

10、越強勁客戶開始投向九年代規模的虛擬機器很難在兩核的虛擬機中縱向擴展 當我們忙于縱向擴展時，客戶已經在探索橫向擴展客戶開始構建基于獨數據庫的建集群，例如TimesTenCustomers實時計費的超規模集群Ericsson Sweden全球 50億戶，20是通過愛信收費實時評級（價格計算，促銷和忠 誠度）實時計費（出控制，多賬戶和 單位，歷史使情況）電信級 99.999的可性，快速 和動故障轉移挑戰TimesTen 內存數據庫TimesTen 復制Shared nothing 集群標準 SQL 接口低維護多平臺持低系統影響解決案TimesTen 價值可預測的響應時間極速 SQL 性能99.999

11、% 的可使時間(最停機時間每年5分鐘)ApplicationsA1A2AnA1A2AnTimesTenReplicatio nA1A2AnA1A2AnA1A2AnA1A2AnTimesTenReplicatio nShard # 1Shard # 2TimesTenReplicatio nShard # nData partitioned across shards based on MSISDNEach shard handles several million subscribers depending on configuration.Each TimesTen database is

12、10 50 GB in size depending on configuration.Request DirectorMobile NetworkComplex routerDirects requests to applications on specific shard based on MSISDNCombines and recomputes responses for shared data accessEricsson 計費案應側的橫向擴展挑戰:分后的查詢、事務必須通過應處理負載均衡問題需要良好的預判能Load balancerMobile NetworkSimple Load

13、balancer Distributes requests across grid elements. Could potentially implement data locality based optimizations.Ericsson 計費案簡化： 數據庫側的橫向擴展、分布式能好處:數據分布透明簡化應對分布式下數據的處理需求A1AnA1AnA1AnAnA1A1AnA1AnA1AnA1 An如何能成功的將Scale-Up 轉換為 Scale-Out ?從需求：第1條：遵循完整的ACID的權利不容妥協第2條：保留持完整SQL的權利不容妥協第3條：橫向擴展架構需要既能擴展容量也能擴展吞吐量

14、 第4條：橫向擴展應提系統可性不是破壞它第5條：橫向擴展架構不應讓管理難度加第6條：產品的所有功能必須適配到橫向擴展架構Tada! TimesTen Scaleout In-Memory DatabaseSingle Image In-Memory Database基于TimesTen 內核的全新部署模式向超吞吐量需求的 OLTP 應IOT、交易、控、移動、計費、訂單等前沿設計:全內存、原持 SQL以及 分布式下ACID 事務容錯擴展多副本可多活副本、持讀/寫操作持向報表和批處理的復雜 SQL 和并SQL鍵安裝、集中管理和維護邏輯統的 分布式數據庫TimesTen分布式模式邏輯統的分布式數據庫

15、不是個分數據庫添加和刪除數據庫 elements數據動重新分布負載動使新添加的計算資源內置可 - 多活副本副本之間動同步-度兼容 Oracle 數據庫 （集）-數據類型、API 接口、SQL & PLSQL邏輯統、橫向擴展、共享、應透明、可AgendaTimesTen 簡介為什么要做分布式系統架構設計臨的挑戰性能如何結12345設計針對OLTP優化的橫向擴展架構所臨的挑戰數據分布: 如何在集群內分布數據可: 如何避免單點故障分布式下的 SQL 執: 完整的、透明的 SQL分布式事務處理:集群內在任意節點可以修改任意多語句事務的原性集中化管理:管理個有100個節點的集群應該與管理2個節點的集群樣

16、簡單采 Scale-Out 的原因: 在個節點法承載超表應對超表的標:盡可能減少熱點塊盡可能減少重新分布開銷跨節點間的均勻致的分布算法應該允許在線重新配置 (添加、刪除節點)可以哈希分布來統訪問推薦主鍵的集作為哈希鍵范圍或定義分布較難實現在線變更，臨熱點塊（熱點 區間）問題從客戶端即可計算哈希值UsersSensor ReadingsIoT Devices. . .超表的分布在關聯數據間優化Join 查詢表關聯查詢在OLTP系統很常查詢某customer的所有 order 和 shipmentNoSQL 系統要求結構化看起來很糟糕規避掉 join 查詢，但是會引發許多其他問題空間問題、DML

17、開銷過、異常處理 表的分布式標：盡可能與表關聯分布表數據關聯分布要能做到多級關聯Customer, Order, Line-ItemCustomerOrderLineitemService RequestShipment優化訪問熱讀為主數據熱讀為主數據在OLTP系統中也很常的檢索表: Catalogs, price lists, stock symbols的維度表: Colors, Categories, 等標: 將熱數據本地化Duplicate是解決這種對象的最好法所有查詢檢索都在本地執更新必須同時更改多個副本，且通常這種對象的低 頻更新不會帶來問題PricesSymbolsColors哈希

18、分布 基于致性哈希算法分布表基于Cust_ID 的哈希值，將CUSTOMER表中各分布到所有 elements 當中協同分布 表與表相關聯的共存于相 同element，優化本地事務將 ORDERS 表中與CUSTOMER相關聯的存放 于相同element當中DUPLICATE 查詢為主的表在每個element存放完整數據，優化本地事務將 PRODUCT 表在所有 elements 當中都存份全量數據數據分布法Element 1Element NServersCUSTOMERORDERSPRODUCTSCUSTOMERORDERSPRODUCTSDistribute DuplicateColoc

19、ateColocate分布式系統的其他概念橫向擴展架構必須提供數據位置透明性可以從任意位置訪問和更改任何數據 這是多數應需要的位置感知能提升 key-value 應的訪問效率“Smart clients” 可以設計路由請求，但邏輯常復雜客戶端太復雜是個問題：需要服務器端模型、如何升級TimesTen Scaleout 提供個數據獨的路由APIAPI 映射個分布鍵，數據存放在個或多個element中基于最佳猜測，如果位置有誤，請求仍舊在內部轉發客戶端保持簡單化Location-Sensitve ApplicationRouting APILookup Customer #51Send tobes

20、t Element#51分布式系統的其他概念對向OLTP的橫向擴展的難點: 在線重分布重分布必須要快速或者作為后臺活動必須有冪等性不能阻塞查詢和DML，DDL 有可能實現法概述：執計劃不能與位置信息硬編碼重新分布時避免查詢重編譯邏輯訪問層與物理訪問層分隔開物理訪問時需要映射新、舊位置#51#51#49#49DMLExecutionApplicationUpdate Customers 49, 51可性措施異常法避免。因此，需要保護數據庫軟件本身問題概率 主機異常、絡異常、存儲設備異常比較常數據需要多個副本理想的多活副本可以獲得最好性能超時或斷連時持客戶端故障轉移通過仲裁發現絡分區數據庫中的 E

21、lements 邏輯上被分到replica sets 進分組管理每個副本集（ replica set ）包含K個elements同副本集中的Elements 包含相同 數據所有的 elements 都是 “active” 的可以在任意element上執 DML分布式提交保持強同步并不是復制SQL 會在兩個（多個）element 中同 時執動創建和管理副本集TimesTen Scaleout 中的可技術: Replica SetsReplica Set 2Element 1Element 2Replica Set 1Cust 1,4Orders for cust 1,15Cust 1,4Orde

22、rs for cust 1,15Cust 2,3Orders for cust 2,3Cust 2,3Orders for cust 2,3只要副本集中任意element可，數據在該副本集中即可恢復中的 element 動與其副本同步不同副本集的異常不會導致數據丟失副本集和容錯機制Replica Set 2Element 1Element 2Replica Set 1Cust 1,4Orders for cust 1,15Cust 1,4Orders for cust 1,15Cust 2,3Orders for cust 2,3Cust 2,3Orders for cust 2,3Datab

23、ase still available連接發失敗或超時后，應連接 被動切換到其他element在途事務被明確提交或回滾副本集和應故障轉移Element 1Element 2Replica Set 1Cust 1,4Orders for cust 1,15Cust 1,4Orders for cust 1,15Database still availableApplicationSQL 執挑戰：必須持透明執所有類型的SQL要求：降低OLTP操作的絡交互次數最化調度并批處理或分析查詢操作輔助索引分布式關聯查詢全局序列參照完整性和約束SQL執共享架構需要分布式SQL執計劃邏輯計劃必須對位置中（考慮到

24、重分布）次優計劃會降低性能但不會造成錯誤結果簡單的OLTP訪問需要優化計劃減少絡交互不再有純粹的OLTP應！OLTP常伴隨有分析需求：允許較時間運的分析查詢并運分析應該在當前陳舊數據上運算Parallel Server ProcessesParallel Server ProcessesElement 1Element 2Analytic QueryCoordinatorOLTPQuery1 round trip data Access輔助索引分布鍵 / 基于主鍵 (e.g. custid) 訪問最效OLTP中補充分布鍵訪問同樣重要 (e.g. by name)本地索引每個節點的索引對應本地數

25、據 (hash / range)維護更快 (本地維護)全局輔助索引：個單獨的分布式表映射索引鍵到分布鍵快速查找：轉到存儲索引鍵的節點，查找表由于需要分布式事務，維護較慢兩種類型的輔助索引都需要全局需要獨特約束Local Idx:BalanceGlobal idxNameCustomer Table RowsLocal Idx:BalanceCustomer Table RowsGlobal idxNameElement 1Element 2分布式關聯查詢PK/FK 關聯通過Distribute by Reference 分布 后，實現本地關聯OLTP 同樣需要關聯分布鍵字段E.g. 基于訂單找

26、到告及客戶信息分布式關聯查詢需要基于成本決策合理選擇關聯順序合理選擇索引（全局或本地）合理選擇關聯式Customer OrdersAdsJoin on Orders Category橫向擴展下的事務：致性強致性對企業級OLTP是必要的致性需要兩階段提交阻塞協議：調度者異常時，事務保持在in-doubt 狀態仲裁協議：阻塞但是對查詢開銷較(r + w) N 實現致性參與者和解也常復雜需要提交協議避免阻塞避免影響常規操作性能快速處理掉慢或響應參與者事務：持久性對于低延時系統，磁盤同步寫是噩夢絕多數應能接受數據存在多套內存中 即便不刷出到磁盤TimesTen Scaleout 同樣承諾內存優先，磁盤

27、次之同副本集中的 Elements 不應該共重要資源（同主機、同電 源供給）Epoch 事務確保集群范圍在可配置的間隔內持久化集群異常（罕）時，任何事務丟失僅限于最近次epoch 后提交的事務集中管理 TimesTen ScaleoutttGridAdmin 全新中控 管理命令SQL Developer 可以通過 調 ttGridAdmin 實現 圖形化管理所有集群管理通過管理實例完 成不再需要動登錄其他主機或拷貝件允許只有個管理實例產系統不推薦standby 管理實例可以在異常切 換后成為 active 管理實例管理實例Rack 1Switchdata4mgmt3data2data3mgmt1Rack 2Switchdata8repo1data6data7mgmt2Active MgmtStandby Mgmt“Create payroll database”AgendaTimesTen 簡介為什么要做分布式系統架構設計臨的挑戰性能如何結12345YCSB version 0.15.01KB record(100-byte x 10 Fields)100M records / Repli