Home > Database > Mysql Tutorial > body text

解剖SQLSERVER 第十三篇 Integers在行压缩和页压缩里的存储格

WBOY
Release: 2016-06-07 15:19:36
Original
955 people have browsed it

解剖 SQLSERVER 第十三篇 Integers在行 压缩 和页 压缩 里的 存储 格式 揭秘 (译) http://improve.dk/the-anatomy-of-row-amp-page-compressed-integers/ 当解决OrcaMDF对行 压缩 的支持的时候,视图解析整数的时候遇到了一些挑战。 和正常的未 压缩 整数

解剖SQLSERVER 第十三篇    Integers在行压缩和页压缩里的存储格式揭秘(译)

http://improve.dk/the-anatomy-of-row-amp-page-compressed-integers/

当解决OrcaMDF对行压缩的支持的时候,视图解析整数的时候遇到了一些挑战。

和正常的未压缩整数存储不同的是这些都是可变长度--这意味着1个整数的值50只占用1个字节,而不是通常的4个字节。

这些不是新功能了,大家可以看一下vardecimal他被存储为可变长度。然而不同的是两者存储在磁盘上的数据的方式。

注意虽然我只是实现行压缩,他跟页面压缩中使用的行压缩是一样的,并没有区别

大家可以看一下《深入解析SQL Server 2008 笔记》里面有行压缩和页压缩的详细解释

 

 

Tinyint
Tinyint在压缩后和压缩前基本是一样的(tinyint:从0到255的整数数据,存储大小为 1 字节)只有一个例外情况,当数值是0的时候如果开启了行压缩将不占用任何字节,

如果是非压缩存储将会存储0x0,并且占用一个字节。所有的整形类型(tinyint,smallint,int,bigint)对于0这个数值都是同等对待,数值由压缩行元数据进行描述并且不存储任何值

 

Smallint
让我们开始通过观察正常的未压缩的smallint数值, 对于 -2,-1,1,2这些值的存储,0不会存储任何东西。注意,所有这些值会准确的存放在磁盘上,在这种情况下他们使用小字节序来存储

<span>-</span><span>2</span>    <span>=</span>    <span>0xFEFF</span>
<span>-</span><span>1</span>    <span>=</span>    <span>0xFFFF</span>
<span>1</span>    <span>=</span>    <span>0x0100</span>
<span>2</span>    <span>=</span>    <span>0x0200</span>
Copy after login

Little-Endian

从1,2 这两个值开始,他们很直接很简单的转换为decimal和你想要的实际数值。然而,-1有点不一样,显示0xFEFF 将他转换为decimal是65.535 --我们能存储的最大的无符号整形值是2个字节,

SQLSERVER对于一个smallint 的范围是–32768 to 32767

 

计算实际值依赖于所使用的整数溢出。看看下面的C#代码片段:

<span>unchecked</span><span>
{
    Console.WriteLine(</span><span>0</span> + (<span>short</span>)<span>32767</span><span>);
    Console.WriteLine(</span><span>0</span> + (<span>short</span>)<span>32768</span><span>);
    Console.WriteLine(</span><span>0</span> + (<span>short</span>)<span>32769</span><span>);
    </span><span>//</span><span> ...</span>
    Console.WriteLine(<span>0</span> + (<span>short</span>)<span>65534</span><span>);
    Console.WriteLine(</span><span>0</span> + (<span>short</span>)<span>65535</span><span>);
}</span>
Copy after login

输出如下:

<span>32767</span>
-<span>32768</span>
-<span>32767</span>
-<span>2</span>
-<span>1</span>
Copy after login


如果我们这样计算 0+有符号short的最大值,那么最大值就是有符号短整型 32767,很明显负数就是-32767,

然而,如果我们这样计算 0+32.768=32768,那么就会超出short的范围,我们将最高位翻转变成负数 -32768 却不会溢出。

因为这些数都是常数,编译器不允许溢出--除非我们将代码封装在uncheck {}div里面

 

你可能曾经听过虚构的符号位。基本上它的最高位被用于指示一个数是正数还是负数。

从上面的例子应该很明显的显示符号位不是那么特别--通过查询这个符号位决定一个给定的数的符号。看一下当溢出的时候符号位会怎样

<span>32767</span>    =<span>    0b0111111111111111
</span>-<span>32768</span>    =<span>    0b1000000000000000
</span>-<span>32767</span>    =    0b1000000000000001
Copy after login

 

对于由于太大而引起溢出的数字,最高位“sign bit”需要进行设置。这不神奇,它只是用来引起溢出。

那么,我们有一些背景知识知道一个常规的非压缩integers 是如何存储的。现在看一下那些同样数值的smallint 是如何存储在行压缩表里的

-<span>2</span>    =    <span>0x7E</span>
-<span>1</span>    =    <span>0x7F</span>
<span>1</span>    =    <span>0x81</span>
<span>2</span>    =    <span>0x82</span>
Copy after login

让我们尝试将这些值转换为decimal,我做如下转换

-<span>2</span>    =    <span>0x7E</span>    =    -<span>128</span> + <span>126</span>
-<span>1</span>    =    <span>0x7F</span>    =    -<span>128</span> + <span>127</span>
<span>1</span>    =    <span>0x81</span>    =    -<span>128</span> + <span>129</span>
<span>2</span>    =    <span>0x82</span>    =    -<span>128</span> + <span>130</span>
Copy after login
Copy after login

很明显,这些值会以另一种方式进行存储。最明显的不同是我们现在只使用一个字节--由于变成了可变长度存储。当我们解析这些值的时候,我们需要简单的看一下这些数字的字节存储。如果只使用一个字节,我们知道这表示0到255(对于tinyint来讲) 或者对于smallint 数值是 -128到127 。当smallint 存储的那个值范围在-128到127 就会使用一个字节来存储

 

如果我们使用相同的方法,我们明显会获得错误的结果 。1 0 + 129 诀窍是在本例中将存储的值作为无符号整数,然后最小值作为偏移量
而不是使用0来作为偏移,我们将使用有符号 的一个字节最小值-128 作为偏移

-<span>2</span>    =    <span>0x7E</span>    =    -<span>128</span> + <span>126</span>
-<span>1</span>    =    <span>0x7F</span>    =    -<span>128</span> + <span>127</span>
<span>1</span>    =    <span>0x81</span>    =    -<span>128</span> + <span>129</span>
<span>2</span>    =    <span>0x82</span>    =    -<span>128</span> + <span>130</span>
Copy after login
Copy after login

 

这意味着一旦我们超出有符号 的1个字节的范围 我们将需要用2个字节来存储,对吗?

解剖SQLSERVER 第十三篇    Integers在行压缩和页压缩里的存储格

 

一个非常重要的区别是,非压缩值会永远使用小字节序来存储,然而使用了行压缩的整数值却使用大字节序来存储
所以,他们不只使用不同的偏移值,而使用不同的字节序。但是最终的结果都是相同的,不过计算方式却有很大的不同

 

Int 和 bigint
一旦我找到字节序的规律和行压缩整型值的数值架构,int和bigint的实现就很简单了。和其他类型一样,他们也是可变长度的所以你有可能会碰到5字节长的bigint值和1字节长的int值。下面是SqlBigInt 类型的主要解析代码

 

<span>switch</span><span> (value.Length)
{
    </span><span>case</span> <span>0</span><span>:
        </span><span>return</span> <span>0</span><span>;

    </span><span>case</span> <span>1</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>128</span> + value[<span>0</span><span>]);

    </span><span>case</span> <span>2</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>32768</span> + BitConverter.ToUInt16(<span>new</span>[] { value[<span>1</span>], value[<span>0</span>] }, <span>0</span><span>));

    </span><span>case</span> <span>3</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>8388608</span> + BitConverter.ToUInt32(<span>new</span> <span>byte</span>[] { value[<span>2</span>], value[<span>1</span>], value[<span>0</span>], <span>0</span> }, <span>0</span><span>));

    </span><span>case</span> <span>4</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>2147483648</span> + BitConverter.ToUInt32(<span>new</span>[] { value[<span>3</span>], value[<span>2</span>], value[<span>1</span>], value[<span>0</span>] }, <span>0</span><span>));

    </span><span>case</span> <span>5</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>549755813888</span> + BitConverter.ToInt64(<span>new</span> <span>byte</span>[] { value[<span>4</span>], value[<span>3</span>], value[<span>2</span>], value[<span>1</span>], value[<span>0</span>], <span>0</span>, <span>0</span>, <span>0</span> }, <span>0</span><span>));

    </span><span>case</span> <span>6</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>140737488355328</span> + BitConverter.ToInt64(<span>new</span> <span>byte</span>[] { value[<span>5</span>], value[<span>4</span>], value[<span>3</span>], value[<span>2</span>], value[<span>1</span>], value[<span>0</span>], <span>0</span>, <span>0</span> }, <span>0</span><span>));

    </span><span>case</span> <span>7</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>36028797018963968</span> + BitConverter.ToInt64(<span>new</span> <span>byte</span>[] { value[<span>6</span>], value[<span>5</span>], value[<span>4</span>], value[<span>3</span>], value[<span>2</span>], value[<span>1</span>], value[<span>0</span>], <span>0</span> }, <span>0</span><span>));

    </span><span>case</span> <span>8</span><span>:
        </span><span>return</span> (<span>long</span>)(-<span>9223372036854775808</span> + BitConverter.ToInt64(<span>new</span>[] { value[<span>7</span>], value[<span>6</span>], value[<span>5</span>], value[<span>4</span>], value[<span>3</span>], value[<span>2</span>], value[<span>1</span>], value[<span>0</span>] }, <span>0</span><span>));

    </span><span>default</span><span>:
        </span><span>throw</span> <span>new</span> ArgumentException(<span>"</span><span>Invalid value length: </span><span>"</span> +<span> value.Length);
}</span>
Copy after login

可变长度的值是一个包含字节数据的字节数组存储在磁盘上。如果长度是0,没有东西存储因此我们知道他的值为0。

对于每一个剩余的有效长度,简单的使用最小的显示值作为偏移并且添加上存储的值

对于非压缩值我们可以使用BitConverter 类直接将输入值使用系统字节序转为期望值,对于大多数的英特尔和AMD系统,一般都是小字节序(意味着OrcaMDF 不会运行在一个大字节序的系统上)。然而,当压缩值使用大字节序进行压缩,我必须重新映射输入的数组为小端字节格式,并且在字节尾补上0 以便匹配short,int和long的大小


对于shorts和ints 我将无符号数值读取进来,因为这是我所感兴趣的。工作原理是将int 和uint强制转换为long值。我不能对long类型做同样的事情因为没有其他数据类型比long 更大了。对于long的最大值为9.223.372.036.854.775.807,在磁盘里实际存储为0xFFFFFFFFFFFFFFFF。解析有符号long型使用BitConverter得出的结果 -1 由于会导致溢出。由于额外的负数溢出这有可能会导致出错

-<span>9.223</span>.<span>372.036</span>.<span>854.775</span>.<span>808</span> + <span>0xFFFFFFFFFFFFFF</span> =>
-<span>9.223</span>.<span>372.036</span>.<span>854.775</span>.<span>808</span> + -<span>1</span> =
<span>9.223</span>.<span>372.036</span>.<span>854.775</span>.<span>807</span>
Copy after login

 

结论
通常我有很多的有趣的尝试通过执行一个select语句去找出数值在磁盘上以哪一个字节结束。
这不会花很长的时间去实现,技术内幕的书只是作为引导,还有很多东西需要我们深入挖掘

 

第十三篇完

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template
About us Disclaimer Sitemap
php.cn:Public welfare online PHP training,Help PHP learners grow quickly!