Hummer Time Series DB 数据存储模型

多元（维）时序

     Hummer时序数据库支持多维度时序数据记录，即一条记录出了时间字段外， 还可包含不同类型的多个列。这种多维时序记录结构很适合当前物联网传多元（维）时序
     Hummer时序数据库支持多维度时序数据记录，即一条记录出了时间字段外， 还可包含不同类型的多个列。这种多维时序记录结构很适合当前物联网传感器数据（如陀螺仪记录的X,Y,Z三个重力方向值；如交通卡口记录的车牌号、车速、车颜色、车牌等多维计量值）。

支持定长/变长/可空字字段

     - 对于变长和定长字段采用不同的存储结构，最大程度降低存储空间和解析代价；同时稀疏记录中大量空字段进行特别优化处理，避免空字段占用额外存储空间，从而大大节省了稀疏记录的存储空间

多种排序格式

     -  时序数据处理的主要特征 :   时间断面(区间)上进行精确、模糊、条件检索 —— 例如 : 查找国庆期间查询给定嫌疑人通讯踪迹(精确查询) ; 查春节期间具有“陕A”车牌号字样的进京车辆/总数(模糊前缀查询) ; 查询大年初一北京望京地区用电量最高的电表(地域条件查询)；除时间区间上基本检索外，很多场景更需要在时间段面(区间)上进行各种统计分析计算 —— 例如 : 如，总量统计、同比、环比计算等。

针对上述时序数据处理的两大场景 : “区间内个体回放”和“区间内统计分析”(前者是在时间区间上进行给定key的检索；后者是在时间区间上进行分析计算)，分别设计了KT和TK两种针对性存储格式。如果应用场景同时有统计分析和个体回放两类需求，则可使用蜂鸟专有的PKT格式兼顾这两类需求 —— PKT格式属于TK格式和KT格式之间的一种“折中”选择。若场景确定时，优先考虑使用KT或TK场格式 —— 比如，侦查员追查嫌疑车辆轨迹，或疑犯的通话记录等场景，属标准的个体回放需求，应优先考虑KT格式；路况车流等指标计算则属于区间内统计分析运算需求，应优先考虑TK格式；但当你既想查看给定车轨迹，又想统计路况信息时，则最好选择PKT格式了（这也是默认格式）。

 

我们以示例数据做样本，分别按照三种不同存储格式组织时序数据，通过对比展示几种格式之间的区别。

示例数据:

时间从 2012-06-19 20 ： 30 ： 00 到 2012-06-21 02 ： 30 ： 00 三个小时区间为例， 共到来9个时序数据，内容分别如下:

2012-06-19 20:30:00 (1340109000000)  K1 ， V1 （内部包含colume1,colume2,colume3,....)

2012-06-19 20:40:00 (1340109600000)  K3 ， V2

2012-06-19 21:10:00 (1340111400000)  K2 ， V3

2012-06-19 21:35:00 (1340112900000)  K1 ， V4

2012-06-19 21:45:00 (1340113500000)  K3 ， V5

2012-06-19 22:15:00 (1340115300000)  K1 ， V6

2012-06-19 22:45:00 (1340117100000)  K3 ， V7

2012-06-19 22:55:00 (1340117700000)  K2 ， V8

2012-06-19 22:58:00 (1340117880000)  K1 ， V9

 

TK  格式(即 TIMESTAMP-KEY 格式) —— 该格式首先按照事件发生时间排序，当时间相同时，则再按照事件ID(key)排序。具体 Layout 见下表 

Timestamp	Key	Colume1	Colume2	Colume3	....
1340109000000	K1
1340109600000	K3
1340111400000	K2
1340112900000	k1
1340113500000	K3
1340115300000	K1
1340117100000	K3
1340117700000	K2
1340117880000	K1
...	...

 

 

KT  格式(即 KEY-TIMESTAMP 格式) —— 该格式首先按照key排序。当在key相同时，则再按照事件发生时间再排序。具体 Layout 见下表

Key	Timestamp	Colume1	Colume2	Colume3	.....
K1	1340109000000
K1	1340112900000
K1	1340115300000
K1	1340117880000
K2	1340111400000
K2	1340117700000
K3	1340109600000
K3	1340113500000
K3	1340117100000
...	...

 

 

PKT  格式(即 PARTITION-KEY-TIMESTAMP 格式) —— 该格式首先按照时间分区分组排序(其中partition可选择小时、天、月、年等时间单位，其类似传统数据库中的分区概念)，在 组内首先 按照KEY排序，相同KEY 再按照 事件时间排序。具体 Layout 见下表（ 分区单位 - 小时）

Parttion	Key	Timestamp	Colume1	Colume2	Colume3	Colume4
13401072	K1	1340109000000
13401072	K3	1340109600000
13401108	K1	1340112900000
13401108	K2	1340111400000
13401108	K3	1340113500000
13401144	K1	1340115300000
13401144	K1	1340117880000
13401144	K2	1340117700000
13401144	K3	1340117100000
...	...

 

   上述的数据存储格式核心目的都是为了让时序数据在磁盘上“有序存储”，从而按区间扫描时磁头可保证高速顺序移动，并且遍历的数据尽可能少。如果理解了这个准则，那么自然可知上述时序数据格式各自的优缺点了：

• TK格式对于区间内无key检索性能最优，而对于给定key查询则有所浪费 —— 因为TK格式中未按KEY聚集数据，所以检索给定KEY需要扫描给定时段内全部数据。
  
• KT格式对于给定key检索性能最优，如果区间内无key查询则是麻烦 —— 因为KT格式下要统计给定时段则必须扫描全部数据。
  
• PKT格式对于区间内无key查询效率比TK格式稍差 —— 因为需要扫描完时段所跨分区的全部数据；PKT格式对于给定key检索效率比KT稍差 —— 因为需要在时段所跨越的每个分区内，依次扫描该给定key的对应数据。但PKT格式能兼顾两类查询，且性能损失不大。

Hummer TimeSeries DB Dock DEMO 介绍文章和下载见  http://blog.csdn.net/kanghua/article/details/44653149