（一）Hyper的数据管理概述

Hyper是一个单机的数据库，不过现在有人把它分布式化了，性能还很好。
http://www.vldb.org/pvldb/vol9/p228-roediger.pdf
数据的类型区分：

Hyper将数据分为了冷数据和热数据，冷数据就是经常读不常写的，热数据就是经常写的不经常读的。

为了能够支持对热数据的快速访问，热的数据如果要压缩必须是轻量级的压缩。

在hyper中，Relations被放到一个单独的tuples中，cold数据是被放在了一个不会被改变的区域（DataBlock区域）。其DataBlocks采用的轻量级的压缩，涉及到：排序字典压缩，截断，单值压缩。但是不管是哪种压缩，压缩都只到了字节级别，都是可以通过按字节寻址的，不是按照bit寻址的，也就说没有进行位压缩，对于字符串的压缩，Hyper用的是字典的压缩。

和SAPHANA不同的是，SAPHANA将Relations（也就是数据）分成了读多和写多的区域，每个区域都是有做压缩的，而且更新操作数据需要合并。

Hyper中DataBlock的管理：

Hyper中DataBlock很像IBM的DB2 BLU，与之不同的是，Hyper中数据没有做位压缩，用了一个PSMA小index。

Hyper将就是把数据写到了一个fix-size的chunks(2^16的chunk)中，其相关的压缩的元数据也是和数据绑定在了一起，当数据块被标识成为cold数据的时候，会将chunk标记成为是DataBlock,这个datablock中的数据是保持不变的。在DataChunk中的数据才是被压缩了的。

DataBlock中的SMA和PSMA

为了提高Datachunk读取速度，Hyper提供了一个索引，叫做，PSMA，这个PSMA的作用呢，就是标识了数据在一个DataBlock中scan的范围，说白了就是个范围的索引，提供了：=，> ,< , <= >=操作的索引。这个index是在数据被freezing的时候，才被计算出来，index的粒度是指明了在一个DataBlock里面一次Scan能够访问到的哪些tuple。

在Hyper中，每个DataBlock里面有若干的SMAs，每个SMA指明了其对应列的数据的物理值中的最大值和最小值。在取某些列数据的时候，会提供一个PSMA，PSMA指向了若干个SMA，这些个SMA代表的数据位置的交集就是所要输出的数据的可能位置。

在DataBlock内部，Hyper根据列数据值的分布选择不同的压缩策略。

Hyper中的chunk是没有压缩的逻辑组织，hot chunk中是没有SMA和PSMA的，主要考虑到的是跟新这个SMA和PSMA的代价问题(ofcourse)

在数据变冷的时候，Hyper认为O(N)复杂度的Merge操作都是costly的，所以它的做法是：

一旦数据被冷冻起来了，它就是不变的了，不会涉及到Merge 的操作，如果要对这个数据进行更改也是可以的，方法就是先解冻，然后加热它，让他变成热数据，然后就可以吃了，是改了。(吃货本质暴露)

DataBlock数据组织方式：

一个DataBlock装了大约2^16个数据。首先在DataBlock中放的是数据个数，然后是每个列数据的压缩策略，然后是这个列的SMA的偏移量。

组织方式如下图，颜色对应起来：



Hyper指出，这种范围索引最大的好处就是对那种已经排序过的数据能够具有很好的过滤性能，比如L_shipdate。

但是那种异常值比如我们的rowid向量，这种过滤不明显，所以Hyper提出了PSMA，来进一步过滤数据。

Hyper对数据的更新方式：

Hyper的更新操作采用的是删除然后插入的方式来更新。

Hyper没有采用位压缩的方式：它认为，在Scan方面，只有当取数据时候的那个最开始的Filter发现，现在没有符合标准的tuples而且是整个Blocks都可以被skip的时候，或者所有的属于一个Block的tuples都符合标准的时候，位压缩才具有优势。其实说白了就是说，位压缩的解压缩代价太大了，要不就是没有Block可以用，当然更加谈不上压缩和解压缩，要不就是所有的Block的数据都是我们想要的，那么估计这个时候数据直接传就可以了。

Hype里面有一个叫做PSMa的压缩的轻量级的索引，这个用来标识了所要的数据的在Block中的范围。

在优化方面，Hyper用到了向量化(Vectorization )和JIT处理数据，前者可以用到计算机的SIMD特性，具体用到了selecttion scan , bit unpacking , bulk loading , sorting 和 breadth-first中，后者呢，可以优化代码，让参数的传递在CPUcache之间传递？？？？现在，在hashjoin方面，已经用到了Vectorwise on JIT-compiling.

冷数据在Hyper里面是不会被修改的，但是允许一种操作，就是delete，Hyper采用的打标记的方式，将数据delete后，就会在hot区域中插入一条新的数据。

Hyper最爱的轻量级索引

Hyper认为，如果前期的Filter出来的数据中结果是稀疏的，那么采用bit压缩的方式来组织数据的解压代价是costly的。它认为，Hyper数据中的轻量级的压缩策略，可以适应于稀疏的结果的读取，而且压缩代价也是cheap的。

它之所以具有这样的特性，是因为它有一个轻量级的索引。这个索引其实就是指定了数据在DataBlock中的位置。

Hyper中DataBlock存储位置：

依然是在内存中

Hyper中如何高效的处理OLAP和OLTP的业务：

Hyper中提到的tuple-at-a-time JIT compilation ，好处是提高程序的执行效率https://www.zhihu.com/question/19672491。对于OLTP的业务，采用的JIT编译的代码来处理，数据之间的传输通过的是CPU的register，对于OLAP的数据的处理，向量化方式的处理方式并不能够带来好的收益。对于OLAP的数据的处理，是通过vectorization（向量化，就是以列的方式）处理，数据是过内存的，向量化方式处理好处主要是当数据需要scan的时候。但是，由于在DataBlock上面的数据有不同的压缩策略，如果单纯的用JIT编译代码的方式的话，由于不同的压缩策略，导致了不同的memory
layout，会给JIT编译器带来很大挑战，其效率也会降低。

那么如果向JIT编译器屏蔽底层数据的不同的压缩策略，解决等层异构的数据存储结构，就是通过vectorization scan解决。向量化scan数据的操作是采用的预编译的方式。除此以外，vectorization 可以用SIMD做优化。

我想，一般OLTP的操作设计的数据量都不大，而且，数据主要是集中在小范围的修改操作上面，所以数据可以不过内存。

Hyper采用了向量化的方式读取数据，然后以将数据喂给JIT-complied tuple-at-a-time的 pipeline。

Hyper中压缩的数据存在于什么传输中：

Hyper只Filter和point-access（点访问）的时候，才会用到数据压缩的方式。在复杂的数据操作，比如在join上，Hyper不作数据的压缩。

论文中提到的JIT：

Vectorwise，Impala都用到了JIT，这是啥子呢，需要具体研究