1 .基本概念
时间序列数据库(Time Series Database )是专门用于存储和管理时间序列数据的数据库。 时序数据库特别适用于物联网设备监控和互联网业务监控场景。
这里介绍了时间序列数据库的一些基本概念。 不同的时间序列数据库的称谓略有不同。
1.1度量(metric ) )。
监视风力和温度等数据的指标。 相当于关系数据库的表。
1.2标签(tag ) )。
项目监测的具体对象属于指定衡量标准下的数据子类。 标记(Tag )由标记键)和相应的标记值)组成。
例如，在监测数据时，指定的度量是“气温”，“城市TagKey )=杭州TagValue”是标签) Tag )，用于监测杭州市的气温。 更多标签示例：机房=A，IP= 172.220.110.1。
1.3域(字段) )。
指定度量下的数据子类别通常包含随时间戳变化而变化的数据。 一个metric可以支持多个字段。 例如，metric是风力，该测量可以有两个字段： direction和speed。
1.4测量(值) )。
56、1000r/s等测量值。 如果有多个字段，则每个字段都有对应的value。 不同的字段支持不同数据类型的写入。 在同一字段中写入某个数据类型的value后，不能在同一字段中写入其他数据类型。
1.5时间戳(Timestamp )。
数据(测量值)发生的时刻。
1.6数据点(数据点)。
为受监控的指标(由测量和标签定义)在特定时间间隔(连续时间戳)收集的每个测量都是数据点。 一个metric 1一个字段(可选；一个timestamp 1一个value n个tag ) (n=1)唯一定义一个数据点。 相当于关系数据库的row。
1.7时间序列)。
时间序列由一个metric 1一个field (可选n个tag ) n=1)”定义。 主要是对某一被监测指标(由测量值和标签定义)的描述。 在某个时间序列上产生的数据值的增加与时间序列的增加无关。
例1 )单域)温度的时间序列监测值
“温度”(temperature )作为一个测量值(metric )，共有4个据点，各数据点由以下内容构成。
时间标记：时间戳
三个tag :每个tag都是一个密钥-值对，tag的密钥分别是deivceID、floor和room。
一个字段：温度值
因为其中4个据点使用的metric、tag相同，所以是相同的时间序列。 如图所示：
例2 )多域、单数据源采集)记录一定时间内某集群内各机器上各端口的进出流量，每30分钟记录一次观测值。
网络(Network )作为一个度量(metric )，共有7个据点。 每个数据点由以下部分组成：
时间标记：时间戳
两个tag:host，port表示每个point属于哪个计算机上的哪个端口
两个field:bytes_in、bytes_out表示piont的测定值，是30分钟以内的出入流量的平均值
相同的host、相同的port，每30分钟产生一个point，随着时间的变化，field(bytes_in，bytes_out )也变化。
例如，在host:host4，port:51514，timestamp从02:00到02:30的时间段内，bytes_in从37.937上升到38.089，bytes_out为2897.
例3 )多域、多数据源采集：两个监测风力域(speed和direction )的监测数据、监测数据来自不同的传感器
风力(wind )作为一个度量，共有2个时间序列、8个据点。 每个数据点由以下部分组成：
三个tag:key分别是传感器、city和province。 为了表示将风向(direction )数据上传到广东省深圳市的传感器编号95D8-7913，将该数据点的tag设定为sensor=95D8-7913、city=深圳、province=广
风向(direction )和速度(speed )两个域分别来自不同的传感器。
如图所示，如果metric、field和tag相同，则使用相同的时间序列。
以metric field格式保存数据的优点在于，可以按同一时间顺序合并查询。 以上图为例，要研究1467627246000-1467627249000小时内风力(wind )的状况，可以联合研究多个字段中的值
到下图的数据。1.8 时间精度
时间线数据的写入时间精度——毫秒、秒、分钟、小时或者其他稳定时间频度。例如，每秒一个温度数据的采集频度，每 5 分钟一个负载数据的采集频度。
1.9-1 数据组(Data Group)
可以按标签这些数据分成不同的数据组。用来对比不同监测对象(由标签定义)的同一指标(由度量定义)的数据。
例如，将温度指标数据按照不同城市进行分组查询，操作类似于该 SQL 语句：select temperature from xxx group by city where city in (shanghai, hangzhou)。
1.9-2 聚合( Aggregation)
可以对一段时间的数据点做聚合，如每10分钟的和值、平均值、最大值、最小值等。
例如，当选定了某个城市某个城区的污染指数时，通常将各个环境监测点的指标数据平均值作为最终区域的指标数据，这个计算过程就是空间聚合。
2.应用场景
2.1系统运维和业务实时监控
在业务服务器上部署各种脚本客户端，实时采集服务器指标数据(IO指标、CPU指标、带宽内存指标等等)，业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等)，很显然，这些数据都是时间序列相关的。客户端采集和实时计算之后会发送给哨兵服务器，哨兵服务器会将这些数据进行存储，并实现实现监控和分析的展现，供用户查询。
如下图所示，用户可以登录哨兵系统查看某台服务器的负载，负载曲线就是按照时间进行绘制的，带有明显的时序特征：
2.2 物联网设备状态监控存储分析
在可预知的未来3~5年，随着物联网以及工业4.0的到来，所有设备都会携带传感器并联网，传感器收集的时序数据将严重依赖TSDB的实时分析能力、存储能力以及查询统计能力。
上图是一个智慧工厂示意图，工厂中所有设备都会携带传感设备，这些传感设备会实时采集设备温度、压力等基本信息，并发送给服务器端进行实时分析、存储以及后期的查询统计。除此之外，比如现在比较流行的各种穿戴设备，以后都可以联网，穿戴设备上采集的心跳信息、血流信息、体感信息等等也都会实时传输给服务器进行实时分析、存储以及查询统计。
PS：阿里云拥有自主研发的时序数据库产品 TSDB ，此产品在阿里内部磨练多年， 历经多次双十一高严苛场景的功能和性能验证， 在应用监控，服务器资源监控，数据库监控， 智慧园区设备监控，以及盒马新零售边缘设备监控都有丰富的落地使用场景 ，覆盖了阿里集团80%以上的时序监控业务。
3.基本特点
时序业务和普通业务在很多方面都有巨大的区别，归纳起来主要有如下几个方面：
3.1 持续产生海量数据，没有波峰波谷
举几个简单的例子，比如类似哨兵的监控系统，假如现在系统监控1w台服务器的各类指标，每台服务器每秒采集100种metrics，这样每秒钟将会有100w的TPS。再比如说，现在比较流行的运动手环，假如当前有100w人佩戴，每个手环一秒只采集3种metrcis(心跳、脉搏、步数)，这样每秒钟也会产生300w的TPS。
3.2 数据都是插入操作，基本没有更新删除操作
时序业务产生的数据很少有更新删除的操作，基于这样的事实，在时序数据库架构设计上会有很大的简化。
3.3 近期数据关注度更高，未来会更关注流式处理这个环节，时间久远的数据极少被访问，甚至可以丢弃
这个很容易理解，哨兵系统我们通常最关心最近一小时的数据，最多看看最近3天的数据，很少去看3天以前的数据。随着流式计算的到来，时序数据在以后的发展中必然会更关注即时数据的价值，这部分数据的价值毫无疑问也是最大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景，报警时效性越高，对业务越有利。
3.4 数据存在多个维度的标签，往往需要多维度联合查询以及统计查询。
时序数据另一个非常重要的功能是多维度聚合统计查询，比如业务需要统计最近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少，这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高，但对查询聚合性能有比较高的要求。
4.TSDB核心特性
总结起来TSDB需要关注的技术点主要有这么几个：
4.1 高吞吐量写入能力
这是针对时序业务持续产生海量数据这么一个特点量身定做的，当前要实现系统高吞吐量写入，必须要满足两个基本技术点要求：系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解，单机肯定是扛不住的，系统必须是集群式的，而且要容易加节点扩展，说到底，就是扩容的时候对业务无感知，目前Hadoop生态系统基本上都可以做到这一点；而LSM体系结构是用来保证单台机器的高吞吐量写入，LSM结构下数据写入只需要写入内存以及追加写入日志，这样就不再需要随机将数据写入磁盘，HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。
4.2 数据分级存储/TTL
这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中，将最近天级别的数据放到SSD，更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。
4.3 高压缩率
提供高压缩率有两个方面的考虑，一方面是节省成本，这很容易理解，将1T数据压缩到100G就可以减少900G的硬盘开销，这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中，比如最近3小时的数据是1T，我现在只有100G的内存，如果不压缩，就会有900G的数据被迫放到硬盘上，这样的话查询开销会非常之大，而使用压缩会将这1T数据都放入内存，查询性能会非常之好。
4.4 多维度查询能力
时序数据通常会有多个维度的标签来刻画一条数据，就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题，这个问题通常需要考虑位图索引或者倒排索引技术。
4.5 高效聚合能力
时序业务一个通用的需求是聚合统计报表查询，比如哨兵系统中需要查看最近一天某个接口出现异常的总次数，或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max，问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合，要知道统计的原始值可能因为时间比较久远而不在内存中哈，因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合，就是在数据写进来的时候就完成基本的聚合操作。
未来技术点：异常实时检测、未来预测等等。
5.传统关系型数据库存储时序数据的问题
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。
5.1 MySQL在海量的时序数据场景下存在如下问题：
存储成本大：对于时序数据压缩不佳，需占用大量机器资源；
维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；
写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；
查询性能差：适用于交易处理，海量数据的聚合分析性能差。
5.2 使用Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题：
数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；
查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。
5.3 时序数据库需要解决以下几个问题：
时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。
时序数据的读取：如何支持在秒级对上亿数据的分组聚合运算。
成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。
6.时序数据库发展简史与现状
目前，DB-Engines把时间序列数据库作为独立的目录来分类统计，下图就是2018年业内流行的时序数据库的关注度排名和最近5年的变化趋势。
参考文档：