Oracle TimesTen Scaleout分布式数据库介绍

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