云数据库系统及在互联网领域的应用教学文案.pptx

《云数据库系统及在互联网领域的应用教学文案.pptx》由会员分享，可在线阅读，更多相关《云数据库系统及在互联网领域的应用教学文案.pptx（65页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、云数据库管理系统及在互联网行业(hngy)的应用第一页，共65页。不掌握(zhngw)大数据来源很难得到真正的实际需求建设大型试验(shyn)环境比较困难不能提供足够的人力资源高校在大数据高校在大数据时时代研究代研究(ynji)面面临临的挑的挑战战第二页，共65页。产产学研学研结结合合(jih)大目标统一，相互促进 松散耦合，各层关注自身核心利益 人的联系紧密（同一人在各层间完成(w ch g)身份切换）与大型(dxng)企业合作技术成果应用演示系统市场层人员支持应用层技术支持研究层独立创业需求提供资金支持独立应用系统环境支持研究论文第三页，共65页。浙大与网易的合作(hzu)模式 学生学习研

2、究(y nji)期间即与企业研究(y nji)团队紧密合作（非传统横向项目模式），毕业后选择去该企业就职，乃至(nizh)担任高级职位 创建网易杭州研究院（浙大与网易两块牌子），目前工程研发人员已超过1000人，公共基础技术研究人员超过500人 半数以上的技术高级经理、总监毕业于浙大计算机学院 网易可以提供资金、大数据资源、用户实际需求提供、开发工程师等的帮助 浙大源源不断提供给网易高水平人才，深厚的前期技术积累第四页，共65页。网易私有网易私有(syu)云的架构云的架构NDDB云分布式数据云分布式数据库库RDS单单机数据机数据库库IAAS(云网云网络络(wnglu)、云主机、云硬、云主机、云

3、硬盘盘)NOS对对象存象存储储(cn ch)NCR云云Redis服服务务云云转码转码云容器引擎云容器引擎云云队队列列NCS云搜索云搜索基基础础服服务务数据管理数据管理应应用架构用架构NLB负载负载均衡服均衡服务务第五页，共65页。云数据云数据库对库对云平台云平台(pngti)的需求的需求网络(wnglu)隔离：默认隔离不同(b tn)租户的数据库灵活配置网络连通性,满足特殊需求故障隔离：主备虚拟机不能位于同一个物理机、交换机主备数据不能落到同一个物理机性能保障：CPU、IO、网络性能有保障高可靠：不能容忍数据丢失弹性：存储、计算规格的弹性伸缩第六页，共65页。平台平台(pngti)对对数据数据

4、库库的支持的支持NCRRDSNDDB云网络(wnglu)网络(wnglu)隔离连通性控制云硬盘存储能力高可靠、可用弹性(tnxng)扩容存储池NLB负载均衡高可用云主机计算能力弹性扩容可用域高可用数据库第七页，共65页。网网络络(wnglu)隔离隔离私有(syu)网每个租户拥有一个独立的二层网络不同用户(yngh)私有网络完全隔离机房网不同租户虚拟机之间的互通租户虚拟机到机房中物理机的互通ACL控制连通性互联网链接到互联网（外网）数据库默认运行于私有网络内，不同租户完全隔离。必要时通过机房网络互连第八页，共65页。资资源物理位置失去控制源物理位置失去控制风险风险硬盘主从硬盘的数据可能落在同一物

5、理机或物理硬盘数据库数据丢失主机不同云主机可能位与同一物理机数据库不可用联网不同云主机可能经由同一网卡或网线联网数据库不可用交换机不用云主机可能接入到同一交换机大量高可用数据库发生不可用故障故障(gzhng)隔离隔离风险风险做冗余(rn y)而不隔离故障，是伪高可用、伪高可靠第九页，共65页。可用域a可用域b故障隔离：故障隔离：提供提供资资源位置控制源位置控制 可用域可用域 控制云物理控制云物理资资源位置，源位置，确保故障隔离的机制确保故障隔离的机制 不同不同(b tn)可用域确保物理机、可用域确保物理机、联联网和交网和交换换机隔离机隔离 应应用用场场景：主景：主备备隔离隔离 数据数据库库主主

6、备备从不同从不同(b tn)可用域可用域分配分配 Redis主备 云硬盘两副本(fbn)第十页，共65页。存储(cn ch)池a存储(cn ch)池b故障隔离：故障隔离：提供提供资资源位置控制（存源位置控制（存储储池）池）存存储储池池 云云计计算平台提供用算平台提供用于控制云硬于控制云硬盘盘物理物理(wl)资资源位置，确保故源位置，确保故障隔离的机制障隔离的机制 不同存储池确保物理机隔离 应用场景：主备隔离 数据库主备两块云硬盘从不同存储池分配 云Redis主备两块云硬盘从不同存储池分配第十一页，共65页。高可靠保高可靠保证证：云硬：云硬盘盘需求：要求(yoqi)云硬盘可靠性大于本地RAID，

7、不要求(yoqi)极高可靠性因为(yn wi)数据库本身有主从备份第十二页，共65页。计计算算(j sun)性能性能容量容量预预留留热迁移(qiny)逻辑(lu j)隔离虚拟机计算性能随宿主机总体负载变化可能有20%左右的差异宿主机总体负载70%以内虚拟机CPU负载建议不要超过70%云计算平台运维保证宿主机总体负载不超过70%借助KVM提供的热迁移机制，可以在几分钟内将虚拟机无感知的迁移到另一台宿主机监控总体负载超高的宿主机，热迁移其它高负载的云主机网易云主机设计了可用域功能可以物理隔离不同类型业务的云主机对外业务和内部服务隔离、线上业务和测试系统隔离、数据库与业务隔离第十三页，共65页。高可

8、用数据库RDS（新型(xnxng)数据库引擎NTSE +对新型(xnxng)硬件的支持InnoSQL Flash Cache+VSR技术(jsh)）第十四页，共65页。面向面向(min xin)互互联联网的关系数据网的关系数据库库需求需求OLTP，短小事务(shw)事务(shw)性要求灵活读多写少，数据热点明显(mngxin)，往往集中于数据集的10%以内数据量大，IO为系统瓶颈，CPU能力通常过剩产品升级较快，模式变更频繁第十五页，共65页。现有(xin yu)业内解决方案使用(shyng)MYSQL+InnoDB+Memcached(Redis)主要(zhyo)问题不必要的事务处理机制，造

9、成性能处理的浪费页级缓存效率低空间利用率低下模式变更困难Memcached难以降低更新负载本质上并未针对互联网应用特点为此，设计实现了一个新型数据库存储引擎NTSE，用MYSQL+NTSE来替代MYSQL+InnoDB+Memcached面向互面向互联联网的关系数据网的关系数据库库需求需求第十六页，共65页。关键技术的选择(xunz)OLTP短小事务事务性要求灵活读多写少有(sho yu)热点数据量大IO瓶颈CPU过剩模式变更频繁两种事务模型并可在线转换内存多版本外存单一版本的MVCC设计记录级缓存数据压缩动态(dngti)模式，在线索引修改、备份与数据重整第十七页，共65页。事务(shw)模

10、型两种事务(shw)模型传统ACID事务：保证多实体、多表操作通用(tngyng)事务ACID，支持分布式事务，通用(tngyng)性好单实体ACID事务：保证对单实体的单次操作微型事务的ACID，性能更优（锁定时间短并发度高、无需前向日志、无死锁）事务模型在线切换单实体ACID事务表“升级”为传统ACID事务表：创建内存多版本数据结构，瞬时完成传统ACID事务表“降级”为单实体ACID事务表：purge少量内存多版本数据后销毁内存多版本数据结构，秒级完成第十八页，共65页。MVCC多版本(bnbn)粒度Oracle：页面级多版本，重建(zhn jin)页面开销大NTSE/InnoDB/Pos

11、tgreSQL：记录级多版本，实现(shxin)简单，效率高版本记录存储Oracle/InnoDB/PostgreSQL：外存存储，存储成本高，旧版本回收效率低，能良好支持超大超长事务；NTSE引擎：内存存内存存储储多版本多版本记录记录，外存单一版本记录。存储成本低，旧版本易回收，便于在线事务/非事务切换，但不能支持超大超长事务（应用不需要）；历史记录存储NTSE/Oracle/InnoDB：独立存独立存储储，方便旧版本回收，减少对应用的影响PostgreSQL：数据文件内存储，旧版本回收特别困难；在牺牲了支持超大超长事务（互联网应用一般无此要求）这一功能后，NTSE在存储、旧版本回收、旧版本

12、操作等方面综合效率优于Oracle/InnoDB/PostgreSQL第十九页，共65页。记录(jl)级缓存使用记录(jl)级缓存，缓存频繁访问的行记录(jl)：内存(ni cn)利用率优于页面级缓存解决了目前使用Memcached存在的数据一致性和缓存效率问题技术挑战内存分配：记录大小不一，使用类Linux SLAB分配器，根据记录大小，分为不同的级别；替换策略：简单LRU内存开销大，使用页内LRU组合页面级最小堆，将内存开销优化到每记录2字节同记录间的LRU替换算法根据访问热度及频率确定页面替换或记录替换缓存一致性：行级缓存修改，记录Redo日志第二十页，共65页。数据压缩(sh j y

13、su)压缩算法表级混合行列(hng li)压缩支持多种列内及列间规则压缩(y su)支持后端通用压缩(y su)算法支持多压缩(y su)级别基于压缩数据的新型索引支持基本索引（MAX/MIN）和扩展索引（HASH）基本索引自动创建，对压缩率和装载速度无影响扩展索引手动创建，存储成本小于4字节/行，创建速度大大优于传统B+树索引所有索引对查询过程透明第二十一页，共65页。高可用支持(zhch)动态模式（dynamic schema）支持，增加(zngji)字段仅修改表定义，瞬时完成。创建/删除索引，在线进行(jnxng)，不锁表，不影响应用在线数据备份，备份过程不锁表，不锁数据库，不影响应用数

14、据重整（OPTIMIZE），在线进行，不锁表，不影响应用第二十二页，共65页。性能(xngnng)对比（blogbench）blogbench，是模拟网易博客应用的基准测试，特点：SQL简单(jindn)，以简单(jindn)的查询、更新、插入为主测试数据：1亿条记录性能改善显著，达到InnoDB的4倍以上2015/4/21 Tuesday第二十三页，共65页。InnoSQL Flash Cache设计(shj)思路很多互联网应用按IOPS/GB计算介于SSD和SATA之间，适合使用SSD+SATA混合存储提升(tshng)性能降低成本，但目前mysql无法有效利用SSD新型硬件优势设计(sh

15、j)实现了InnoSQL Flash Cache：SSD用作二级缓存可靠性可用性增强Virtual Synchronized Replication：虚拟同步复制，保证崩溃恢复但不保证Slave读取到实时数据Full Synchronized Replication：全同步复制，保证Slave数据访问一致性缓冲池预热加速，缩短数据库重启预热时间：通过dump/load复制状态crash safe并行复制云计算多租户环境需求Profiler：限定数据库用户的IO访问次数和CPU使用时间2015/4/21 Tuesday第二十四页，共65页。InnoSQL Flash CacheLRU替换下的页面

16、才写到Flash Cache，避免Flash和内存重复缓存在实现(shxin)二级缓存的同时也实现(shxin)了doublewrite功能对SSD只进行顺序(shnx)写，提升寿命和性能第二十五页，共65页。536201616582459050010001500200025003000InnoSQL Flash Cache：性能：性能(xngnng)对对比比Blogbench17741224Facebook_Flash_Cache_100GFacebook_Flash_Cache_18GInnoSQL_Flash_Cache_18GInnoSQL_Flash_Cache_10GSSD2 Di

17、sk RAID 1同等SSD缓存大小(18G)时InnoSQL Flash Cache性能是Facebook Flash Cache的2倍；由于InnoSQL Flash Cache对SSD只产生顺序写，性能甚至(shnzh)优于将所有数据存储于SSD时的原生MySQL。第二十六页，共65页。云云阅读应阅读应用用(yngyng)Flash Cache案例案例优化前硬件配置600G SAS*4，有效容量1.2T优化后硬件配置2T SATA*4+160G SSD*2，有效容量4T成本接近(jijn)，容量大增，IO负载骤降第二十七页，共65页。RDS高可用技高可用技术术(jsh)VSR复制(fzh

18、)保证数据不丢心跳(xn tio)和主动监测双重探活并行复制保证主从无延迟秒级切换VIP切换（秒级）Slave Apply完日志(并行复制保证零延迟）CAP选择C和AP很少发生发生P时可能需要人工介入处理第二十八页，共65页。虚虚拟拟同步同步(tngb)复制：复制：VSRBinlog得到(d do)slave节点ack之后，再提交(tjio)事务，故障时能保证持久性第二十九页，共65页。VSR性能性能(xngnng)VSR提供(tgng)强同步的同时，几乎没有性能损失原因：增大了组提交比例，减少了磁盘(c pn)IO负载第三十页，共65页。高可用高可用优优化：并行复制化：并行复制解决(jiju

19、)MySQL原生复制的痛点从串行执行binlog，主从(zhcng)数据延迟大failover等待数据(shj)同步时间久，可用性差社区的方案基于表的并行复制：无法解决热点表的延迟问题基于批量提交的复制：无法充分利用磁盘带宽基于行的并行复制：并行检测实现难度巨大InnoSQL并行复制原理：一个组提交中的事务都可以并行执行效果：网易云监控数据库延迟从9个小时降低到无延迟、网易电商数据库延迟从5个小时降低到无延迟，可用性大幅提高第三十一页，共65页。failover速数据丢失性能可维护性度Replication大量数据丢失好简单快Semi-syncReplication小部分数据丢失差简单快MHA

20、数据不丢失，前提是Master服务器依然存活（可能性极低）一般简单快SAN数据不丢失，前提是共享存储本身没有发生故障（可能性较高）一般数据库简单SAN设备复杂慢Galera数据不丢失，前提至少有1台服务器存活（可能性较高）差复杂快网易RDS/NTSE数据不丢失，前提至少有1台服务器存活（可能性较高）好简单极快高可用方案高可用方案(fng n)对对比比第三十二页，共65页。应用(yngyng)总结关注性能，事务需求不高的应用，可使用(shyng)NTES提供的非事务功能对事务要求(yoqi)较高的应用，可使用NTES提供的事务功能数据热点集中的应用，可从NTES提供的行级缓存中获取优势数据量大的

21、应用，可使用数据压缩功能提供很好的SSD支持所有应用都能获得高可用支持第三十三页，共65页。云分布式数据库NDDB第三十四页，共65页。产产品品(chnpn)目目标标大容量高并发，100TB兼容(jin rn)标准MySQL协议SQL兼容度高，支持(zhch)跨表JOIN，子查询等高可用，高可靠，强一致（继承自RDS）支持(zhch)从RDS升级到NDDB在线伸缩对开发支持效率高完善的管理特性：备份、统计、监控等第三十五页，共65页。现现有方案有方案(fng n)评评估估Oracle RAC成本高昂：商业产品；硬件需求(商业存储系统)可伸缩性风险：现有部署(b sh)一般不超过20节点中间件产

22、品(chnpn)市场上缺乏成熟的解决方案NoSQL产品可用性、可靠性保障不足复杂查询、事务等功能支持不足缺乏类SQL标准接口，应用开发效率低第三十六页，共65页。NDDB系统(xtng)架构第三十七页，共65页。数据数据(shj)Sharding核心一：表核心一：表级级水平切分、两水平切分、两级级映射方案映射方案(fng n)保保证证一一级级Hash固定；方便后固定；方便后续续的的扩扩容与收容与收缩缩核心二：关核心二：关联联表使用相同分区策略表使用相同分区策略使用相同分区策略的关使用相同分区策略的关联联表，可在分区内完成表，可在分区内完成EQUAL-JOIN(Local Join)第三十八页，

23、共65页。查询处查询处理流程理流程(lichng)第三十九页，共65页。在在线扩线扩容容过过程（程（1扩扩2为为例）例）全量复制：全量复制：新建新建2个个RDS作作为为目目标标RDS源源RDS节节点全量复制数据到目点全量复制数据到目标标RDS记录记录全量复制全量复制时时日志位置日志位置删删除除脏脏数据：数据：2个目个目标标RDS各自各自删删除一半无用数据，相当于除一半无用数据，相当于1拆拆2增量复制：增量复制：从日志的全量复制点开始从日志的全量复制点开始读读取日志回放增量数据到取日志回放增量数据到2个目个目标标RDS等待回等待回访访快要完成快要完成时时，进进行行悬悬停切停切库库悬悬停切停切库库

24、：锁锁定所有定所有查询查询服服务务器器等待尾部少量等待尾部少量(sholing)日志回日志回访访完成完成查询查询服服务务器（器（QS）切）切换换到目到目标标RDS解解锁查询锁查询服服务务器，器，扩扩容完成容完成全量复制(fzh)（只读RDS）Hamal 增量复制+增量数据校验删除(shnch)脏数据 QS悬停切库第四十页，共65页。分布式事分布式事务处务处理理核心核心(hxn)：两：两阶阶段提交段提交(2-Phase-Commit)支持支持SQL Proxy(Query Server)，作为(zuwi)分布式事务的发起者与协调者解析(ji x)用户的SQL，若SQL跨多节点，开始一个分布式事务

25、用户提交事务，QS作为协调者，发起Prepare请求，记录Prepare日志待所有参与者均Prepare成功，发起Commit请求，提交事务，记录Commit日志异常情况一：Query Server崩溃并重启根据Query Server中记录的Prepare日志，处理悬挂事务异常情况二：Query Server永久崩溃将分布式事务日志存储于高可靠的云硬盘系统保证XA事务ACID第四十一页，共65页。NCR云云Redis服服务务(fw)第四十二页，共65页。NCR需求需求(xqi)兼容Redis协议弹性(tnxng)伸缩高可用分钟级部署、完善的统计(tngj)和运维工具第四十三页，共65页。NC

26、R架构架构(ji u)NLB负载负载均衡均衡 4层负载(fz i)均衡 代理(d il)节点 Redis进程 云硬盘云主机第四十四页，共65页。在在线线(zi xin)扩扩容容NLB负载负载均衡均衡NLB负载均衡(jnhng)复制 Pre-shardig:预先创建所有redis进程 通过redis成熟的一对一复制机制迁移部分redis进程实现伸缩 理解业务协议的代理节点延时请求消除节点路由切换影响 有状态系统(x tng)实现自适应无缝伸缩的参考架构第四十五页，共65页。NCR特点特点(tdin)利用已有NLB、云主机(zhj)、云硬盘组件实现(shxin)代价小SLA有保障Preshardi

27、ng+redis主从复制实现扩容优点：实现代价小，且满足应用需求缺点：运维需要有一定专业性,只适用私有云环境缺点：需要实现考虑集群容量，将来考虑采用REDIS CLUSTER第四十六页，共65页。云数据云数据库应库应用用(yngyng)覆盖网易互联网主要(zhyo)应用第四十七页，共65页。小小结结(xioji)云平台(pngti)和数据库一体化设计，平台(pngti)为数据库提供隔离性、性能保障、可靠性、资源弹性，降低云数据库实现代价。云数据库RDS，提供即开即用、稳定可靠、弹性(tnxng)伸缩的高可用数据库服务，RDS也是分布式数据库NDDB的基石。分布式云数据库NDDB,是兼容MySQ

28、L协议，具有横向扩容能力的分布式关系数据库平台，提供大型应用无限伸缩能力。云Redis服务NCR,是高可用的托管式分布式Redis服务，满足复杂内存数据结构存储和缓冲需求。第四十八页，共65页。网易对浙大研究(ynji)的帮助问题来源(iyu)（实际需求，用户奇思妙想）大数据资源设计师+工程师资金(zjn)第四十九页，共65页。myDJ:基于能力的音基于能力的音乐乐(ynyu)推荐推荐（SIGIR/TKDE/ACMMM/TMM）第五十页，共65页。基于能力的音乐(ynyu)推荐研究(ynji)动机为了给用户推荐适合(shh)其自身演唱的歌曲研究问题对唱歌社交社区中海量用户根据歌曲难度进行粗粒度

29、的演唱歌曲推荐对有极高歌曲选择需求的用户根据其发声能力进行细粒度的演唱歌曲推荐研究路线第五十一页，共65页。基于个体发声能力(nngl)的音乐推荐研究(ynji)内容对个体(gt)发声能力进行建模对每首歌曲进行建模从而能用于推荐在发声能力以及歌曲之间建立查询推荐机制第五十二页，共65页。基于个体发声能力(nngl)的音乐推荐发声能力(nngl)可视化男低音查询(chxn)结果展示男中音男高音第五十三页，共65页。唱歌社交(shjio)社区中的音乐推荐系统技术路线创新思想通过对真实用户数据进行挖掘发现歌曲难度序提出歌曲难度图模型，对歌曲难度序进行概率建模提出一种迭代概率推导的能力(nngl)音乐

30、推荐算法进行歌曲推荐第五十四页，共65页。唱歌社交社区中的音乐推荐系统实验结果推荐准确率与传统推荐算法相比提升180%以上，克服推荐系统冷启动(qdng)问题推荐结果在实际用户使用中令人满意算法(sun f)准确率比较第五十五页，共65页。myDJ原型(yunxng)系统可以录制用户发声能力，实时的进行发声能力可视化以及演唱(ynchng)歌曲推荐第五十六页，共65页。LogBase:基于日志基于日志(rzh)结结构的构的弹弹性性数据数据库库（VLDB/ICDE/TKDE）第五十七页，共65页。背景(bijng)介绍传统(chuntng)的数据库保留两份实际上等同的数据：数据库表、日志(rzh

31、)数据库表用来快速回答查询（查询效率高）日志(rzh)用来进行恢复处理（更新效率高）日志(rzh)和数据需要同步（代价高）然而，有一类大数据应用传统数据库不能很好的支持高速更新而查询分布不均匀：高速电商交易（每秒10万笔）、互联网有害信息甄别（数据出入速度极快、分析查询为主）第五十八页，共65页。Log数据库表A=100B=200背景(bijng)介绍基于日志(rzh)的恢复当数据库发生故障时，可以通过日志来进行恢复。利用日志里面记录的事务开始、结束和期间完成的修改(xigi)操作，我们可以将数据库恢复到其发生故障前的状态那么也就是说，可以通过搜索日志来得到数据库中数据那么可以通过日志来回答用

32、户的查询吗？理论上完全可行实际系统中速度太慢第五十九页，共65页。基于日志(rzh)结构的数据库提出(t ch)基于单一日志结构的数据库颠覆了传统数据库（日志(rzh)数据库表）存储结构，仅仅维护一个日志(rzh)文件大大降低了存储代价（不再需要数据表）大大提升了更新速度，单节点每秒10万条，多节点弹性增长新的硬件（如PCM和SSD)进一步提高了日志文件的读写性能主要的挑战：如何在得到以上优点的同时，保证高效的查询处理能力？第六十页，共65页。日志(rzh)结构数据库架构第六十一页，共65页。LogKeyLogKeyLogKeyDataDataData日志结构数据库架构（续）数据表（日志格式）

33、被平均分割(fng)到不同的服务器节点每个服务器节点对每一个表都维护一个指针，指向日志文件的相关位置：每个表的日志先存储在内存缓存中，当达到一定大小(4M)，将被使用append的方式写入日志文件，而服务器则记录该块在日志文件的起始位置每一条日志记录使用特殊的键值进行区别，所有的表数据都存储在一个统一的日志文件唯一的插入(ch r)操作：append日志(rzh)文件表A表B表C第六十二页，共65页。LogBase的查询机制在LogBase中，为了支持高性能的查询，使用了创新的内存硬盘混合(hnh)索引技术分布式日志查询技术内存硬盘混合(hnh)索引技术内存保留类似B树的索引结构每个叶子节点c

34、ache line大小硬盘维护基于日志文件结构的树结构内存索引满了和硬盘树进行合并查询时，根据查询热点模式，大部分查询可以在内存索引得到结果，少数需要搜索(su su)硬盘索引 a,t2,pa,t18,pd,t20,pk,t8,p k,t32,p z,t46,p(Log)第六十三页，共65页。LogBase的查询机制（续）分布式日志查询技术将查询按照键值分割到不同的服务器节点每个节点并行查找结果异步的返回，降低同步代价相比类似的Hbase模型，因为LogBase仅仅维护一份(y fn)日志文件，大大降低了读写的I/O代价WriteOpRead Op内存(ni cn)索引索引同步写流程(lichng)读流程日志文件日志文件日志文件MemDFS第六十四页，共65页。日志压缩算法日志文件大小会随着时间(shjin)增长，而很多日志记录的数据实际已经被后面日志的新数据所替代，成为过时数据定期调用特定的日志压缩算法来合并日志，压缩比达到1/10日志首先根据键值和时间(shjin)进行排序同一键值、不同时间(shjin)的日志进行合并最终产生新的按照键值排序的日志文件原始(yunsh)日志原始(yunsh)日志排序日志排序日志1.删除过期数据Compact2.基于(jy)合并日志排序日志排序日志第六十五页，共65页。