云数据库管理系统及在互联网领域的应用ppt课件

云数据库管理系统及在互联网行业的应用不掌握大数据来源很难得到真正的实际需求建设大型试验环境比较困难不能提供足够的人力资源高校在大数据时代研究面临的挑战高校在大数据时代研究面临的挑战产学研结合产学研结合 大目标统一，相互促进 松散耦合，各层关注自身核心利益 人的联系紧密（同一人在各层间完成身份切换）与大型企业合作技术成果应用演示系统市场层人员支持应用层技术支持研究层独立创业需求提供资金支持独立应用系统环境支持研究论文浙大与网易的合作模式 学生学习研究期间即与企业研究团队紧密合作（非传统横向项目模式），毕业后选择去该企业就职，乃至担任高级职位 创建网易杭州研究院（浙大与网易两块牌子），目前工程研发人员已超过1000人，公共基础技术研究人员超过500人 半数以上的技术高级经理、总监毕业于浙大计算机学院 网易可以提供资金、大数据资源、用户实际需求提供、开发工程师等的帮助 浙大源源不断提供给网易高水平人才，深厚的前期技术积累网易私有云的架构网易私有云的架构NDDB云分布式数据库云分布式数据库RDS单机数据库单机数据库IAAS(云网络、云主机、云硬盘云网络、云主机、云硬盘)NOS对对象存储象存储NCR云云Redis服务服务云转码云转码云容器引擎云容器引擎云队列云队列NCS云搜索云搜索基础服务基础服务数据管理数据管理应用架构应用架构NLB负载均衡服务负载均衡服务云数据库对云平台的需求云数据库对云平台的需求网络隔离：默认隔离不同租户的数据库灵活配置网络连通性,满足特殊需求故障隔离：主备虚拟机不能位于同一个物理机、交换机主备数据不能落到同一个物理机性能保障：CPU、IO、网络性能有保障高可靠：不能容忍数据丢失弹性：存储、计算规格的弹性伸缩平台对数据库的支持平台对数据库的支持NCRRDSNDDB云网络网络隔离连通性控制云硬盘存储能力高可靠、可用弹性扩容存储池NLB负载均衡高可用云主机计算能力弹性扩容可用域高可用数据库网络隔离网络隔离私有网每个租户拥有一个独立的二层网络不同用户私有网络完全隔离机房网不同租户虚拟机之间的互通租户虚拟机到机房中物理机的互通ACL控制连通性互联网链接到互联网（外网）数据库默认运行于私有网络内，不同租户完全隔离。必要时通过机房网络互连资源物理位置失去控制资源物理位置失去控制风险风险硬盘主从硬盘的数据可能落在同一物理机或物理硬盘数据库数据丢失主机不同云主机可能位与同一物理机数据库不可用联网不同云主机可能经由同一网卡或网线联网数据库不可用交换机不用云主机可能接入到同一交换机大量高可用数据库发生不可用故障隔离风险故障隔离风险做冗余而不隔离故障，是伪高可用、伪高可靠可用域a可用域b故障隔离：故障隔离：提供资源位置控制提供资源位置控制 可用域 控制云物理资源位置，确保故障隔离的机制 不同可用域确保物理机、联网和交换机隔离 应用场景：主备隔离 数据库主备从不同可用域分配 Redis主备 云硬盘两副本存储池a存储池b故障隔离：故障隔离：提供资源位置控制（存储池）提供资源位置控制（存储池）存储池 云计算平台提供用于控制云硬盘物理资源位置，确保故障隔离的机制 不同存储池确保物理机隔离 应用场景：主备隔离 数据库主备两块云硬盘从不同存储池分配 云Redis主备两块云硬盘从不同存储池分配高可靠保证：云硬盘高可靠保证：云硬盘需求：要求云硬盘可靠性大于本地RAID，不要求极高可靠性因为数据库本身有主从备份计算性能计算性能容量预留热迁移逻辑隔离虚拟机计算性能随宿主机总体负载变化可能有20%左右的差异宿主机总体负载70%以内虚拟机CPU负载建议不要超过70%云计算平台运维保证宿主机总体负载不超过70%借助KVM提供的热迁移机制，可以在几分钟内将虚拟机无感知的迁移到另一台宿主机监控总体负载超高的宿主机，热迁移其它高负载的云主机网易云主机设计了可用域功能可以物理隔离不同类型业务的云主机对外业务和内部服务隔离、线上业务和测试系统隔离、数据库与业务隔离高可用数据库RDS（新型数据库引擎NTSE +对新型硬件的支持InnoSQL Flash Cache+VSR技术）面向互联网的关系数据库需求面向互联网的关系数据库需求OLTP，短小事务事务性要求灵活读多写少，数据热点明显，往往集中于数据集的10%以内数据量大，IO为系统瓶颈，CPU能力通常过剩产品升级较快，模式变更频繁现有业内解决方案使用MYSQL+InnoDB+Memcached(Redis)主要问题不必要的事务处理机制，造成性能处理的浪费页级缓存效率低空间利用率低下模式变更困难Memcached难以降低更新负载本质上并未针对互联网应用特点为此，设计实现了一个新型数据库存储引擎NTSE，用MYSQL+NTSE来替代MYSQL+InnoDB+Memcached面向互联网的关系数据库需求面向互联网的关系数据库需求关键技术的选择OLTP短小事务事务性要求灵活读多写少有热点数据量大IO瓶颈CPU过剩模式变更频繁两种事务模型并可在线转换内存多版本外存单一版本的MVCC设计记录级缓存数据压缩动态模式，在线索引修改、备份与数据重整事务模型两种事务模型传统ACID事务：保证多实体、多表操作通用事务ACID，支持分布式事务，通用性好单实体ACID事务：保证对单实体的单次操作微型事务的ACID，性能更优（锁定时间短并发度高、无需前向日志、无死锁）事务模型在线切换单实体ACID事务表“升级”为传统ACID事务表：创建内存多版本数据结构，瞬时完成传统ACID事务表“降级”为单实体ACID事务表：purge少量内存多版本数据后销毁内存多版本数据结构，秒级完成MVCC多版本粒度Oracle：页面级多版本，重建页面开销大NTSE/InnoDB/PostgreSQL：记录级多版本记录级多版本，实现简单，效率高版本记录存储Oracle/InnoDB/PostgreSQL：外存存储，存储成本高，旧版本回收效率低，能良好支持超大超长事务；NTSE引擎：内存存储多版本记录内存存储多版本记录，外存单一版本记录。存储成本低，旧版本易回收，便于在线事务/非事务切换，但不能支持超大超长事务（应用不需要）；历史记录存储NTSE/Oracle/InnoDB：独立存储独立存储，方便旧版本回收，减少对应用的影响PostgreSQL：数据文件内存储，旧版本回收特别困难；在牺牲了支持超大超长事务（互联网应用一般无此要求）这一功能后，NTSE在存储、旧版本回收、旧版本操作等方面综合效率优于Oracle/InnoDB/PostgreSQL记录级缓存使用记录级缓存，缓存频繁访问的行记录：内存利用率优于页面级缓存解决了目前使用Memcached存在的数据一致性和缓存效率问题技术挑战内存分配：记录大小不一，使用类Linux SLAB分配器，根据记录大小，分为不同的级别；替换策略：简单LRU内存开销大，使用页内LRU组合页面级最小堆，将内存开销优化到每记录2字节同记录间的LRU替换算法根据访问热度及频率确定页面替换或记录替换缓存一致性：行级缓存修改，记录Redo日志数据压缩压缩算法表级混合行列压缩支持多种列内及列间规则压缩支持后端通用压缩算法支持多压缩级别基于压缩数据的新型索引支持基本索引（MAX/MIN）和扩展索引（HASH）基本索引自动创建，对压缩率和装载速度无影响扩展索引手动创建，存储成本小于4字节/行，创建速度大大优于传统B+树索引所有索引对查询过程透明高可用支持动态模式（dynamic schema）支持，增加字段仅修改表定义，瞬时完成。创建/删除索引，在线进行，不锁表，不影响应用在线数据备份，备份过程不锁表，不锁数据库，不影响应用数据重整（OPTIMIZE），在线进行，不锁表，不影响应用性能对比（blogbench）blogbench，是模拟网易博客应用的基准测试，特点：SQL简单，以简单的查询、更新、插入为主测试数据：1亿条记录性能改善显著，达到InnoDB的4倍以上2015/4/21 TuesdayInnoSQL Flash Cache设计思路很多互联网应用按IOPS/GB计算介于SSD和SATA之间，适合使用SSD+SATA混合存储提升性能降低成本，但目前mysql无法有效利用SSD新型硬件优势设计实现了InnoSQL Flash Cache：SSD用作二级缓存可靠性可用性增强Virtual Synchronized Replication：虚拟同步复制，保证崩溃恢复但不保证Slave读取到实时数据Full Synchronized Replication：全同步复制，保证Slave数据访问一致性缓冲池预热加速，缩短数据库重启预热时间：通过dump/load复制状态crash safe并行复制云计算多租户环境需求Profiler：限定数据库用户的IO访问次数和CPU使用时间2015/4/21 TuesdayInnoSQL Flash CacheLRU替换下的页面才写到Flash Cache，避免Flash和内存重复缓存在实现二级缓存的同时也实现了doublewrite功能对SSD只进行顺序写，提升寿命和性能536201616582459050010001500200025003000InnoSQL Flash Cache：性能对比：性能对比Blogbench17741224Facebook_Flash_Cache_100GFacebook_Flash_Cache_18GInnoSQL_Flash_Cache_18GInnoSQL_Flash_Cache_10GSSD2 Disk RAID 1同等SSD缓存大小(18G)时InnoSQL Flash Cache性能是Facebook Flash Cache的2倍；由于InnoSQL Flash Cache对SSD只产生顺序写，性能甚至优于将所有数据存储于SSD时的原生MySQL。云阅读应用云阅读应用Flash Cache案例案例优化前硬件配置600G SAS*4，有效容量1.2T优化后硬件配置2T SATA*4+160G SSD*2，有效容量4T成本接近，容量大增，IO负载骤降RDS高可用技术高可用技术VSR复制保证数据不丢心跳和主动监测双重探活并行复制保证主从无延迟秒级切换VIP切换（秒级）Slave Apply完日志(并行复制保证零延迟）CAP选择C和AP很少发生发生P时可能需要人工介入处理虚拟同步复制：虚拟同步复制：VSRBinlog得到slave节点ack之后，再提交事务，故障时能保证持久性VSR性能性能VSR提供强同步的同时，几乎没有性能损失原因：增大了组提交比例，减少了磁盘IO负载高可用优化：并行复制高可用优化：并行复制解决MySQL原生复制的痛点从串行执行binlog，主从数据延迟大failover等待数据同步时间久，可用性差社区的方案基于表的并行复制：无法解决热点表的延迟问题基于批量提交的复制：无法充分利用磁盘带宽基于行的并行复制：并行检测实现难度巨大InnoSQL并行复制原理：一个组提交中的事务都可以并行执行效果：网易云监控数据库延迟从9个小时降低到无延迟、网易电商数据库延迟从5个小时降低到无延迟，可用性大幅提高failover速数据丢失性能可维护性度Replication大量数据丢失好简单快Semi-syncReplication小部分数据丢失差简单快MHA数据不丢失，前提是Master服务器依然存活（可能性极低）一般简单快SAN数据不丢失，前提是共享存储本身没有发生故障（可能性较高）一般数据库简单SAN设备复杂慢Galera数据不丢失，前提至少有1台服务器存活（可能性较高）差复杂快网易RDS/NTSE数据不丢失，前提至少有1台服务器存活（可能性较高）好简单极快高可用方案对比高可用方案对比应用总结关注性能，事务需求不高的应用，可使用NTES提供的非事务功能对事务要求较高的应用，可使用NTES提供的事务功能数据热点集中的应用，可从NTES提供的行级缓存中获取优势数据量大的应用，可使用数据压缩功能提供很好的SSD支持所有应用都能获得高可用支持云分布式数据库NDDB产品目标产品目标大容量高并发，100TB兼容标准MySQL协议SQL兼容度高，支持跨表JOIN，子查询等高可用，高可靠，强一致（继承自RDS）支持从RDS升级到NDDB在线伸缩对开发支持效率高完善的管理特性：备份、统计、监控等现有方案评估现有方案评估Oracle RAC成本高昂：商业产品；硬件需求(商业存储系统)可伸缩性风险：现有部署一般不超过20节点中间件产品市场上缺乏成熟的解决方案NoSQL产品可用性、可靠性保障不足复杂查询、事务等功能支持不足缺乏类SQL标准接口，应用开发效率低NDDB系统架构数据数据Sharding核心一核心一：表级水平切分、两级映射方案保证一级Hash固定；方便后续的扩容与收缩核心二核心二：关联表使用相同分区策略使用相同分区策略的关联表，可在分区内完成EQUAL-JOIN(Local Join)查询处理流程查询处理流程在线扩容过程（在线扩容过程（1扩扩2为例）为例）全量复制：新建2个RDS作为目标RDS源RDS节点全量复制数据到目标RDS记录全量复制时日志位置删除脏数据：2个目标RDS各自删除一半无用数据，相当于1拆2增量复制：从日志的全量复制点开始读取日志回放增量数据到2个目标RDS等待回访快要完成时，进行悬停切库悬停切库：锁定所有查询服务器等待尾部少量日志回访完成查询服务器（QS）切换到目标RDS解锁查询服务器，扩容完成全量复制（只读RDS）Hamal 增量复制+增量数据校验删除脏数据 QS悬停切库分布式事务处理分布式事务处理核心核心：两阶段提交(2-Phase-Commit)支持SQL Proxy(Query Server)，作为分布式事务的发起者与协调者解析用户的SQL，若SQL跨多节点，开始一个分布式事务用户提交事务，QS作为协调者，发起Prepare请求，记录Prepare日志待所有参与者均Prepare成功，发起Commit请求，提交事务，记录Commit日志异常情况一：Query Server崩溃并重启根据Query Server中记录的Prepare日志，处理悬挂事务异常情况二：Query Server永久崩溃将分布式事务日志存储于高可靠的云硬盘系统保证XA事务ACIDNCR云云Redis服务服务NCR需求需求兼容Redis协议弹性伸缩高可用分钟级部署、完善的统计和运维工具NCR架构架构NLB负载均衡 4层负载均衡 代理节点 Redis进程 云硬盘云主机在线扩容在线扩容NLB负载均衡NLB负载均衡复制 Pre-sharding:预先创建所有redis进程 通过redis成熟的一对一复制机制迁移部分redis进程实现伸缩 理解业务协议的代理节点延时请求消除节点路由切换影响 有状态系统实现自适应无缝伸缩的参考架构NCR特点特点利用已有NLB、云主机、云硬盘组件实现代价小SLA有保障Presharding+redis主从复制实现扩容优点：实现代价小，且满足应用需求缺点：运维需要有一定专业性,只适用私有云环境缺点：需要实现考虑集群容量，将来考虑采用REDIS CLUSTER云数据库应用云数据库应用覆盖网易互联网主要应用小结小结云平台和数据库一体化设计，平台为数据库提供隔离性、性能保障、可靠性、资源弹性，降低云数据库实现代价。云数据库RDS，提供即开即用、稳定可靠、弹性伸缩的高可用数据库服务，RDS也是分布式数据库NDDB的基石。分布式云数据库NDDB,是兼容MySQL协议，具有横向扩容能力的分布式关系数据库平台，提供大型应用无限伸缩能力。云Redis服务NCR,是高可用的托管式分布式Redis服务，满足复杂内存数据结构存储和缓冲需求。网易对浙大研究的帮助问题来源（实际需求，用户奇思妙想）大数据资源设计师+工程师资金myDJ:基于能力的音乐推荐基于能力的音乐推荐（SIGIR/TKDE/ACMMM/TMM）基于能力的音乐推荐研究动机为了给用户推荐适合其自身演唱的歌曲研究问题对唱歌社交社区中海量用户根据歌曲难度进行粗粒度的演唱歌曲推荐对有极高歌曲选择需求的用户根据其发声能力进行细粒度的演唱歌曲推荐研究路线基于个体发声能力的音乐推荐研究内容对个体发声能力进行建模对每首歌曲进行建模从而能用于推荐在发声能力以及歌曲之间建立查询推荐机制基于个体发声能力的音乐推荐发声能力可视化男低音查询结果展示男中音男高音唱歌社交社区中的音乐推荐系统技术路线创新思想通过对真实用户数据进行挖掘发现歌曲难度序提出歌曲难度图模型，对歌曲难度序进行概率建模提出一种迭代概率推导的能力音乐推荐算法进行歌曲推荐唱歌社交社区中的音乐推荐系统实验结果推荐准确率与传统推荐算法相比提升180%以上，克服推荐系统冷启动问题推荐结果在实际用户使用中令人满意算法准确率比较myDJ原型系统可以录制用户发声能力，实时的进行发声能力可视化以及演唱歌曲推荐LogBase:基于日志结构的弹性基于日志结构的弹性数据库数据库（VLDB/ICDE/TKDE）背景介绍传统的数据库保留两份实际上等同的数据：数据库表、日志数据库表用来快速回答查询（查询效率高）日志用来进行恢复处理（更新效率高）日志和数据需要同步（代价高）然而，有一类大数据应用传统数据库不能很好的支持高速更新而查询分布不均匀：高速电商交易（每秒10万笔）、互联网有害信息甄别（数据出入速度极快、分析查询为主）Log数据库表A=100B=200背景介绍基于日志的恢复当数据库发生故障时，可以通过日志来进行恢复。利用日志里面记录的事务开始、结束和期间完成的修改操作，我们可以将数据库恢复到其发生故障前的状态那么也就是说，可以通过搜索日志来得到数据库中数据那么可以通过日志来回答用户的查询吗？理论上完全可行实际系统中速度太慢基于日志结构的数据库提出基于单一日志结构的数据库颠覆了传统数据库（日志数据库表）存储结构，仅仅维护一个日志文件大大降低了存储代价（不再需要数据表）大大提升了更新速度，单节点每秒10万条，多节点弹性增长新的硬件（如PCM和SSD)进一步提高了日志文件的读写性能主要的挑战：如何在得到以上优点的同时，保证高效的查询处理能力？日志结构数据库架构LogKeyLogKeyLogKeyDataDataData日志结构数据库架构（续）数据表（日志格式）被平均分割到不同的服务器节点每个服务器节点对每一个表都维护一个指针，指向日志文件的相关位置：每个表的日志先存储在内存缓存中，当达到一定大小(4M)，将被使用append的方式写入日志文件，而服务器则记录该块在日志文件的起始位置每一条日志记录使用特殊的键值进行区别，所有的表数据都存储在一个统一的日志文件唯一的插入操作：append日志文件表A表B表CLogBase的查询机制在LogBase中，为了支持高性能的查询，使用了创新的内存硬盘混合索引技术分布式日志查询技术内存硬盘混合索引技术内存保留类似B树的索引结构每个叶子节点cache line大小硬盘维护基于日志文件结构的树结构内存索引满了和硬盘树进行合并查询时，根据查询热点模式，大部分查询可以在内存索引得到结果，少数需要搜索硬盘索引 a,t2,pa,t18,pd,t20,pk,t8,p k,t32,p z,t46,p(Log)LogBase的查询机制（续）分布式日志查询技术将查询按照键值分割到不同的服务器节点每个节点并行查找结果异步的返回，降低同步代价相比类似的Hbase模型，因为LogBase仅仅维护一份日志文件，大大降低了读写的I/O代价WriteOpRead Op内存索引索引同步写流程读流程日志文件日志文件日志文件MemDFS日志压缩算法日志文件大小会随着时间增长，而很多日志记录的数据实际已经被后面日志的新数据所替代，成为过时数据定期调用特定的日志压缩算法来合并日志，压缩比达到1/10日志首先根据键值和时间进行排序同一键值、不同时间的日志进行合并最终产生新的按照键值排序的日志文件原始日志原始日志排序日志排序日志1.删除过期数据Compact2.基于合并日志排序日志排序日志