分布式数据库技术架构的演变与发展方向试卷.pptxVIP

分布式数据库技术架构 CSDN数据库核心技术与应用实战峰会 目 录 / Contents Part one 分布式数据库技术架构分类 Part two Part three Part four 企业为何需要分布式数据库 企业典型业务场景 分布式数据库的技术架构演变 Part five 分布式数据库技术架构的未来方向 Part six 数据库行业十三五预测 分布式数据库 技术架构分类 分布式数据库技术架构分类 Oralce RAC MySQL Cluster Vertica GreenPlum HBase MongoDB 分布式数据库技术架构分类 MySQL Proxy TDDL Atlas D-RDS OceanBase HotDB Fabric CDB Cobar 2005年 --- 2015年 企业为何需要 分布式数据库 企业为何需要分布式数据库 易扩展 海量用户 海量数据 高可靠 高性能 高并发 业务要求 企业为何需要分布式数据库 私有云 数据创造价值 分布式 开源产品 硬件平民化 自主研发 自动化 企业信息化发展的趋势 企业为何需要分布式数据库 企业典型业务场景 企业典型业务场景 目标 说明 指标分解 海量数据 系统运行一年之后数据总量：120T 每年数据增量：小于等于20%，也即第一年数据最大增量：24T 单应用数据20T以上 单表有20亿条记录(大省的在1亿+条记录) 系统正常运行后，不做任何数据存储调整或二次拆分的情况下，支撑业务数据持续增长年限：3年 高可用 数据库可用性达到99.99%，即每年仅允许有累计53分钟的不可用时间； 定期维护（包括部署）除外 要求可在线数据备份，时间少于11小时（22：00～08：00） 失败切换时间小于10s 故障恢复时间小于30分钟 数据复制延迟时间（本地：1s，异地：1分钟） 本地同步时，数据丢失量小于1笔交易 高性能 要求支撑5+个应用的全国访问 支持的并发量大于2万 数据库交易量大于10万/s 响应时间1s 最大响应时间10s QPS大于30万 可扩展 当数据量或系统负载超过我们3年规划之后，大部分业务系统可通过增加物理服务器节点的方式，达到支持业务的持续发展或性能线性提高 要求性能可扩展 要求容量可扩展 数据迁移时可通过规划和技术手段，能做到不影响数据库提供数据服务的质量 增加物理服务器节点，对应用模块透明，不需要修改任何代码 要求可在线扩展，扩展时间/对业务的影响时间（如性能下降时间）小于10小时 扩展的线性度应该大于70% 多中心 要求两地三中心数据容灾及数据服务 要求在线，且数据中心的每个节点都可以提供服务 数据同步延迟最长时间 小于1分钟 数据服务切换最大时间 小于3分钟 业务服务切换最大时间 小于10分钟 数据丢失量 小于100笔交易 不同机房的业务数据库组之间，能做到数据异步互相复制；同一份数据，同一时刻只有一个数据中心应用模块能对其进行修改，但是全网的数据中心都可同时对其进行只读操作 电信行业某集团总部去IOE项目 目标 说明 指标分解 高并发 2013年单量：平时 N00万， 高峰 NE00万 2013年操作平台TPS须大于27000 2014年单量：平时 M000万， 高峰 M000万 　2014年操作平台TPS须大于40000 2015年单量：平时 DF00万， 高峰 D000万 2015年操作平台TPS须大于60000 网点数量：12000+ PDA终端：10W+ 子系统PC终端：4个+/网点  接入平台集群应用服务数量：YX0个 + 数据库连接数 2100/实例（操作平台占130个）  2014年峰值单量M000W，全国12000个网点。 操作平台N00W单量，优化前： 数据写入：INSERT KL亿次/天 数据删除：DELETE KX亿次/天 操作平台N00W单量，优化后： 数据写入：INSERT X亿次/天 数据删除：DELETE Y亿次/天 高可用 数据库可用性达到99.99% 数据服务或应用服务的任意一个节点宕机， 不影响业务系统服务 应用展开服务达到99.99% 数据库中间件达到99.99% 应用对列服务达到99.99% 故障切换时间小于10秒 业务系统整体每年仅允许有累计53分钟的 不可用时间，定期维护（包括部署）除外 故障恢复时间小于5分钟 数据库的数据复制延迟时间小于1秒 伸缩性 应用服务任意增减 支持对操作平台中的展开应用服务节点和数据库实例进行动态扩展；