羊毛网站建设视频,wordpress文库主题,wordpress第三方jquery,wordpress short_open_tag一、背景
1.1、影响磁盘性能的因素#xff1a;
主要受限于磁盘的寻道时间#xff0c;优化磁盘数据访问的方法是尽量减少磁盘的IO次数。磁盘数据访问效率取决于磁盘IO次数#xff0c;而磁盘IO次数又取决于数据在磁盘上的组织方式。磁盘数据存储大多采用B树类型数据结构
主要受限于磁盘的寻道时间优化磁盘数据访问的方法是尽量减少磁盘的IO次数。磁盘数据访问效率取决于磁盘IO次数而磁盘IO次数又取决于数据在磁盘上的组织方式。磁盘数据存储大多采用B树类型数据结构这种数据结构针对磁盘数据的存储和访问进行了优化减少访问数据时磁盘IO次数。
1.2、常用的数据结构
1.2.1、B树 B树是一种专门针对磁盘存储而优化的N叉排序树以树节点为单位存储在磁盘中从根开始查找所需数据所在的节点编号和磁盘位置将其加载到内存中然后继续查找直到找到所需的数据。 目前数据库多采用两级索引的B树树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录三次磁盘访问获得数据索引及行ID然后再进行一次数据文件读操作及一次数据文件写操作。
但是由于每次磁盘访问都是随机的而传统机械硬盘在数据随机访问时性能较差每次数据访问都需要多次访问磁盘影响数据访问性能。
1.2.2、LSM树
LSM树可以看作是一个N阶合并树。LSM树本质上就是在读写之间取得平衡
和B树相比它牺牲了部分读性能用来大幅提高写性能。
它的原理是把一颗大树拆分成N棵小树 它首先写入到内存中内存没有寻道速度的问题随机写的性能得到大幅提升在内存中构建一颗有序小树随着小树越来越大内存的小树会flush到磁盘上。
当读时由于不知道数据在哪棵小树上因此必须遍历所有的小树但在每颗小树内部数据是有序的。
数据写操作包括插入、修改、删除都在内存中进行并且都会创建一个新记录修改会记录新的数据值而删除会记录一个删除标志这些数据在内存中仍然还是一棵排序树当数据量超过设定的内存阈值后会将这棵排序树和磁盘上最新的排序树合并。当这棵排序树的数据量也超过设定阈值后和磁盘上下一级的排序树合并。合并过程中会用最新更新的数据覆盖旧的数据或者记录为不同版本。在需要进行读操作时总是从内存中的排序树开始搜索如果没有找到就从磁盘上的排序树顺序查找。
在LSM树上进行一次数据更新不需要磁盘访问在内存即可完成速度远快于B树。当数据访问以写操作为主而读操作则集中在最近写入的数据上时使用LSM树可以极大程度地减少磁盘的访问次数加快访问速度。
Leveldb是Google开源的一个快速轻量级的key-value存储引擎以库的形式提供没有提供上层c/s架构和网络通信的功能。Leveldb存储引擎的功能如下:
1、提供key-value存储key和value是任意的二进制数据。数据是按照key有序存储的可以修改排序规则。
2、只提供了Put/Get/Delete等基本操作接口支持批量原子操作。
3、支持快照功能。
4、支持数据的正向和反向遍历访问。
5、支持数据压缩功能(Snappy压缩)。
6、支持多线程同步但不支持多进程同时访问。
二、LevelDB的组成
构成LevelDb静态结构的包括六个主要部分内存中的MemTable和Immutable MemTable以及磁盘上的几种主要文件Current文件、Manifest文件、log文件以及SSTable文件。如下图所示 2.1、写操作
我们通过写操作来综合了解下这几个文件
当应用写入一条Key:Value记录的时候LevelDb会先往log文件里追加写入成功后将记录插进Memtable中这样基本就算完成了写入操作因为一次写入操作只涉及一次磁盘顺序写和一次内存写入这是LevelDb写入速度极快的主要原因。
Log文件在系统中的作用主要是用于系统崩溃恢复而不丢失数据假如没有Log文件因为写入的记录刚开始是保存在内存中的此时如果系统崩溃内存中的数据还没有来得及Dump到磁盘所以会丢失数据。为了避免这种情况LevelDb在写入内存前先将操作记录到Log文件中然后再记入内存中这样即使系统崩溃也可以从Log文件中恢复内存中的Memtable不会造成数据的丢失。
当Memtable插入的数据占用内存到了一个界限后需要将内存的记录导出到外存文件中LevleDb会生成新的Log文件和Memtable原先的Memtable就成为Immutable Memtable顾名思义就是说这个文件的内容是不可更改的。新到来的数据被记入新的Log文件和MemtableLevelDb后台调度会将Immutable Memtable的数据导出到磁盘形成一个新的SSTable文件。SSTable就是由内存中的数据不断导出并进行Compaction操作后形成的而且SSTable的所有文件是一种层级结构第一层为Level 0第二层为Level 1依次类推层级逐渐增高这也是为何称为LevelDb的原因。
SSTable中的文件是Key有序的各个Level的SSTable都是如此但是需要注意的是Level 0的SSTable文件后缀为.sst和其它Level的文件相比有特殊性这个层级内的.sst文件两个文件可能存在key重叠比如有两个level 0的sst文件文件A和文件B文件A的key范围是{bar, car}文件B的Key范围是{blue,samecity}那么很可能两个文件都存在key”blood”的记录。对于其它Level的SSTable文件来说则不会出现同一层级内.sst文件的key重叠现象就是说Level L中任意两个.sst文件那么可以保证它们的key值是不会重叠的。这点需要特别注意。
SSTable中的某个文件属于特定层级而且其存储的记录是key有序的那么必然有文件中的最小key和最大key这是非常重要的信息。Manifest就是记载SSTable各个文件的管理信息比如属于哪个Level文件名称叫什么最小key和最大key各自是多少。
Current文件是记载当前的manifest文件名。因为在LevleDb的运行过程中随着Compaction的进行SSTable文件会发生变化会有新的文件产生老的文件被废弃Manifest也会跟着反映这种变化此时往往会新生成Manifest文件来记载这种变化而Current则用来指出哪个Manifest文件才是我们关心的那个Manifest文件。
当某个level下的SSTable文件数目超过一定设置值后levelDb会从这个level的SSTable中选择n个文件level0时n1;level0时因key有重叠n1将其和高一层级的level1的SSTable文件合并这就是major compaction。 对于 compaction下文具体分析。
另外LevelDB的写操作是线程安全的LevelDB Write 的线程安全是通过将所有的写入插入到一个队列中, 然后有且仅有一个线程去消费这个队列来做到的. 消费这个队列的线程会把队列头部的几个Batch合并成一个大的Batch 一起消费掉, 也是为了提高效率.
log文件内是key无序的而Memtable中是key有序的如何实现LevelDB的删除操作对于levelDb来说并不存在立即删除的操作而是与插入操作相同的区别是插入操作插入的是Key:Value 值而删除操作插入的是“Key:删除标记”并不真正去删除记录而是后台Compaction的时候才去做真正的删除操作。
2.2、读取记录 1、LevelDB首先会去查看内存中的Memtable如果Memtable中包含key及其对应的value则返回value值即可
2、如果在Memtable没有读到key则接下来到同样处于内存中的Immutable Memtable中去读取类似地如果读到就返回
3、若是没有读到那么只能万般无奈下从磁盘中的大量SSTable文件中查找。因为SSTable数量较多而且分成多个Level首先从属于level 0的文件中查找如果找到则返回对应的value值如果没有找到那么到level 1中的文件中去找如此循环往复直到在某层SSTable文件中找到这个key对应的value为止或者查到最高level查找失败说明整个系统中不存在这个Key)。
2.2.1、为何选择是从低level到高level的查询路径
1、从信息的更新时间来说很明显Memtable存储的是最新鲜的KV对
2、Immutable Memtable中存储的KV数据对的新鲜程度次之而所有SSTable文件中的KV数据新鲜程度一定不如内存中的Memtable和Immutable Memtable的。
3、对于SSTable文件来说如果同时在level L和Level L1找到同一个keylevel L的信息一定比level L1的要新。也就是说上面列出的查找路径就是按照数据新鲜程度排列出来的越新鲜的越先查找。同样的key不同的value逻辑上理解好像levelDb中只有一个存储记录即最新的记录但是在levelDb中很可能存在两条记录比如记录分别存在Level L和Level L1中。如果同时在level L和Level L1找到同一个keylevel L的信息一定比level L1的要新。从道理上讲呢Level L1的数据是从Level L 经过Compaction后得到的Level L比Level L1的数据要新鲜。
2.2.2、SSTable文件很多如何快速地找到key对应的value值
1、在LevelDb中在level 0和其它level中查找某个key的过程是不一样的。
2、因为level 0下的不同文件可能key的范围有重叠某个要查询的key有可能多个文件都包含这样的话LevelDb的策略是先找出level 0中哪些文件包含这个keymanifest文件中记载了level和对应的文件及文件里key的范围信息LevelDb在内存中保留这种映射表 之后按照文件的新鲜程度排序新的文件排在前面之后依次查找读出key对应的value。而如果是非level 0的话因为这个level的文件之间key是不重叠的所以只从一个文件就可以找到key对应的value。
3、如果给定一个要查询的key和某个key range包含这个key的SSTable文件那么levelDb一般会先在内存中的Cache中查找是否包含这个文件的缓存记录如果包含则从缓存中读取如果不包含则打开SSTable文件同时将这个文件的索引部分加载到内存中并放入Cache中。 这样Cache里面就有了这个SSTable的缓存项但是只有索引部分在内存中之后levelDb根据索引可以定位到哪个内容Block会包含这条key从文件中读出这个Block的内容在根据记录一一比较如果找到则返回结果如果没有找到那么说明这个level的SSTable文件并不包含这个key所以到下一级别的SSTable中去查找。
2.3、Compaction操作
LevelDB的compaction操作包含minor compaction和major compaction两种
Minor compaction 的目的是当内存中的memtable大小到了一定值时将内容保存到磁盘文件中如下图所示 从上图可以看出
1、当memtable数量到了一定程度会转换为immutable memtable此时不能往其中写入记录只能从中读取KV内容。immutable memtable其实是一个多层级队列SkipList其中的记录是根据key有序排列的。按照immutable memtable中记录由小到大遍历并依次写入一个level 0 的新建SSTable文件中写完后建立文件的index 数据这样就完成了一次minor compaction。从图中也可以看出对于被删除的记录在minor compaction过程中并不真正删除这个记录原因也很简单这里只知道要删掉key记录但是这个KV数据在哪里?那需要复杂的查找所以在minor compaction的时候并不做删除只是将这个key作为一个记录写入文件中至于真正的删除操作在以后更高层级的compaction中会去做。
2、当某个level下的SSTable文件数目超过一定设置值后levelDb会从这个level的SSTable中选择一个文件level0将其和高一层级的level1的SSTable文件合并这就是major compaction。
在大于0的层级中每个SSTable文件内的Key都是由小到大有序存储的而且不同文件之间的key范围文件内最小key和最大key之间不会有任何重叠。但是因为level 0的文件是通过minor compaction直接生成的所以任意两个level 0下的两个sstable文件可能再key范围上有重叠。所以在做major compaction的时候对于大于level 0的层级选择其中一个文件就行但是对于level 0来说指定某个文件后本level中很可能有其他SSTable文件的key范围和这个文件有重叠这种情况下要找出所有有重叠的文件和level 1的文件进行合并即level 0在进行文件选择的时候可能会有多个文件参与major compaction。
levelDb在选定某个level进行compaction后还要选择是具体哪个文件要进行compactionlevelDb采用轮流的方式比如这次是文件A进行compaction那么下次就是在key range上紧挨着文件A的文件B进行compaction这样每个文件都会有机会轮流和高层的level 文件进行合并。
接着levelDb选择L1层中和文件A在key range上有重叠的所有文件来和文件A进行合并。也就是说选定了level L的文件A,之后在level L1中找到了所有需要合并的文件B,C,D等。合并的过程如下 Major compaction的过程如下对多个文件采用多路归并排序的方式依次找出其中最小的Key记录也就是对多个文件中的所有记录重新进行排序。之后采取一定的标准判断这个Key是否还需要保存如果判断没有保存价值那么直接抛掉如果觉得还需要继续保存那么就将其写入level L1层中新生成的一个SSTable文件中。就这样对KV数据一一处理形成了一系列新的L1层数据文件之前的L层文件和L1层参与compaction 的文件数据此时已经没有意义了所以全部删除。这样就完成了L层和L1层文件记录的合并过程。在major compaction过程中判断一个KV记录是否抛弃的其中一个标准是:对于某个key来说如果在小于L层中存在这个Key那么这个KV在major compaction过程中可以抛掉。因为对于层级低于L的文件中如果存在同一Key的记录那么说明对于Key来说有更新鲜的Value存在那么过去的Value就等于没有意义了所以可以删除。
大体了解了Level DB后让我们来学习下Tair中的LDB。
ldb是基于leveldb开发的一款持久化产品作为Tair的持久化存储引擎适用于确实有持久化需求richldb引擎内嵌Mdb作为内存KV级别cache读写qps较高万级别的应用场景。ldb目前线上使用的ssd机型SSD单机读10w qps 写2W tps (700B测试)因此在成本上要比缓存型产品高出几倍。在支持的数据结构上和mdb相同功能上ldb还支持范围查找但基于性能考虑需特别谨慎使用。
读流程
首先在MemTable文件中寻找查看它的开始和结束是哪一部分找到负责这个key的文件从里面把这个数字给拿出来。对每一个LO都会去找当然如果有一步能够找到就会提前返回。对于LeveIDB会做一些聚合尽量读一次盘能读少一些。
写流程
找到数据分区存入操作指引同时把结果插入到Mdb cache里。这样的话持久化存储引擎的效率跟缓存性效率是一样的如果数据有访问热点的话访问的IP可以得到很好的保证。当memtable写满后dump成Level 0上的sstable无数据合并。Level 会循环compact range。
Ldb的新功能
加入过期时间嵌入一个datafilter逻辑得到这个数据的时候会先过滤一下比如设置一些过期数据这个数据如果已经过期它就会跳过去就认为是不存在的。虽然持久化但是就想把之前数据全部清掉然后再写入新的这样是有异步清理。它本身的compact是自己做的有它内部自己的过程在level-n上做这个过程当中现在主要做的工作就是把一些垃圾数据给清理了在做机群变动的时候因为Tair宕掉一台机器会做数据的重分布导致数据备份的完整性和前端服务的可用性问题这个过程可以把垃圾数据可以清理掉。如果按照自己的过程它不是很敏感我们就要做高Levelcompact我们会主动出发加速一些range合并。使用binlog做异步跨集群数据同步。这里还不是很清楚
典型应用场景
1.存储黑白单数据读qps很高db无法承载。
2.计数器功能更新非常频繁且数据不可丢失。
RDB
名词解释
Restful协议Representational State Transfer资源是由URI来指定。对资源的操作包括获取、创建、修改和删除资源这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。通过操作资源的表现形式来操作资源。资源的表现形式则是XML或者HTML取决于读者是机器还是人是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。
rdb是基于redis开发另一款内存型产品tair抽取了redis内部存储引擎部分支持redis所有数据结构故rdb不仅支持key对应一个value的结构同时也支持key对应多个value的结构结构可以是list/map/set/zset。注很多同学会把value是一个map/list之类的对象和rdb支持的list/hash结构混为一谈。这里再强调一下tair的key和value均为可序列化对象因此如果value是map或者list之类的序列化之后的对象这个还是属于key-value结构而rdb支持的list/hash/set/zset是指一个key对应多个value。比如list就是key-{value1, value2, value3}。设置限制内存quota去除aof/vm增加logiclock的概念lazy清理db数据比如想把area数据都清理掉可能对当时运行会有影响当后台再做的时候可以根据前面访问的时候来比较一下logiclock来确定这个数据是不是在它的生存周期里面如果不在生存周期里面可以做清理就是因为这个数据是不存在的。特别适用容量小一般在M级别50G之内读写qps高万级别的应用场景。由于是内存型产品因此无法保证数据的安全性对数据安全有要求的应用建议在后端加持久化数据源或使用ldb作为rdb的持久化。实现了Restful协议。 典型应用场景
1.用list结构来显示最新的项目列表
2.用sortedset来做排行榜取Top N
3.用set来做uniq操作如页面访问者排重
4.使用hset来做单key下多属性的项目例如商品的基本信息库存价格等设置成多属性。
典型用法
rdb集群应用有复杂数据结构的需求。rdb不仅支持key对应一个value的结构同时也支持key对应多个value的结构结构可以是list/map/set/zset。
MDB
mdb是Tair最早的一款内存型产品也是在公司内部应用最广泛的集中式缓存。特别适用容量小一般在M级别50G之内读写QPS高万级别的应用场景。由于是内存型产品因此无法保证数据的安全性对数据安全有要求的应用建议在后端加持久化数据源例如MySQL
典型应用场景
用于缓存降低对后端数据库的访问压力。临时数据存储分钟级别后失效偶尔部分数据丢失不会对业务产生较大影响。读多写少读qps达到万级别以上。
mdb是memche系统在内存里面真正内存管理使用page和slab。抽样出一个area的概念有很多应用会共用一个应用给第一个area做一个逻辑分区可以针对area获得配额进行数据清除不会影响其他的应用做到逻辑分区。有些应用有些情况下一些数据这段时间不想用可以直接清掉是可以支持的。
支持数据过期的应用会有后台的一些逻辑来把它清理掉。它的内存使用率会是一个问题所以会在一定时间去均衡slab达到内存使用率优化。还对它各种操作、统计都做了很详细的监控可以实时监控到这个集群的情况。
还有后台进程后台进程能做两个事情会定期对数据进行清理。另外一个为了内存利用率会做一些均衡slab的管理达到内存使用率的均衡。
典型用法
session场景。这种场景一般访问量非常高且对响应时间有很高的要求对数据有一定的一致性要求。后端无数据源数据丢失对应用影响不大。 作者lxqfirst 链接https://www.jianshu.com/p/91367e93612f 来源简书 著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。
