搜索
云数据库管理系统及在互联网行业的应用浙江大学计算机科学与技术学院陈刚2015年4月16日不掌握大数据来源很难得到真正的实际需求建设大型试验环境比较困难不能提供足够的人力资源高校在大数据时代研究面临的挑战产学研结合大目标统一，相互促进松散耦合，各层关注自身核心利益人的联系紧密（同一人在各层间完成身份切换）演示系统研究论文与大型企业合作独立创业研究层市场层技术支持人员支持需求提供技术成果应用独立应用系统应用层资金支持环境支持浙大与网易的合作模式学生学习研究期间即与企业研究团队紧密合作（非传统横向项目模式），毕业后选择去该企业就职，乃至担任高级职位创建网易杭州研究院（浙大与网易两块牌子），目前工程研发人员已超过1000人，公共基础技术研究人员超过500人半数以上的技术高级经理、总监毕业于浙大计算机学院网易可以提供资金、大数据资源、用户实际需求提供、开发工程师等的帮助浙大源源不断提供给网易高水平人才，深厚的前期技术积累网易私有云的架构NDDB云分布式数据库RDS单机数据库IAAS(云网络、云主机、云硬盘)NOS对象存储NCR云Redis服务云转码云容器引擎云队列NCS云搜索基础服务数据管理应用架构NLB负载均衡服务云数据库对云平台的需求网络隔离：默认隔离不同租户的数据库灵活配置网络连通性,满足特殊需求故障隔离：主备虚拟机不能位于同一个物理机、交换机主备数据不能落到同一个物理机性能保障：CPU、IO、网络性能有保障高可靠：不能容忍数据丢失弹性：存储、计算规格的弹性伸缩平台对数据库的支持云网络云硬盘云主机NLBNCRRDSNDDB网络隔离连通性控制存储能力高可靠、可用弹性扩容存储池负载均衡高可用计算能力弹性扩容可用域高可用数据库网络隔离私有网每个租户拥有一个独立的二层网络不同用户私有网络完全隔离机房网不同租户虚拟机之间的互通租户虚拟机到机房中物理机的互通ACL控制连通性互联网链接到互联网（外网）数据库默认运行于私有网络内，不同租户完全隔离。必要时通过机房网络互连故障隔离风险资源物理位置失去控制风险硬盘主从硬盘的数据可能落在同一物理机或物理硬盘数据库数据丢失主机不同云主机可能位与同一物理机数据库不可用联网不同云主机可能经由同一网卡或网线联网数据库不可用交换机不用云主机可能接入到同一交换机大量高可用数据库发生不可用做冗余而不隔离故障，是伪高可用、伪高可靠故障隔离：提供资源位置控制可用域a可用域b可用域控制云物理资源位置，确保故障隔离的机制不同可用域确保物理机、联网和交换机隔离应用场景：主备隔离数据库主备从不同可用域分配Redis主备云硬盘两副本故障隔离：提供资源位置控制（存储池）存储池a存储池b存储池云计算平台提供用于控制云硬盘物理资源位置，确保故障隔离的机制不同存储池确保物理机隔离应用场景：主备隔离数据库主备两块云硬盘从不同存储池分配云Redis主备两块云硬盘从不同存储池分配高可靠保证：云硬盘需求：要求云硬盘可靠性大于本地RAID，不要求极高可靠性因为数据库本身有主从备份计算性能容量预留热迁移逻辑隔离•虚拟机计算性能随宿主机总体负载变化可能有20%左右的差异宿主机总体负载70%以内•虚拟机CPU负载建议不要超过70%•云计算平台运维保证宿主机总体负载不超过70%•借助KVM提供的热迁移机制，可以在几分钟内将虚拟机无感知的迁移到另一台宿主机•监控总体负载超高的宿主机，热迁移其它高负载的云主机•网易云主机设计了可用域功能可以物理隔离不同类型业务的云主机•对外业务和内部服务隔离、线上业务和测试系统隔离、数据库与业务隔离高可用数据库RDS（新型数据库引擎NTSE+对新型硬件的支持InnoSQLFlashCache+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存在的数据一致性和缓存效率问题技术挑战内存分配：记录大小不一，使用类LinuxSLAB分配器，根据记录大小，分为不同的级别；替换策略：简单LRU内存开销大，使用页内LRU组合页面级最小堆，将内存开销优化到每记录2字节同记录间的LRU替换算法根据访问热度及频率确定页面替换或记录替换缓存一致性：行级缓存修改，记录Redo日志数据压缩压缩算法表级混合行列压缩支持多种列内及列间规则压缩支持后端通用压缩算法支持多压缩级别基于压缩数据的新型索引支持基本索引（MAX/MIN）和扩展索引（HASH）基本索引自动创建，对压缩率和装载速度无影响扩展索引手动创建，存储成本小于4字节/行，创建速度大大优于传统B+树索引所有索引对查询过程透明高可用支持动态模式（dynamicschema）支持，增加字段仅修改表定义，瞬时完成。创建/删除索引，在线进行，不锁表，不影响应用在线数据备份，备份过程不锁表，不锁数据库，不影响应用数据重整（OPTIMIZE），在线进行，不锁表，不影响应用性能对比（blogbench）blogbench，是模拟网易博客应用的基准测试，特点：SQL简单，以简单的查询、更新、插入为主测试数据：1亿条记录性能改善显著，达到InnoDB的4倍以上2015/4/21TuesdayInnoSQLFlashCache设计思路很多互联网应用按IOPS/GB计算介于SSD和SATA之间，适合使用SSD+SATA混合存储提升性能降低成本，但目前mysql无法有效利用SSD新型硬件优势设计实现了InnoSQLFlashCache：SSD用作二级缓存可靠性可用性增强VirtualSynchronizedReplication：虚拟同步复制，保证崩溃恢复但不保证Slave读取到实时数据FullSynchronizedReplication：全同步复制，保证Slave数据访问一致性缓冲池预热加速，缩短数据库重启预热时间：通过dump/load复制状态crashsafe并行复制云计算多租户环境需求Profiler：限定数据库用户的IO访问次数和CPU使用时间2015/4/21TuesdayInnoSQLFlashCacheLRU替换下的页面才写到FlashCache，避免Flash和内存重复缓存在实现二级缓存的同时也实现了doublewrite功能对SSD只进行顺序写，提升寿命和性能InnoSQLFlashCache：性能对比53620161658245912241774050010001500200025003000BlogbenchFacebook_Flash_Cache_100GFacebook_Flash_Cache_18GInnoSQL_Flash_Cache_18GInnoSQL_Flash_Cache_10GSSD2DiskRAID1同等SSD缓存大小(18G)时InnoSQLFlashCache性能是FacebookFlashCache的2倍；由于InnoSQLFlashCache对SSD只产生顺序写，性能甚至优于将所有数据存储于SSD时的原生MySQL。云阅读应用FlashCache案例优化前硬件配置600GSAS*4，有效容量1.2T优化后硬件配置2TSATA*4+160GSSD*2，有效容量4T成本接近，容量大增，IO负载骤降RDS高可用技术VSR复制保证数据不丢心跳和主动监测双重探活并行复制保证主从无延迟秒级切换VIP切换（秒级）SlaveApply完日志(并行复制保证零延迟）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在线伸缩对开发支持效率高完善的管理特性：备份、统计、监控等现有方案评估OracleRAC成本高昂：商业产品；硬件需求(商业存储系统)可伸缩性风险：现有部署一般不超过20节点中间件产品市场上缺乏成熟的解决方案NoSQL产品可用性、可靠性保障不足复杂查询、事务等功能支持不足缺乏类SQL标准接口，应用开发效率低NDDB系统架构数据Sharding核心一：表级水平切分、两级映射方案保证一级Ha