精华内容
下载资源
问答
  • kafka日志清理策略,compact和delete

    千次阅读 2021-11-22 16:17:14
    kafka log的清理策略有两种:delete,compact,默认是delete 这个对应了kafka中每个topic对于record的管理模式 delete:一般是使用按照时间保留的策略,当不活跃的segment的时间戳是大于设置的时间的时候,当前...

    https://blog.csdn.net/u013200380/article/details/106453013/
    1. kafka日志清理策略概述
    kafka log的清理策略有两种:delete,compact,默认是delete
    这个对应了kafka中每个topic对于record的管理模式

    delete:一般是使用按照时间保留的策略,当不活跃的segment的时间戳是大于设置的时间的时候,当前segment就会被删除
    compact: 日志不会被删除,会被去重清理,这种模式要求每个record都必须有key,然后kafka会按照一定的时机清理segment中的key,对于同一个key只保留罪行的那个key.同样的,compact也只针对不活跃的segment
    配置为
    cleanup.policy: delete
    cleanup.policy: compact
    1
    2
    如果没有特殊说明,本文中的配置均为kafka-1.1, 且为topic级别是设置

    2. kafka segment
    在学习日志清理策略之前,首先了解一下kafka是如何存储和管理日志的,因为他的管理都是基于segment的,所以有必要先了解清楚这个
    segement的产生策略。

    2.1 segmnet 的作用
    kafka的日志存储和消费,对外的最小粒度是partion,也就是producer和consumer最小的选择粒度是某个topic的某些partition。
    每个partition又多个segment组成,这些segment一般是按照时间顺序产生的。
    在单个partition中只有一个处于active的segment,这个segment是正在写入的segment(假设为segmentA),当segmentA的大小达到一定的程度(或者是经过了一定的时长),就会产生一个新的segmentB,这个时候segmentA就不再有数据写入了,变成了不活跃的segment,而segmentB就是当前Active的segment.
    日志清理的策略总是针对不活跃的segment进行的。
    2.2 segment生成相关的配置
    segment.bytes: 每个segment的大小,达到这个大小会产生新的segment, 默认是1G
    segment.ms: 配置每隔n ms产生一个新的segment,默认是168h,也就是7天
    这两个配置是同时起作用的,那个条件先满足都会执行产生新的segment的动作
    在这里,我们就需要注意,需要理解这两个配置在日志的不同场景下可能带来的影响,在下面介绍具体的日志清理策略的时候会再回来看这一块儿。

    3. 日志清理delete策略
    3.1 delete 相关配置
    假如对某个topic(假设为user_topic)设置了 cleanup.policy: delete
    那么当前topic使用的log删除策略就是 delete,这个策略会周期性的检查partion中的不活跃的segment,根据配置采用两种方式删除一些旧的segment.

    retention.bytes: 总的segment的大小限制,达到这个限制后会删除旧的segment,默认值为-1,就是不会删除
    retention.ms: segment的最后写入record的时间-当前时间 > retention.ms 的segment会被删除,默认是168h, 7天
    1
    2
    一些其他的辅助性配置

    log.retention.check.interval.ms: 每隔多久检查一次是否有可以删除的log,默认是300s,5分钟 这个是broker级别的设置
    file.delete.delay.ms: 在彻底删除文件前保留的时间,默认为1分钟   这个是broker级别的设置
    1
    2
    在delete的日志策略下,我们来讨论一下,假如我们想要日志保留3天
    我们可以通过设置

    retention.ms: 259200000
    1
    假设我们保留其他的配置不便。想想一下这个场景:
    日志产生的很慢,3天还没有达到1g,这个时候根据segment的产生策略,还只有一个segment,而且这个segment是活跃的,所以不能被删除,即使到了第4天可能依然不能被删除。这个时候如果我们依然想要优化存储,就可以使用另一个配置来使删除依然能够按时触发,对的,我们可以设置

    segment.ms: 43200000 # 12个小时
    1
    这样的话,每隔12个小时,只有有新的数据进来,都会产生一个新的segment,这样的话,就可以触发3天的删除策略了。
    所以,比较重要的一点是,对于流量比较低的topic,要注意控制 segment.ms< retention.ms

    3.2 简单总结
    kafka启用delete的清理策略的时候需要注意配置

    cleanup.policy: delete
    segment.bytes: 每个segment的大小,达到这个大小会产生新的segment, 默认是1G
    segment.ms: 配置每隔n ms产生一个新的segment,默认是168h,也就是7天
    retention.bytes: 总的segment的大小限制,达到这个限制后会删除旧的segment,默认值为-1,就是不会删除
    retention.ms: segment的最后写入record的时间-当前时间 > retention.ms 的segment会被删除,默认是168h, 7天
    1
    2
    3
    4
    5
    对于低流量的topic需要关注使用segment.ms 来配合日志的清理

    4. 日志清理compact策略
    4.1 日志compact的使用场景
    日志清理的compact策略,对于那种需要留存一份全量数据的需求比较有用,什么意思呢,比如,

    我用flink计算了所有用户的粉丝数,而且每5分钟更新一次,结果都存储到kafka当中。
    这个时候kafka相当于是一个数据总线,任何需要用户粉丝数的业务部门都可以从kafka中拿到这个数据。
    这个时候如果数据的保存使用delete策略,为了保存所有用户的粉丝数,只能设置不删除,也就是

    retention.bytes: -1
    retention.ms: Long.MAX #这个值需要自己去设置实际的数值值

    1
    2
    3
    这样的话,数据会无限膨胀,而且,很多数据是无意义的,因为业务方从kafka中消费数据的时候,实际上只是想知道用户的当前粉丝数是多少,不关注一个月前这个用户有多少粉丝数,但是这些数据都在kafka中存储,会造成无意义的消费。
    kafka提供了一种叫做compact的清理策略,这个策略可以很好的帮助我们应对这种情况。

    kafka的compact 策略要求每个record都要有key,kafka是根据key来进行去重合并的。每个key至少保留一个最新的值。

    4.2 compact的工作模式
    对于每一个kafka partition的日志,以segment为单位,都会被分为两部分,已清理和未清理的部分。同时,未清理的那部分又分为可以清理的和不可清理的。对于可以清理的segment大致是下面的一个清理思路。

    同时对于清理过后的segment如果太小,kafka也会有一定的策略去合并这些segemnt,防止segment碎片化。
    我们通过配置

    cleanup.policy: compact
    1
    来开启compact的日志清理策略
    配套的配置还有

    min.cleanable.dirty.ratio: 可以进行compact的脏数据的比例,dirtyRatio = dirtyBytes / (cleanBytes + dirtyBytes) 其中dirtyBytes表示可清理部分的日志大小,cleanBytes表示已清理部分的日志大小。这个配置也是为了提升清理的性价比设置的,因为清理数据需要对磁盘进行读写,开销并不小,如果你的数据只有很小的重复比例,实际上是没有清理的必要的。这个值默认是0.5 也就是脏了的数据达到了总数据的50%才会清理,一般情况下我如果开启了compact策略,都会将这个值设置为0.1,感觉这样对于想要消费当前topic的业务方更加友好。

    min.compaction.lag.ms: 这个设置了在一条消息在被produer发送到kafka当中之后,多久时间以内不会被compact,为了满足有些想要获取一定时间内的历史快照的业务,默认是0,就是不会根据消息投递的时间来决定消息是否应该被compacted

    4.3 tombstone 消息
    在compact下,还有一类比较特殊的消息,只有key,value值为null的消息,这一类消息如果合并了实际上也是没有意义的,因为没有值,所以kafka在compact的时候会删除value为null的消息,但是并不是在第一次去重的时候立刻删除,而是允许存储的更久一些。有一个特殊的配置来处理。
    delete.retention.ms: 这个配置就是专门针对tombstone类型的消息进行设置的。默认为24小时,也就是这个tombstone在当次compact完成后并不会被清理,在下次compact的时候,他的最后修改时间+delete.retention.ms>当前时间,才会被删掉。

    这里面还有一点需要注意的是,如果你想测试tombstone的删除功能的话,请注意不要使用console-producer,他并不能产生value为null的record,坑死个人的,还是老老实实的用java-client跑一跑吧。

    4.4 低流量topic的注意事项
    同样,因为compact针对的是不活跃的segment,所以我们要对低流量的topic特别小心。
    在流量较低的情况下。假如我们设置

    segment.bytes: 每个segment的大小,达到这个大小会产生新的segment, 默认是1G
    segment.ms: 配置每隔n ms产生一个新的segment,默认是168h,也就是7天

    1
    2
    3
    这样的话,新的segment没有办法产生,也就无从进行compact了。

    4.5 简单总结compact的配置
    kafka启用delete的清理策略的时候需要注意配置

    cleanup.policy: compact
    segment.bytes: 每个segment的大小,达到这个大小会产生新的segment, 默认是1G
    segment.ms: 配置每隔n ms产生一个新的segment,默认是168h,也就是7天
    retention.bytes: 总的segment的大小限制,达到这个限制后会删除旧的segment,默认值为-1,就是不会删除
    retention.ms: segment的最后写入record的时间-当前时间 > retention.ms 的segment会被删除,默认是168h, 7天
    min.cleanable.dirty.ratio: 脏数据可以容忍的比例,如果你的机器性能可以,而且数据量较大的话,建议这个值设置更小一些,对consumer更友好
    min.compaction.lag.ms: 看业务有需要的话可以设置
    1
    2
    3
    4
    5
    6
    7
    对于低流量的topic需要关注使用segment.ms 来配合日志的清理

    5. kafka创建修改topic的命令
    5.1. 创建topic的时候指定配置
    #!/bin/bash


    ZOOKEEPER="127.0.0.1:2181"
    BROKER="127.0.0.1:9092"

    TOPIC="post-count-processed"

    ## 删除操作
    ../kafka_2.12-2.2.0/bin/kafka-topics.sh --bootstrap-server $BROKER  --delete --topic $TOPIC
    sleep 3

    echo "----------------------"

    ../kafka_2.12-2.2.0/bin/kafka-topics.sh --zookeeper ${ZOOKEEPER} --create --topic ${TOPIC} --partitions 1    --replication-factor 3  --config cleanup.policy=compact --config segment.ms=86400000 --config min.cleanable.dirty.ratio=0.1

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    5.2 topic创建时忘了设置,修改方式
    #!/bin/bash

    ZOOKEEPER="127.0.0.1:2181"
    BROKER="127.0.0.1:9092"
    TOPIC="post-count-processed"

    ./kafka_2.12-2.2.0/bin/kafka-configs.sh --zookeeper ${ZOOKEEPER} --entity-type topics --entity-name ${TOPIC}    --alter --add-config "delete.retention.ms=86400000,segment.ms=3600000,min.cleanable.dirty.ratio=0.1"

    1
    2
    3
    4
    5
    6
    7
    8
    5.3 查看你的配置
    #!/bin/bash

    ZOOKEEPER="127.0.0.1:2181"
    BROKER="127.0.0.1:9092"
    TOPIC="post-count-processed"

    ../kafka_2.12-2.2.0/bin/kafka-configs.sh --zookeeper  ${ZOOKEEPER} --entity-type topics --entity-name ${TOPIC} --describe

    1
    2
    3
    4
    5
    6
    7
    8
    参考
    http://kafka.apache.org/11/documentation.html#compaction
    https://www.linkedin.com/pulse/introduction-topic-log-compaction-apache-kafka-nihit-saxena
    https://blog.csdn.net/u013332124/article/details/82793381
    ————————————————
    版权声明:本文为CSDN博主「夜月行者」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/u013200380/article/details/106453013/

    展开全文
  • COMPACT 紧凑型行格式 REDUNDANT 字段长度偏移类型 DYNAMIC 动态行格式 COMPRESSED 压缩行格式 二、COMPACT行格式示意图 三、变长字段长度列表 1.目的 针对于变长字段列入VARCHAR,VARBINARY,TEXT,BLOB等变长字段...

    前言

    了解行结构的意义:

    1. 知道设置好的主键可以节省空间
    2. 知道char的大小设置错误还不如varchar
    3. 知道字符集对变长字段类型的影响
    4. 知道null 和 空串的区别
    5. 还有一些…我还没发现

    Compact行结构 一图以弊之

    在这里插入图片描述

    一、Innodb四种行格式

    1. COMPACT 紧凑型行格式
    2. REDUNDANT 字段长度偏移类型
    3. DYNAMIC 动态行格式
    4. COMPRESSED 压缩行格式

    二、COMPACT行格式示意图

    在这里插入图片描述

    三、变长字段长度列表

    1.目的

    针对于变长字段列入VARCHAR,VARBINARY,TEXT,BLOB等变长字段类型,由于存储的字段长度不固定,如果不记录该字段的真实长度,那么就无法计算出这一行的准确长度,那么就无法进行行与行的切分。
    所以变长字段会占用两部分空间,第一部分是数据的长度,另一部分是该数据所占用的字节数。

    2.规则

    1. 变长字段长度列表是按照逆序存放 的,(这是跟页读取有关,后面补充)
    2. 变长字段的值为null时,不显示在变长字段长度列表中
    3. 变长字段的实际字节长度小于127时,用一个字节表示。 大于127时,用两个字节表示,最多也只需要用2个字节(这个跟内存页的规定有关,这里暂不拓展)
    4. 一个字节8个比特位,最高位为0时,表示这个字段占一个字节,2^7-1 = 127。如果是两个字节,那么第一个字节的最高位应该为1,这样才会读取第二个字节跟第一个字节进行组合表示。

    3.逆序读取变长字段长度列表

    在经过2次尝试后,发现变长字段长度列表是从后往前读的。虽然知道字段的摆放顺序是逆序的,但是对于读取的顺序是逆序的很多文档和书籍中并没有提到。
    16进制变长字段长度列表为: 03 0e 81
    先读取81,发现最高位为1,那么表示这是一个双字节表示一个字段的实际长度,接着读取0e,将81的最高位改为0后,组成的双字节数字就是该字段的实际长度270
    (03) 这里首位字符为0表示单字节表示一个字段的实际长度,字段实际长度为3

    4.字符与字节之间的计算

    变长字段长度列表存储的是该字段字节的长度,而我们在定义的时候一般是定义的字符的长度,那么如何计算呢?
    变长字段最大字节数计算公式:
    最大字节数 = 字段最大字符数*字符集单个字符最大字节数
    这里有几个定义需要解释一下
    字段最大字符数是指的在你定义varchar(M)时,这个M就是你能存储的最大字符数
    字符集单个字符最大字节数指的是该字符集最多用几个字节来表示一个字符。
    最常见的utf8mb4字符集就是用1~4个字节来表示一个字符。

    四、null值列表

    1.目的

    null值列表就是告知在字段中,哪些可能为null的值是null,哪些不是null。这样就能按照顺序正确的读取字段的值。

    2.规则

    1. 只有字段值可为null的字段才能显示在null值列表中
    2. null值列表是通过bit位来进行标识的,一个字段占一个比特位
    3. null值列表bit位是按照字段逆序排列的
    4. 当字段的比特位不够8的倍数时,需要在高位补0
    5. 字段值为null的bit位为1,否则为0

    五、固定头信息

    1.目的

    记录行的位置,页信息,记录类型等信息,是固定的五个字节的大小

    2.头信息的组成

    名称大小(bit位)描述
    预留位1没有使用
    预留位1没有使用
    delete_flag1删除标识
    min_rec_flag1B+树每层非叶子节点中最小的目录项记录都会添加该标记(涉及到索引,后面会写)
    n_owned4一个页有多条记录,这些记录会再进行分组,每个分组有个老大,老大回存储这个分组中有几条记录,这个是给老大用的
    heap_no13当前记录在页中相对位置
    record_type3记录类型 0表示普通记录 1表示B+树非叶子节点的目录项记录 2表示Infimum记录 3表示Supremum记录
    next_record16下调记录的相对位置

    以上表格中刚好可以组成一个5字节的头信息数据

    六、额外信息

    1.作用

    这个信息是mysql自动生成的信息,主要包括row_id 行号 ,trx_id事务id ,roll_pointer 回滚指针。因为mysql是聚簇索引,所有的记录其实就是一颗索引树,所有的记录在树的最底层的叶子节点上。如果我们没有设置主键,也没有一个不存在null值的Unique键,那么mysql会为我们创建一个row_id来作为主键。

    名称大小(字节数)是否必须描述
    row_id6行号,当没有主键也没有不为null的Unique键时才会生成
    trx_id6事务ID
    roll_pointer6回滚指针

    七、真实记录

    在额外信息之后,就是字段的真实数据,按照顺序排放,null值字段被省略(通过null值列表进行组合成完整的字段记录数据)

    八、验证

    1.基于最简单的ASCII测试与解析行格式

    # 创建数据库
    create database mysqlstudy;
    
    # 创建基础表
    create table compact_record_demo(
    	col1 varchar(10),
    	col2 char(5),
    	col3 int,
    	col4 varchar(5),
    	col5 varchar(15) not null
    ) charset=ascii row_format=COMPACT;
    

    在这里插入图片描述

    # 插入数据
    insert into compact_record_demo (col1,col2,col3,col4,col5) values ('aa','bbb',4,null,'cccc');
    insert into compact_record_demo (col1,col2,col3,col4,col5) values ('0',null,5,null,'cccc');
    

    2.获取数据文件

    然后去/var/lib/mysql/mysqlstudy 目录下去取出数据文件 compact_record_demo.ibd文件
    在这里插入图片描述

    3.找到行记录所在位置

    Sublime Text打开ibd文件, 根据ASCII对照找到a所对应的16进制值61 。然后再Sublime Text中搜索
    在这里插入图片描述

    这一块就是真实数据内容了
    那我们开始解析第一条行记录

    4.变长字段长度列表计算流程:

    col1 长度是2,对应的十六进制就是0x02 ,计入变长字段列表
    col2 长度是3,对应十六进制就是0x03,但是是定长字符类型,所以不计入变长字段列表
    col3 定长数字 不计入变长字段长度列表
    col4 值为null ,不计入变长字段长度列表,计入null值列表
    col5 长度为4,对应十六进制值为0x04,计入变长字段列表
    那么变长字段列表的16进制展示形式为 0x04 0x02,而这条记录的尾部为’cccc’,十六进制展现形式为63636363,那么根据一头一尾,我们可以确定整条行记录的信息为一下的内容

    5.compact_record_demo的第一条记录解析:

    0402 // 变长字段列表
    08 // null值列表
    00 00 10 00 2a //固定头信息 5个字节
    00 00 00 00 24 00 // 没有主键时,固定6个字节的rowId,作为主键
    00 00 00 26 5a c8 // 事务ID 固定6个字节
    ba 00 00 01 f6 01 10 // 回滚指针 固定7个字节
    61 61 // 字段col1
    62 62 62 20 20 // 字段col2 值为 bbb ,由于是定长char,所以会在后面补20空格
    80 00 00 04 // 字段col4 值为4(整型数据表示法会在后面进行补充
    63 63 63 63 // 字段5 值为cccc

    6.null值列表计算

    col1 col2 col3 col4 都可以为null ,所以需要四个bit位来展示,那么会占用一个字节,所以08表示null值列表
    二进制表现形式:00001000
    基于前面null值列表的规则,可以计算出每个字段对应的位置和对应位置bit位的值
    在这里插入图片描述

    九、小结

    在学习的过程中,只有不断理解,不断验证,最后进行归纳总结,才能转化为自己的东西。其中可能有些谬误之处,希望不会对后来者造成坏的影响。我所使用的mysql版本是5.7。

    展开全文
  • Mysql compact行格式

    2021-02-15 23:55:49
    InnoDB行格式类型(Compact格式) Compact行格式示意图: Mysql中变长字段是如何存储的 mysql支持变长的数据类型,varchar(m)、varbinary(m)、text、blob类型等,这些变长的数据类型占用的存储...

     

     

     

     

     

    InnoDB行格式类型(Compact格式)

    Compact行格式示意图:

     

     

     

     

    Mysql中变长字段是如何存储的

     

    mysql支持变长的数据类型,varchar(m)、varbinary(m)、text、blob类型等,这些变长的数据类型占用的存储空间分为两部分:

       1.真正的数据内容

       2.申明占用的字节数

    如果不保存真实数据占用字节数,那么mysql服务器无法判断出真实数据有多长,导致无法准确取数据 。所以我们在存储真实数据的时候需要顺便把这些数据占用的字节数也存起来。

    在compact行格式中,把所有边长类型的长度存放在行记录的开头部位形成一个列表,按照列的逆序存放

    CHAR是一种固定长度的类型,VARCHAR则是一种可变长度的类型VARCHAR(M),M代表最大能存多少个字符。( MySQL5.0.3以前是字节,以后就是字符)

     

    基本存储方式

    变长字段的长度列表,null值列表,数据头,column01的值,column02的值,column0n的值...
    
    •  

    变长字段如何存储

    • 某行中有一个变长字段
        # 假如有三个字段 id,name,age其中name是变长类型(Varchar)
        |id|name|age|
        |1|wang|18|
        
        磁盘里的存储为:
        0x04 null值列表 数据头 1 wang 18
        
        # 其中0x04表示name长度为4
    
    • 多行的数据也是紧挨着存储
        # 假如有三个字段 id,name,age其中name是变长类型(Varchar)
        |id|name|age|
        |1|wang|18|
        |2|li|20|
        
        磁盘里的存储为:
        0x04 null值列表 数据头 1 wang 18 0x02 null值列表 数据头 2 li 20
    
    • 单行中多个变长字段如何存储
        # 假如有三个字段 id,name,desc,age其中name,desc是变长类型(Varchar)
        |id|name|desc|age|
        |1|wang|shuaige|18|
        
        磁盘里的存储为:
        0x07 0x04 null值列表 数据头 1 wang shuaige 18
        
        # 其中0x04表示name长度为4,0x07表示desc的长度为7

     

     

     

     

    NULL值列表是如何存储的

    Compact行格式会把可以为NULL的列统一管理起来,存一个标记为在NULL值列表中,如果表中没有允许存储NULL 的列,则 NULL值列表也不存在了。
    二进制位的值为1时,代表该列的值为NULL。
    二进制位的值为0时,代表该列的值不为NULL。

     

        # 假如有三个字段 id,name,age其中name是变长类型(Varchar)
        |id|name|age|
        |1|wang|18|
        
        磁盘里的存储为:
        0x04 00 数据头 1 wang 18
        
        # 其中00表示name,age都不为空,当然这里id是主键,肯定不为空,所以没记录
    

     

     

     

    记录头信息

    除了变长字段长度列表、NULL值列表之外,还有一个用于描述记录的记录头信息,它是由固定的5个字节组成。5个字节也就是40个二进制位,不同的位代表不同的意思,如图:
    在这里插入图片描述

    记录的真实数据

    记录的真实数据除了我们自己定义的列的数据以外,还会有三个隐藏列:
    在这里插入图片描述
    实际上这几个列的真正名称其实是:DB_ROW_ID、DB_TRX_ID,DB_ROLL_PTR。

    一个表没有手动定义主键,则会选取一个Unique键作为主键,如果连Unique键都没有定义的话,则会为表默认添加一个名为row_id的隐藏列作为主键。所以row_id是在没有自定义主键以及Unique键的情况下才会存在的。

    行溢出数据

    VARCHAR(M)类型的列最多可以占用65535个字节。其中的M代表该类型最多存储的字符数量,如果我们使用ascii字符集的话,一个字符就代表一个字节,我们看看VARCHAR(65535)是否可用:
    在这里插入图片描述
    报错信息表达的意思是:MySQL对一条记录占用的最大存储空间是有限制的,除BLOB或者TEXT类型的列之外,其他所有的列(不包括隐藏列和记录头信息)占用的字节长度加起来不能超过65535个字节。这个65535个字节除了列本身的数据之外,还包括一些其他的数据,比如说我们为了存储一个VARCHAR(M)类型的列,其实需要占用3部分存储空间:

    1. 真实数据
    2. 变长字段真实数据的长度
    3. NULL值标识

    如果该VARCHAR类型的列没有NOT NULL属性,那最多只能存储65532个字节的数据,因为变长字段的长度占用2个字节,NULL值标识需要占用1个字节。
    在这里插入图片描述
    在这里插入图片描述

    记录中的数据太多产生的溢出

    一个页的大小一般是16KB,也就是16384字节,而一个VARCHAR(M)类型的列就最多可以存储65533个字节,这样就可能出现一个页存放不了一条记录。

    CompactReduntant行格式中,对于占用存储空间非常大的列,在记录的真实数据处只会存储该列的一部分数据,把剩余的数据分散存储在几个其他的页中,然后记录的真实数据处用20个字节存储指向这些页的地址(当然这20个字节中还包括这些分散t在其他页面中的数据的占用的字节数),从而可以找到剩余数据所在的

     

    记录中的数据太多产生的溢出

    一个页的大小一般是16KB,也就是16384字节,而一个VARCHAR(M)类型的列就最多可以存储65533个字节,这样就可能出现一个页存放不了一条记录。

    CompactReduntant行格式中,对于占用存储空间非常大的列,在记录的真实数据处只会存储该列的一部分数据,把剩余的数据分散存储在几个其他的页中,然后记录的真实数据处用20个字节存储指向这些页的地址(当然这20个字节中还包括这些分散t在其他页面中的数据的占用的字节数),从而可以找到剩余数据所在的

     

     

    Dynamic和Compressed格式

    这两种行格式类似于COMPACT行格式,只不过在处理行溢出数据时有点儿分歧,它们不会在记录的真实数据处存储一部分数据,而是把所有的数据都存储到其他页面中,只在记录的真实数据处存储其他页面的地址。另外,Compressed行格式会采用压缩算法对页面进行压缩。

     

     

     

    参考资料:
    Mysql中变长字段是如何存储的     https://blog.csdn.net/weixin_29491885/article/details/104846592

    innodb行格式和数据页以及索引底层原理分析  https://blog.csdn.net/java_eehehe/article/details/105529353          https://www.cnblogs.com/qcfeng/p/7325307.html

    展开全文
  • Compact IF

    2021-07-03 23:11:53
    Compact IF紧凑型条件判断指令 Compact IF 的语法 IF Condition DO; 语法说明:判断 Condition 是否为 true,如果是 true ,则进行后面 DO 的操作;如果为 false,则不进行后面 DO 的操作,程序指针向下一个语句。...

    Compact IF紧凑型条件判断指令


    Compact IF 的语法

    • IF Condition DO;

      语法说明:判断 Condition 是否为 true,如果是 true ,则进行后面 DO 的操作;如果为 false,则不进行后面 DO

      的操作,程序指针向下一个语句。

    总结

    • Compact IF 在 Condition 直接进行操作,条件满足执行 DO,不满足,则执行下一个语句
    • Compact IF 只有一句,只能根据Condition 执行一个动作
    • Compact IF 不能实现指令的嵌套
    格式IF Condition DO;
    参数Condition判断条件
    DO执行语句
    示例IF n<3 n=n+1;
    说明当 n 小于3时,n 加1
    展开全文
  • 【CVPR 2021】剪枝篇(四):Towards Compact CNNs via Collaborative Compression论文地址:主要问题:主要思路:具体实现:基本符号:通道剪枝:张量分级:全局压缩率优化:多步启发式压缩:实验结果:联系作者:我...
  • 序本文主要研究一下Java 9的Compact StringsCompressed Strings(Java 6)Java 6引入了Compressed Strings,对于one byte per character使用byte[],对于two bytes per character继续使用char[];之前可以使用-XX:+...
  • InnoDB存储引擎和大多数...到MySQL 5.1时,InnoDB存储引擎提供了Compact和Redundant两种格式来存放行记录数据,Redundant是为兼容之前版本而保留的,如果你阅读过InnoDB的源代码,会发现源代码中是用PHYSICAL RECOR...
  • Compact regression tree

    2021-04-20 05:30:39
    [mdlInfo.bytes cMdlInfo.bytes] ans = 1×2 12401 6898 cMdlInfo.bytes/mdlInfo.bytes ans = 0.5562 In this case, the compact regression tree model consumes about 25% less memory than the full model ...
  • A compact profile is a subset of the full Java SE Platform API. Because they have a smaller storage footprint, compact profiles can enable many Java applications to run on resource-constrained devices...
  • 用法:array compact("variable 1", "variable 2"...)参数:此函数接受可变数量的参数,以逗号运算符(',')分隔。这些参数是字符串数据类型,并指定我们要用于创建数组的变量的名称。我们还可以将数组作为此函数的.....
  • 语法:array compact("variable 1", "variable 2"...)参数:此函数接受由逗号运算符(',')分隔的可变数量的参数。这些参数是字符串数据类型,并指定我们要用于创建数组的变量的名称。我们也可以将一个数组作为...
  • mysql中行的格式类型包括:Compact、redundant、dynamic、compressed这四种,行和行之间是通过一个单向链表的形式来连接的,而我在实际工作中最常用到的是compact类型。具体行的类型可以在create中看到,例如:...
  • buffer.compact(); System.out.print(buffer.capacity() + "\t"); System.out.print(buffer.limit() + "\t"); System.out.println(buffer.position() + "\t"); buffer.put((byte) 'E'); buffer.put((byte) 'F'); ...
  • Compact Convolution Module 作者提出了 CompConv 模块,通过分治的策略高效地从输入中学习特征输出。3.1节介绍其动机。3.2节讲述 CompConv 的核心单元。3.3节介绍完整的CompConv模块,以递归的方式执行核心单元。...
  • PHP中的compact()函数

    2021-04-21 09:43:14
    compact()函数创建一个包含变量及其值的数组。它返回一个数组,其中添加了所有变量语法compact(variable1,variable2)参数variable1-可以是带有变量名称的字符串,也可以是变量数组。需要。variable2-可以是带有...
  • compact紧凑算法思想

    2021-06-28 17:28:19
    compact算法思想 只有能用于比较的启发式算法才能结合compact思想 紧凑遗传算法cGA 持久精英紧凑遗传算法pe-cGA 非持久精英紧凑遗传算法ne-cGA 实值紧凑遗传算法rcGA 紧凑粒子群算法cPSO
  • 详细介绍在LSM学习分享——LSM读写流程中提到的copaction操作。主要介绍两种基本策略:size-tiered和leveled。...例如在LSM树中写入时可能触发Compact操作,导致实际写入的数据量远大于该key的数据量。 (...
  • Compact PCI总线 一、 Compact PCI简介 Compact PCI(Compact Peripheral Component Interconnect)简称CPCI,中文又称紧凑型PCI,是国际工业计算机制造者联合会(PCI Industrial Computer Manufacturer’s Group,...
  • 2015-07-09 10:14:59 | +------+------+---------------------+---------------------+ 5 rows in set (0.00 sec) [root@localhost ~]# mysqldump --compact --database test1 >test1.sql Warning: Using unique ...
  • Compact 行格式存储 - NULL 值列表 某些字段可能可以为 NULL,如果对于 NULL 还单独存储,是一种浪费空间的行为,和 Compact 行格式存储的理念相悖。采用 BitMap 的思想,标记这些字段,可以节省空间。Null值列表...
  • In MySQL InnoDB, what is the difference between COMPRESSED, COMPACT and DYNAMIC for ROW_FORMAT?What are the benefits between each other?在 MySQL InnoDB 中,COMPRESSED, COMPACT 和DYNAMIC对于用户来说ROW...
  • 2015-07-09 10:14:59 | +------+------+---------------------+---------------------+ 5 rows in set (0.00 sec) [root@localhost ~]# mysqldump --compact --database test1 >test1.sql Warning: Using unique ...
  • 加拿大西蒙弗雷泽大学陈之钦(Zhiqin Chen )等人的「BSP-Net」相关研究获得了最佳学生论文奖,他们的论文题目是《BSP-Net: Generating Compact Meshes via Binary Space Partitioning》。在最新一期的机器之心 CVPR...
  • Kafka 提供了专门的后台线程定期地巡检待 Compact 的主题,看看是否存在满足条件的可删除数据。这个后台线程叫 Log Cleaner。很多实际生产环境中都出现过位移主题无限膨胀占用过多磁盘空间的问题,如果你的环境中也...
  • ---------------------------------------------------------------------- 翻译一段MySQL关于Innodb的物理行结构的官方文档: Records in InnoDB ROW_FORMAT=COMPACT tables have the following characteristics: ...
  • Learning Compact Geometric Features概述CGF 论文地址:Learning Compact Geometric Features 概述 这篇文章是点云配准领域的一篇文章,为了解决3D局部特征描述的方法,提出了一种独特的学习特征的方法,其中这些...
  • SQLite and SQL Server Compact Toolbox是一个Visual Studio的插件。使用它可以以界面化方式对数据库进行操作。 在Visual Studio 2019 》工具 》管理扩展 中搜索添加安装即可
  • compact操作 mongodb数据库,当存储引擎是wiredtiger时,如果进行集合内数据删除,mongodb不会将释放集合占用的空间,需要通过compact命令来进行集合空间的整理释放,给我的感觉是类似于操作系统的碎片整理。 单个...
  • 文章目录前言一、文章内容二、文章总结三、相关代码 前言 原文地址—2017 一、文章内容 文章想法 输入数据 文章模型 训练方式 模型输出 实验结果 文章结论 二、文章总结 文章novel和优势: ......
  • 一直都没发现,原来 Windows 系统自带了一个文件压缩程序:compact.exe,这个程序位于系统的“Windows\system32”文件夹下,专门用来显示或改变NTFS分区上的文件的压缩状况。利用该程序对系统分区中的任意文件进行...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 109,215
精华内容 43,686
关键字:

compact

友情链接: C8051F410 AD采集.rar