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格式能兼顾两类查询，且性能损失不大。