1 .基础1.1时序数据的定义时序数据(Time Series Data，TSD，以下简称时序)是指从定义上来说，按每个时间维度被索引的一系列数据。 用描述性的语言说明什么是时间序列数据，简单来说，这样的数据记述了某个测量对象主体在某个时间范围内的各时间点的测量值。 它普遍存在于IT基础设施、运维监控系统、物联网中。
对时间序列数据建模包括三个重要部分：主体、时间点和测量。 应用该模型，可以发现在日常工作中，随时都会接触到这样的数据。
如果你是股东，某个股票的股价是时间序列数据，记录着该股票各时刻的股价。
如果你是运输业者，监视数据就是一种时序数据，例如对机器的CPU的监视数据记录各时刻机器的CPU的实际消耗值。
时序数据将孤立于时间维度的观测值连成一条线，揭示软硬件系统的状态变化。 的孤立观测值不能称为时序数据，但通过时间线连接大量的观测值，可以研究和分析观测值的趋势和规律。
1.2时序数据的特点1.2.1在时序数据的数学模型上介绍了时序数据的基本概念说明了分析时序数据的意义时间序列数据应该如何保存呢？ 数据的保存必须考虑其数学模型和特点，时序数据当然也不例外。 因此，首先介绍时间序列数据的数学模型和特征。
下图是按一定时间记录某个集群内各机器上各端口出入流量的时序数据，每30分钟记录一次观测值。 这里以图中的数据为例，介绍时间序列数据的数学模型。 (根据时间序列数据库的不同，基本概念的称呼可能会不同，但此处以腾讯CTSDB为准。 ）
measurement :与关系数据库中的表相似的度量数据集
point :与关系数据库中的row相似的数据点
timestamp :表示收集数据的时间点的时间戳；
tag )表示数据的归属、属性，指示由哪个装置/模块产生，一般不随时间变化；
(field )表示指标列、数据的测量值，随着时间平滑变动，无需查询。
如上图所示，该组中数据的度量是网络，每个点由以下部分组成：
时间标记：时间戳
两个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.
1.2.2时序数据特征数据模式：时序数据随时间增加，同维重复取值，指标平稳变化：从上网表数据变化可以看出。
写入：持续高并发写入，无更新操作：时序数据库往往面临百万甚至千万量级的终端实时数据写入，例如移动自行车2017年全国车次仅为千万量级。 但是，数据大多表示设备的状态，写入后不会更新。
查询：按不同维度统计分析指标，且存在明显冷热数据，一般只频繁查询近期数据。
1.3时序数据存储1.3.1传统关系数据库中存在存储时序数据的问题时序数据后，应该存储在哪里？ 首先，我们来看一下传统的关系数据库解决方案在存储时间序列数据时会出现什么问题。
许多人可能认为，在传统关系数据库中添加时间戳列可以用作时间序列数据库。 数据量少的时候也确实没有问题。 但时序数据多由百万至千万级的终端设备生成，写入并发量高，属于海量数据场景。
MySQL在大量时间序列数据的场景中存在以下问题：
存储成本大：时序数据压缩不佳，消耗大量机械资源；
维护成本高：单机系统，上层需要人工分库分表，维护成本高；
写入吞吐量低：单体写入吞吐量低，难以满足时序数据千万级的写入压力；
查询性能差：适合事务处理，海量数据聚合分析性能差。
此外，使用Hadoop eco (Hadoop、Spark等)保存时间序列数据时，还会出现以下问题：
高数据延迟：离线批处理系统，从数据生成到分析，耗时数小时甚至每日；
查询性能差：不能很好地利用索引，依赖于MapReduce任务，查询通常需要很长时间。
您可以看到时间序列数据库需要解决以下问题：
时序数据写入：如何支持每秒写入数千万个数据点。
时序数据读取：如何支持在秒级别分组数以亿计的数据的运算。
成本敏感：海量数据存储带来的是成本问题。 以更低的成本存储这些数据是时序数据库要解决的关键。
1.3.2时序数据库产品的发明都是为了解决传统关系型数据库在时序数据积累和分析上的不足和缺陷，这类产品统一分类为时序数据
库。针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：
存储成本：
利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；
通过预降精度，对历史数据做聚合，节省存储空间。
高并发写入：
批量写入数据，降低网络开销；
数据先写入内存，再周期性的dump为不可变的文件存储。
低查询延时，高查询并发：
优化常见的查询模式，通过索引等技术降低查询延时；
通过缓存、routing等技术提高查询并发。
传统数据库存储采用的都是 B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在 10ms 左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入 B tree 会消耗大量的时间在磁盘寻道上，导致速度很慢。我们知道 SSD 具有更快的寻道时间，但并没有从根本上解决这个问题。
对于 90% 以上场景都是写入的时序数据库，B tree 很明显是不合适的。
业界主流都是采用 LSM tree 替换 B tree，比如 Hbase, Cassandra 等 nosql 。这里我们详细介绍一下。
LSM tree 包括内存里的数据结构和磁盘上的文件两部分。分别对应 Hbase 里的 MemStore 和 HLog；对应 Cassandra 里的 MemTable 和 sstable。
LSM tree 操作流程如下：
数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到 WAL 文件中。
内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。
可以看到 LSM tree 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。但同时也牺牲了读取性能，因为同一个 key 的值可能存在于多个 HFile 中。为了获取更好的读取性能，可以通过 bloom filter 和 compaction 得到，这里限于篇幅就不详细展开。
1.3.4 分布式存储时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。
分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是分片（sharding）问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。
分片方法
时序数据库的分片方法和其他分布式系统是相通的。
哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。
一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有 Amazon 的 DynamoDB 和开源的 Cassandra。
范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有 Hbase。
分片设计
分片设计简单来说就是以什么做分片，这是非常有技巧的，会直接影响写入读取的性能。
**结合时序数据库的特点，根据 measurement+tags 分片是比较好的一种方式，因为往往会按照一个时间范围查询，这样相同 metric 和 tags 的数据会分配到一台机器上连续存放，顺序的磁盘读取是很快的。**再结合上面讲到的单机存储内容，可以做到快速查询。
进一步我们考虑时序数据时间范围很长的情况，需要根据时间范围再分成几段，分别存储到不同的机器上，这样对于大范围时序数据就可以支持并发查询，优化查询速度。
如下图，第一行和第三行都是同样的 tag（sensor=95D8-7913;city= 上海），所以分配到同样的分片，而第五行虽然也是同样的 tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的 tag（sensor=F3CC-20F3;city= 北京）也是一样的道理。
1.4 开源时序数据库介绍 1.4.1开源时序数据库对比目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite，还有Druid等，其产品特性对比如下图所示：
1.4.2 InfluxDB介绍
InfluxDB是一个开源的时序数据库，使用GO语言开发，特别适合用于处理和分析资源监控数据这种时序相关数据。而InfluxDB自带的各种特殊函数如求标准差，随机取样数据，统计数据变化比等，使数据统计和实时分析变得十分方便。
重要概念
influxdb里面有一些重要概念：database，timestamp，field key， field value， field set，tag key，tag value，tag set，measurement， retention policy ，series，point。结合下面的例子数据来说明这几个概念：
name: census
-————————————
time butterflies honeybees location scientist
2015-08-18T00:00:00Z 12 23 1 langstroth
2015-08-18T00:00:00Z 1 30 1 perpetua
2015-08-18T00:06:00Z 11 28 1 langstroth
2015-08-18T00:06:00Z 3 28 1 perpetua
2015-08-18T05:54:00Z 2 11 2 langstroth
2015-08-18T06:00:00Z 1 10 2 langstroth
2015-08-18T06:06:00Z 8 23 2 perpetua
2015-08-18T06:12:00Z 7 22 2 perpetua
timestamp
既然是时间序列数据库，influxdb的数据都有一列名为time的列，里面存储UTC时间戳。
field key，field value，field set
butterflies和honeybees两列数据称为字段(fields)，influxdb的字段由field key和field value组成。其中butterflies和honeybees为field key，它们为string类型，用于存储元数据。
而butterflies这一列的数据12-7为butterflies的field value，同理，honeybees这一列的23-22为honeybees的field value。field value可以为string，float，integer或boolean类型。field value通常都是与时间关联的。
field key和field value对组成的集合称之为field set。如下：
butterflies = 12 honeybees = 23
butterflies = 1 honeybees = 30
butterflies = 11 honeybees = 28
butterflies = 3 honeybees = 28
butterflies = 2 honeybees = 11
butterflies = 1 honeybees = 10
butterflies = 8 honeybees = 23
butterflies = 7 honeybees = 22
在influxdb中，字段必须存在。注意，字段是没有索引的。如果使用字段作为查询条件，会扫描符合查询条件的所有字段值，性能不及tag。类比一下，fields相当于SQL的没有索引的列。
tag key，tag value，tag set
location和scientist这两列称为标签(tags)，标签由tag key和tag value组成。location这个tag key有两个tag value：1和2，scientist有两个tag value：langstroth和perpetua。tag key和tag value对组成了tag set，示例中的tag set如下：
location = 1, scientist = langstroth
location = 2, scientist = langstroth
location = 1, scientist = perpetua
location = 2, scientist = perpetua
tags是可选的，但是强烈建议你用上它，因为tag是有索引的，tags相当于SQL中的有索引的列。tag value只能是string类型 如果你的常用场景是根据butterflies和honeybees来查询，那么你可以将这两个列设置为tag，而其他两列设置为field，tag和field依据具体查询需求来定。
measurement
measurement是fields，tags以及time列的容器，measurement的名字用于描述存储在其中的字段数据，类似mysql的表名。如上面例子中的measurement为census。measurement相当于SQL中的表，本文中我在部分地方会用表来指代measurement。
retention policy
retention policy指数据保留策略，示例数据中的retention policy为默认的autogen。它表示数据一直保留永不过期，副本数量为1。你也可以指定数据的保留时间，如30天。
series
series是共享同一个retention policy，measurement以及tag set的数据集合。示例中数据有4个series，如下:
Arbitrary series number Retention policy Measurement Tag set
series 1 autogen census location = 1,scientist = langstroth
series 2 autogen census location = 2,scientist = langstroth
series 3 autogen census location = 1,scientist = perpetua
series 4 autogen census location = 2,scientist = perpetua
point
point则是同一个series中具有相同时间的field set，points相当于SQL中的数据行。如下面就是一个point：
name: census
-----------------
time butterflies honeybees location scientist
2015-08-18T00:00:00Z 1 30 1 perpetua
database
上面提到的结构都存储在数据库中，示例的数据库为my_database。一个数据库可以有多个measurement，retention policy， continuous queries以及user。influxdb是一个无模式的数据库，可以很容易的添加新的measurement，tags，fields等。而它的操作却和传统的数据库一样，可以使用类SQL语言查询和修改数据。
influxdb不是一个完整的CRUD数据库，它更像是一个CR-ud数据库。它优先考虑的是增加和读取数据而不是更新和删除数据的性能，而且它阻止了某些更新和删除行为使得创建和读取数据更加高效。
更多详细介绍请见：https://www.jianshu.com/p/a1344ca86e9b
---------------------
作者：liukuan73
来源：CSDN
原文：https://blog.csdn.net/liukuan73/article/details/79950329
版权声明：本文为博主原创文章，转载请附上博文链接！
转载于:https://www.cnblogs.com/duanxz/archive/2012/10/09/2716207.html