百度分布式数据库

简介,谁使用MySQL?为什么使用MySQL?问题性能数据规模伸缩功能特性服务化自动化,目标：,功能：,响应时间吞吐解放大部分产品线,节约资源分布式数据库需求,FulltextSnapshotOptimizedalter,其他,单节点,单节点性能,性能QPS(读/写)响应时间(平均/长耗时)数据规模问题随机读存储引擎cache&系统cache随机写(LRU/checkpoint.)bufferedwriteorderedwrite长耗时绝大部分的请求响应时间在1ms以内IOPS是读操作和写操作的瓶颈!,Vs硬盘(sas10k)QPS提升700%VsSSD(FTLOptimized)QPS提升250%，长耗时减少95%可用空间增多&使用寿命增加通用型优化，读为主应用及写为主应用均适合对应用完全透明，使用方式和以前一样2007年百度尝试Flash，2008年百度网页搜索全面使用Flash2008年MySQL尝试使用Flash,2011年百度MySQL全面使用SSD,我们的优化结果,IO设备特性,IO设备(硬盘&SSD&内存)顺序写、顺序读、随机写、随机读响应时间带宽访问密度价格Tapeisdead,diskistape,flashisdisk,ramlocalityisking.JimGray,SSDVs硬盘,SSD16K随机读比硬盘提升1860SSD16K随机写比硬盘提升100SSD16K顺序写比硬盘提升50SSD16K顺序写比其随机写提升440SSD1M顺序写比64次16K随机写提升800SSD1M顺序写比64次16K顺序写提升68SSD1M顺序写比1次16K顺序写提升3700如何针对这些数据来设计系统？,优化手段,FTLin-pagelogging其他文件系统l2fs,btrfs,zfs.BFTLKernelflashcache存储系统逻辑appendwriterandomreadmerge,性价比,通用型,FTL,IO模型随机写随机读In-pagelogging20%log空间75%raid560%使用率,存储系统逻辑,SSD/硬盘作为SSD/硬盘的写cacheSSD作为硬盘的读cacheSSD作为innodbbufferpool的二级读cache远程memory作为innodbbufferpool的二级读cache不同IO模型分离文件/设备/IO模型转化/分离,写cache,IO模型顺序写(提升800%)随机读MergePagesmappingmem:ssd=1:350Multi-Write提升68%写瓶颈iops-吞吐读瓶颈iops-iops,写cache&读cache,IOPSVs吞吐读CacheVs写Cache性价比预热可维护性数据完整性&一致性透明&通用NandflashVsNorflash100ns、写性能、价格、容量、直接寻址Snapshot(Redirectwrite)Btree(log-based38x?)/Btreepatchcompaction,其他,故障ECCSLCRaid/Rebuild架构继续优化该版本readcache/btreepatchcompaction单节点500G1T功能特性增强snapshotonlinealtertable,分布式,产品定位尽量保证数据库特性，提升数据规模线上低延迟的访问满足具有一定复杂关系的数据操作设计原则应用访问方式不变应用知道数据逻辑分布不同访问模式提供的功能不同自动发现/人工决定/自动处理,总体架构,访问模式,Scan&Search基于PartitionKey单表单机单表多机多表单机多表多机不基于PartitionKey单表多表,数据划分,范围划分散列取模划分枚举划分时间划分组合划分Binding继承,负载均衡&数据迁移,负载均衡目标衡量标准定期汇报数据迁移负载均衡高可用,数据一致性,dbproxy与zookeeperzookeeper内部数据一致性同一tablet不同副本之间的数据一致性(异步/半同步)最终一致性会话一致性不同tablet之间的数据一致性分布式事务单机事务最终一致性,系统可用性&可靠性,多副本部署切换dbproxyzookeepertsslavetsdown/mastertsdown/tabletdown/alltabletdownauto-exchanger/盘柜mq,可扩展性,dbproxyzookeepertab