在分析Avro源码时,发现Avro为了对int.long类型数据压缩,采用Protocol Buffers的ZigZag编码(Thrift也采用了ZigZag来压缩整数). 1. 补码编码 为了便于后面的分析,我们先回顾下几个概念: 原码:最高位为符号位,剩余位表示绝对值: 反码:除符号位外,对原码剩余位依次取反: 补码:对于正数,补码为其自身:对于负数,除符号位外对原码剩余位依次取反然后+1. 补码解决了原码中\(0\)存在两种编码的问题: \[ 0=[0000 \enspace 0000]_

ZigZag编码 在网络传输和数据存储场景中,需要对数据进行压缩.数据压缩的算法非常多,但大部分的数据压缩算法的原理是通过某种编码方式不存储数据中的0比特位,因此0比特位越多,数据压缩的效果越好.ZigZag编码就是一种增加0比例位的编码方式.下面使用Java语言来描述ZigZag编码. 一.编码 正数 假设数据类型为byte的正数11,其二进制表示为:00001011 数据左移一位:00010110 符号位(正数的符号为0)放到最后一位:00010110 负数 假设数据类型为byte的负数-1

原文链接:hbase源码系列(四)数据模型-表定义和列族定义的具体含义 hbase是一个KeyValue型的数据库,在<hbase实战>描述它的逻辑模型[行键,列族,列限定符,时间版本],物理模型是基于列族的.但实际情况是啥?还是上点代码吧. HTableDescriptor tableDesc = new HTableDescriptor("test"); //日志flush的时候是同步写,还是异步写 tableDesc.setDurability(Durability.

前言 最近基于huffman编码和最小堆排序算法实现了一个压缩.解压缩的小程序.其源代码已经上传到github上面: Jcompress下载地址 .在本人的github上面有一个叫Utility的repository,该分类下面有一个名为Jcompress的目录便是本文所述的压缩.解压缩小程序的源代码.后续会在Utility下面增加其他一些实用的小程序,比如基于socket的文件断点下载小程序等等.如果你读了此文觉得还不错,不防给笔者的github点个star, 哈哈.在正式介绍Jcompres

这个程序是研一上学期的课程大作业.当时,跨专业的我只有一点 C 语言和数据结构基础,为此,我查阅了不少资料,再加上自己的思考和分析,实现后不断调试.测试和完善,耗时一周左右,在 2012/11/19 完成.虽然这是一个很小的程序,但却是我完成的第一个程序. 源码托管在 Github:点此打开链接 以下为完整的作业报告: 一.问题描述: 名称:基于哈夫曼编码的文件压缩解压 目的:利用哈夫曼编码压缩存储文件,节省空间 输入:任何格式的文件(压缩)或压缩文件(解压) 输出:压缩文件或解压后的原文件 功

Elias-Fano编码过程如下:把一组整数的最低l位连接在一起,同时把高位以严格单调增的排序划分为桶. Example: 2, 3, 5, 7, 11, 13, 24 Count in unary the size of upper bits “buckets” including empty ones:110=>计算最大的桶,此处是110,计算方法如下:Maximum bucket: [U / 2^l]Example: [24 / 2^2] = 6 = 110 连接最低位: Concaten

记录一下在做一个报修功能的心路历程,需求功能很简单,一个表单提交,表单包含简单的文字字段以及图片 因为使用的是weui框架,前面的话去找weui的表单和图片上传组件,说实话,weui的组件写的还不错,作为一个不太懂前端的渣渣可以拿来开箱即用 主要是不用调那么多的样式问题,直接上代码: <div class="weui-cell"> <div class="weui-cell__bd"> <div class="weui-upl

LevelDB内部通过采用变长编码,对数据进行压缩来减少存储空间,采用CRC进行数据正确性校验.下面就对varint编码进行学习. 传统的integer是以32位来表示的,存储需要4个字节,当如果整数大小在256以内,那么只需要用一个字节就可以存储这个整数,这样就可以节省3个字节的存储空间,Google varint就是根据这种思想来序列化整数的 无符号 Varint 是一种紧凑的表示数字的方法.它用一个或多个字节来表示一个数字,值越小的数字使用越少的字节数.这能减少用来表示数字的字节数. Va

Protocol Buffers编码详解,例子,图解 本文不是让你掌握protobuf的使用,而是以超级细致的例子的方式分析protobuf的编码设计.通过此文你可以了解protobuf的数据压缩能力来自什么地方,版本兼容如何做到的,其Key-Value编码的设计思路.如果你详细了解此文,你应该就能具备自己造一套编解码轮子的能力(至少基本思路). 测试的例子 阅读图片时请对比前面的例子和表格.每个字段的名称都是包含了tag的. message S2 { optional int32 s2_1 =

3D文件压缩库——Draco简析 今年1月份时,google发布了名为“Draco”的3D图形开源压缩库,下载了其代码来看了下,感觉虽然暂时用不到,但还是有前途的,故简单做下分析. 注:Draco 代码地址: https://github.com/google/draco 基本使用 编译 cmake . + make 编译源码,生成 draco_encoder 和 draco_decoder 两个可执行文件 编码/压缩 使用 draco_encoder 压缩 obj 或 ply 的文件: ./d

http://blog.sina.com.cn/s/blog_4155bb1d0100soq9.html INTEL MEDIA SDK是INTEL推出的基于其内建显示核心的编解码技术,我们在播放高清视频时得益于这个硬解码,极大地降低了CPU占用率.除了解码,它还有编码功能,有硬件编码(SDK HARDWARE)和软件编码(SDK SOFTWARE),那么,INTEL的这个技术到底有多大能耐呢? 最新的小日本TMPGEnc Video Mastering Works 5的编码引擎可以分别调用IN

前言 通常在搜索打分完毕后,IndexSearcher会返回一个docID序列,但是仅仅有docID我们是无法看到存储在索引中的document,这时候就需要通过docID来得到完整Document信息,这个过程就需要对fdx/fdt文件进行读操作.为了更清楚地了解fdx/fdt文件的作用,本文把fdx/fdt文件的读和写整合到了一起,尽管这在Lucene中是两个分开的过程. 1. 索引生成阶段 索引生成阶段包含着一个复杂的过程,所以了解本文前最好对Lucene的索引架构有一定的了解,可以参考博

本文介绍protocol buffer消息二进制传输格式.在应用程序中使用protocol buffer时,你并不需要了解这些,但它对你了解protocol buffer格式如何影响你的编码消息的大小很有用. 简单消息 我们从一个非常简单的消息定义开始: message Test1 { int32 a = 1; } 在程序中,你可以创建一个Test1,然后设置a为150.之后你讲消息序列化到一个输出流.如果你想检查编码的消息,你会看到三个字节: 08 96 01 那么,这些数字代表什么呢?接着往

前面的话 每天都有各种媒体对象经由HTTP传送,如图像.文本.影片以及软件程序等.HTTP要确保它的报文被正确传送,识别.提取以及适当处理.为了实现这些目标,HTTP使用了完善的标签来描述承载内容的实体.本文将详细介绍HTTP的实体和编码 实体介绍 如果把HTTP报文想象成因特网货运系统中的箱子,那么HTTP实体就是报文中实际的货物.下图展示了一个简单的实体,装在HTTP响应报文中 实体首部指出这是一个纯文本文档(Content-Type : text/plain),它只有18个字节长(Cont

compress命令 compress命令使用"Lempress-Ziv"编码压缩数据文件.compress是个历史悠久的压缩程序,文件经它压缩后,其名称后面会多出".Z"的扩展名.当要解压缩时,可执行uncompress指令.事实上uncompress是指向compress的符号连接,因此不论是压缩或解压缩,都可通过compress指令单独完成. 选项: -f:不提示用户,强制覆盖掉目标文件: -c:将结果送到标准输出,无文件被改变: -r:递归的操作方式: -b

(一)概述 音频数据一般都具有较高的采样率,经过压缩的原始数据才具有实用价值,否则不仅要占用大量存储空间而且在播放或进行网络传输时效率也是非常低下的,所以音频数字压缩编码在多媒体应用中有着广泛而又重要的用途. 音频的编码压缩方式有许多种,这些不同的压缩方式有着不同的数据压缩比和还原音质,具体的编码格式和算法更是大相径庭.多数协议都比较复杂,普通程序难以实现其加.解压算法,而为多媒体提供了较强支持的Windows 98操作系统引入了ACM和VCM技术,用来管理系统中存在的所有的音频和视频编.解码器

1. 压缩编码概述 数据压缩在日常生活极为常见,平常所用到jpg.mp3均采用数据压缩(采用Huffman编码)以减少占用空间.编码\(C\)是指从字符空间\(A\)到码字表\(X\)的映射.数据压缩编码指编码后信息的长度较于原始信息要短.本文试图探讨Huffman编码是如何保证唯一可译性.如何压缩.以及压缩效率如何? 前缀码 前缀码的任意一码字均不为其他码字的前缀,此保证了编码的唯一可译性.比如码字表{0, 01, 11, 1},0为01的前缀,1为11的前缀:当遇到字符文本011100,是应

Druid底层不保存原始数据,而是借鉴了Apache Lucene.Apache Solr以及ElasticSearch等检索引擎的基本做法,对数据按列建立索引,最终转化为Segment,用于存储.查询与分析. 首先,无论是实时数据还是批量数据在进入Druid前都需要经过Indexing Service这个过程.在Indexing Service阶段,Druid主要做三件事:第一,将每条记录转换为列式(columnar format):第二,为每列数据建立位图索引:第三,使用不同的压缩算法进行压

Google Protocol Buffer 使用到了两种编码方式:Varints 和 zigzag. 一 Varints 编码 每个 byte 只用 7bit 表示数字,最高位 bit作为标志位,如果为: 1,表示后续的 byte 也是该数字的一部分: 0,表示结束. 因此值越小的数字使用越少的字节数.例如小于 128 的数只需要用一个 byte 表示. 1: 0000 0001 128: 0111 1111 129: 1000 0001 0111 1111 二 Zigzag 编码 负数最高位

Yslow的第4个经验法则指出:启用gzip压缩功能,能够降低HTTP传输的数据和时间,从而降低client请求的响应时间. 本篇是Yslow法则的第四个,主要包含三个方面的内容: 1.      什么是gzip 2.      gzip与HTTP 3.      nginx启用gzip 什么是gzip? Gzip最早出如今Unix系统中,是GNU的文件压缩工具.我们今天所说的Gzip,并非特指Linux/Unix中的压缩工具,而是指HTTP中普遍使用的内容编码格式(内容编码,这里指的是内容的压