数据库架构和数据库即服务.pptx

《数据库架构和数据库即服务.pptx》由会员分享，可在线阅读，更多相关《数据库架构和数据库即服务.pptx（25页珍藏版）》请在课桌文档上搜索。

1、,U-Cloud MySQL使用,参考架构-oracle建议,2,参考架构-oracle建议,3,SID数据库,ADB数据库,数据库架构建议,4,HA,SID：采用Hamaster-slave架构，数据表采用表分区技术,ADB：多个分片，每个分片采用masterslave方式或是master HA或是mysql cluster方式,master,多slave,应用,数据库即服务,对于SID，采用master-多slave方式，应对大量读操作；由于分片含义不清晰，所以不采用分片，为了应对大表需求，可以采用表分区技术；对于ADB，采用分片架构多数据库存储数据，每个分片可以采用mysql-多slav

2、e结构或采用master HA结构,cluster,OR,SID数据库,ADB数据库,数据库即服务实现建议,5,HA,HA,HA,master,多slave,应用,数据库即服务服务器端（数据库逻辑集群管理 数据库分片管理 数据对象访问接口 监控）,数据库即服务客户端（连接池本地管理 元数据访问 访问接口）,数据访问（jdbc）,元数据访问/数据对象访问（针对SID提供）,数据访问（jdbc）、数据库管理和监控,数据库即服务分成客户端和服务器端，客户端提供本地接口供应用使用，完成连接池管理、元数据库访问、数据访问等功能；服务器端完成数据库分片管理、集群管理、数据的对象转换以及数据库监控功能数据库

3、即服务对应用提供两种接口：原始jdbc接口和对象访问接口，前者适用于SID和ADB，后者仅针对SID提供,财务管理渗透于业务活动信息系统支撑流程化管理,李福申中国联通 集团副总裁2011年4月27日,谢谢！,1.1 U-Cloud环境的高可用挑战,7,当前环境,应用分散-应用分布在各省，本地接入为主资源独立 烟囱式部署的部署方式导致资源仅供单一应用使用数据私有 数据存储在独立的应用数据库中，难以数据共享,目标环境,应用集中化-应用部署在集中大数据中心内，供多区域访问资源弹性化 依据应用资源需求，弹性供给资源数据海量化 实现数据统一建模、管理和共享,U-Cloud需解决的问题,数据中心发生灾难可

4、能导致应用不可用，同时需考虑新建数据中心的应用部署的平滑过渡当资源停服会导致多个应用或服务不可用，故障还可能影响其它功能模块，导致风险分散，影响业务无法正常运转数据规模的急剧增长以及高并发量的数据操作可能导致数据可靠性下降,在应用的集中部署、资源共享和海量数据的新环境下，数据中心灾难、故障影响扩散以及数据处理能力不稳定等风险将会导致业务系统的可用性问题，为此，U-Cloud将采用高可用、故障隔离和平滑迁移等技术确保系统的持续运行,1.2 高可用设计原则和关键要素,8,用户,运维人员,U-Cloud平台管理,平台可用性,应用可用性,设计原则,基础设施可用性,可用性管控,1.3 高可用的基础设施层

5、,SAN共享存储,公共服务群,数据库群,业务应用群,光纤交换机,管理平台,故障发现、事件驱动、快速调度基础设施资源,9,1.4 高可用的平台承载环境,平台双机热备保证高可用,业务服务器池,SOA服务总线群集,心跳检测/资源调度,管理平台,心跳检测/资源调度,故障发现、事件驱动、快速调度平台资源,关键节点冗余设计保证网络高可用,基础资源池化保证整体高可用,10,服务层,1.5 高可用的应用运行环境,使用者,路由/缓存,访问应用1,服务总线群集,访问应用N,1,2,集成调用,3,ESB,服务总线,服务总线,1,高可用实现要点：每一个应用容器都是无状态的，用户访问时的会话信息将保存在共享的数据库缓存

6、中，因此当一个应用环境发生故障后，用户会迅速连接到一个新的可用的应用环境中，最多只可能影响正提交的事务；所有服务都注册到服务总线上，所有的容器都是群集部署，每一个应用环境都是通过服务总线进行动态组装。,运行时的高可用：通过应用容器群集实现用户访问的负载均衡；通过服务总线访问技术服务、业务服务和数据服务；群集方式保证服务总线的可用性；结合服务总线和服务的群集化，实现当一个服务不可用时，能够快速切换到其他空闲服务.,1,2,3,1.6 有效隔离，控制故障影响范围,避免应用模块网状交叉调用。将应用通用逻辑抽离形成服务，减少服务间耦合度，设置服务的访问权限。应用环境根据业务特征划分成不同的资源池，配置

7、不同的隔离级别。,当应用模块、服务故障时，自动将访问路由到冗余节点。在调度资源时，资源充足情况下可随机选择任一空置应用环境，否则，由仲裁机制选择，原则是不影响该应用环境下的其他应用的可用性和性能。,规划阶段,运行阶段,维护阶段,分析故障原因，由应用自身原因导致的故障通过规划建议进行完善。如果由高负载导致，则为应用模块和服务增加相应资源。,将故障影响控制在有限范围,服务,服务,服务,服务,界面,逻辑,接口,服务总线,规范设计,合理调度,持续优化,12,2.1 海量数据带来的挑战和应对,U-Cloud下的企业IT架构，原先分散在各个应用系统独立数据库的数据，转变为全部统一建模，管理，在带来数据共享

8、程度高、全局视角易实现等好处的同时，也要应对海量数据支撑的挑战。,数据存储,数据访问,数据管理,数据规模的急遽扩大，服务器单点能力和存储IO的限制，导致数据不便实现物理上的集中存储，必须考虑数据物理分布的实现。集中存储数据，数据规模的增长，会带来对应存储成本超比例增长,关系数据库中，数据表内存放海量数据，导致每次数据插入都会重建索引，效率低下，同样过大的表进行查询也无法保证效率。业务的增长带来数据访问操作的增长，长期解决访问压力增长需要有效的水平扩展机制企业IT系统集中化和访问互联网化，要求数据可以就近访问,数据量的巨大，也给数据本身的安全性、可靠性的保障带来了困难，数据的隔离、备份、恢复、容

9、灾都不易实现,有效切分，均衡分布，适当冗余，自然容灾,2.2 从应用出发，有效切分，均衡分布,大量数据表间关联度过高，集中存放导致整体性海量数据问题,单张表的海量数据问题,根据查询的关联度，进行数据表的存放重组，均衡单库数据量。,进行数据水平切片，均衡单表数据量,垂直切分,水平切分,问题,数据存储,数据访问,DB,DB,DB,优化模型，降低关联度,确定切分key和算法,通过表级的数据路由，引导访问,化整为零，合并子查询结果,2.3 多种手段并用，保证整体的高效率和高可用,RDB,WDB1,WDB2,WDB3,单个物理数据库采用数据库集群保证单点可靠性,统一写数据库，读数据库水平切分便于实现读数

10、据库的分布扩展,写数据库垂直切分，读数据库数据整合便于实现数据的关联查询和整体视图,WDB,RDB,RDB,RDB,.,写数据库向读数据库异步同步更新数据，数据自然备份,异常时反向同步恢复数据,高可用,高效率,单点可靠,整体可用,数据切分和读写分离结合,新读节点加入，重新分布保证数据分布均匀,2.4 与应用建模结合，形成数据的立体分布,SID,ADB1,ADB2,ODS,ADBN,.,外部系统同步来的静态数据，如来自CRM的产品数据,应用数据模型全局优化，形成高内聚，低耦合的多个应用数据域，最小化应用数据域间的数据交换，同时识别大数据表,本平台内系统的全局数据，指定单一属主，保证管理简单性,R

11、DB,WDB1,WDB3,WDB,RDB1,RDB3,高内聚、低耦合的应用数据域,大数据单表水平切分,WDB,RDB1,RDB3,大数据单表水平切分,RDB,WRDB,逻辑视图,物理视图,数据建模,.,2.5 数据访问的智能化，提高使用效率,数据路由服务,水平切分数据域,垂直切分数据域,SID数据域,WRDB,数据表群1,数据表群N,大数据表1,大数据表N,平台内全局数据,外部系统全局数据,访问优化服务,数据访问接口,访问分解聚合,将访问与全局数据对象的物理分布关联起来,根据物理分布进行任务分解，结果聚合,形成访问路径的记录分析，模型物理分布优化,单表ORM,SQL受限接口,1.显式指明具体访

12、问逻辑对象2.限制水平切分域的数据进入关联查询SQL,1.提供缓存服务，优化单表ORM结果的聚合,数据库即服务,并发子访问,路由优化访问,2.6 U-Cloud应用数据建模分析参考,基本是在线交易型应用，数据分析需求有限，应用间交易以人工处理为主，数据实时一致要求不高，但存在违规异常用户基本是内部员工，总用户数可预期，数据访问的时间分布相对固定总体并发访问量较大，以局部数据的操作和查询为主用户群可分为地市用户、省分用户和集团公司用户，业务操作主要在区域内，跨区域的数据操作比例不大部分应用数据的读操作明显大于写操作，且写操作以插入为主，如电子运维部分应用数据有模型复杂化的可能性，如资源管理大部分

13、应用的有明显的在线数据和历史数据之分，历史数据活性很小，主要是大记录量的查询操作有两个应用要访问GIS系统，因为传输地图数据，要求较高的带宽,应用特征分析,对于历史数据，引入ILM思想，形成多层次的数据备份退休机制，在线备份部分采取水平切分方法,对数据进行固定区域聚群，结合数据存储量和数据访问量，有效的保证各大分区的数据管理压力相当,过程中数据，如工单，无论来自云内，还是云外，都要通过调用服务传递，形成自然冗余，严禁直接访问其他系统数据,全局参考数据，云外整体数据（如产品数据）异步复制到只读SID，违规异常情况做实时数据桥接,区域分片,应用解耦,全局固化,数据分级,单点压力小，主要操作效率高，

14、应用耦合小,2.7 U-Cloud数据物理分布,快 响应时间 慢,小 存储能力 大,内存缓存,热,小,大,冷,存储数据,高 管理难度 低,存储阵列,SSD(固态硬盘）,SAS机械盘,SATA机械盘,机内存储,主数据库,读数据库,读数据库,读数据库,Cache,Cache,Cache,Cache,Cache,Cache,Cache,Cache,Cache,Cache,Cache,Cahce,LRU算法淘汰数据,一致性hash均衡数据,面向应用的数据分片,异步数据同步,应用,数据操作时同时更新cache和主数据库,数据读取时按照cache-读库-主库,归档数据,基于策略数据归档,数据的物理分布需要

15、结合应用数据的特性以及不同管理方式的特性，进行规划，从而保证数据的访问总是在一个最快最小的数据集合内进行，化海量为大量，甚至到小量，充分保证数据的整体可用性。,海量数据,大量数据,小量数据,3.多中心下的数据容灾备份,20,数据中心3,数据中心2,数据中心1,对用户特征数据根据用户进行数据切分，依据一主二备的方式进行数据分布,1.写数据路由到该数据的Master库,2.通过分布式数据库复制自然同步到远端Slave库,全局数据一点维护，全网其他节点自然同步,S,S,M,数据库同步技术+竞选容灾机制,写数据时路由到该份数据的Master库进行,读数据时路由到最近的数据库进行,M,S,M,VS.,1

16、.数据规划,2.数据访问,3.数据容灾,任一数据中心都有全部数据，即可随时接替故障数据中心的Master数据块，亦可反向恢复故障数据中心的数据,M,M,X,全局数据,地域切分数据,7.1 传统的解决方案基于大型集中数据库,21,大型关系型数据库,太多的应用机器,有限的连接池,集中的数据库,方案特点：小型机+高端存储为中心，单点可靠性、性能高大型关系型数据库集群，如Oracle、DB2以Scale up扩展方式为主局限性：数据库资源宝贵，成本高受架构限制，不方便扩展思考：如何降低成本如何建立有更大扩展范围的Scale out扩展方式如何提高可靠性、可用性,集中数据库，快速方便，面向功能,扩大X8

17、6架构应用范围？引入MYSQL等开源数据库？,7.2 X86与小型机技术对比,22,性能,*For Enterprise&Technical ComputingApplication Segments,04,07+,摩尔定律,+30%-50%in 04,+50%-100%in 07+,Intel Xeon-Based Platforms,Itanium Platforms,小型机的安腾的性能提升速度高于x86的至强,高端RISC的可靠性更高,小型机的安腾性能扩展能力高出x86的至强2.5倍,+125%,+50%,可靠性,扩展性,x86的单点性能、可靠性、扩展能力短时间难以突破必须使用分布式冗余

18、架构来达到整体的高扩展、高可用,以同出自Intel的面向小型机的安腾、面向X86的至强相比，小型机因其特有的架构和技术，在性能、可靠性、扩展性都明显优于X86,7.3 分布式架构参考：淘宝网,23,主库：comm，comm2采用小型机_高端存储承担交易主流程采用买家buyerid分库，承担买家的所有查询,读库：tc read db采用PC+SSD架构采用卖家sellerid分库，承担卖家的所有查询，承担top api调用查询，承担detail页面查询,根据不同应用的数据模型和操作特点，进行分库，并开发出TDDL来进行数据的物理模型的操作封装。,关键点：1.应用操作耦合度低，可以很容易找到数据分

19、片key2.为提升PC读写性能，使用了SSD3.关键数据采用oracle，但在考虑取代,商品库：14亿/8亿(下线/在线)QPS/TPS：78K/2.7K(峰值)R/W IOPS：46K/7K(峰值),买家收藏的宝贝：收藏信息表，65亿条记录宝贝信息表，4亿条记录人均收藏千条每天1.2亿访问响应时间100ms,7.4 分布式架构参考：又拍网,24,user_id%n=0,user_id%n=1,user_id%n=2,user_id%n=3,group_id%n=0,group_id%n=1,group_id%n=2,group_id%n=3,album_id%n=0,album_id%n=1

20、,album_id%n=2,album_id%n=3,timen,ntime2n,2ntime3n,3ntime4n,users,groupmessages,photoalbums,events,Single DB,Application Servers,v,v,v,v,v,水平数据分片,垂直数据分片,v,v,垂直分片和水平分片结合，实现数据分布，从而达到在数据存储的可靠性、高扩展性。,关键点：1.数据分片必须和应用设计结合2.低事务性、低数据耦合更容易实现数据的分片,7.5 分布式架构参考：58同城,25,%1主,%2主,%3主,%n主,数据库数目为nInfoid生成算法：local tim

21、es+ip(mac)+pid分库切片算法：infoid对数据库数目取模,Search engine（内容索引）,Mysql（主从+分片）,Memcached（90%以上请求拦截）,%1从,%2从,%3从,%n从,主要以信息的发布和查阅为主，信息（帖子）：10亿访问量：20K QPS，256 TBS,%X主,%X从,%1主,%n+1主,%n主,%2n主,数据库数目从n扩展到2n分片扩展算法：简单二倍增，从库升级为主库特点：简单、无数据迁移、热扩展,分片数据库构造,分片数据库扩展,整体数据架构,关键点：1.面向应用进行数据切片设计2.巧妙的设计扩展算法，避免扩展时数据的挪动3.根据数据特点来选取物理承载,