Hummer Time Series DB 数据存储模型

多元(维)时序

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

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

多种排序格式
     -  时序数据处理的主要特征 :   时间断面(区间)上进行精确、模糊、条件检索 —— 例如 : 查找国庆期间查询给定嫌疑人通讯踪迹(精确查询) ; 查春节期间具有“陕A”车牌号字样的进京车辆/总数(模糊前缀查询) ; 查询大年初一北京望京地区用电量最高的电表(地域条件查询);除时间区间上基本检索外,很多场景更需要在时间段面(区间)上进行各种统计分析计算 —— 例如 : 如,总量统计、同比、环比计算等。
针对上述时序数据处理的两大场景 : “区间内个体回放和“区间内统计分析”(前者是在时间区间上进行给定key的检索;后者是在时间区间上进行分析计算),分别设计了KTTK两种针对性存储格式。如果应用场景同时有统计分析和个体回放两类需求,则可使用蜂鸟专有的PKT格式兼顾这两类需求 —— PKT格式属于TK格式和KT格式之间的一种“折中”选择。若场景确定时,优先考虑使用KTTK场格式 —— 比如,侦查员追查嫌疑车辆轨迹,或疑犯的通话记录等场景,属标准的个体回放需求,应优先考虑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

你可能感兴趣的:(数据库,NoSQL,timeseries,数据存储,IoT)