时序数据库系列

时序数据库-01-时序数据库有哪些？为什么要使用

时序数据库-02-聊一聊时序数据库

时序数据库-03-opentsdb-分布式时序数据库

时序数据库-04-InfluxData-分布式时序数据库

时序数据库-05-TDengine 是一款开源、高性能、云原生的时序数据库 (Time-Series Database, TSDB)

时序数据库-05-TDengine Time-Series Database, TSDB

时序数据库-05-TDengine windows11 WSL 安装实战笔记 docker

时序数据库-06-01-vm VictoriaMetrics 快速、经济高效的监控解决方案和时间序列数据库

时序数据库-06-02-vm VictoriaMetrics install on docker 安装 vm

时序数据库-06-03-vm VictoriaMetrics java 整合

时序数据库-06-04-vm VictoriaMetrics storage 存储原理简介

时序数据库-06-05-vm VictoriaMetrics cluster 集群原理

时序数据库-06-06-vm VictoriaMetrics cluster 集群访问方式

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 时序数据库需要解决以下几个问题：

时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。

时序数据的读取：如何支持在秒级对上亿数据的分组聚合运算。

成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。

1.基本概念

时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

1.1 度量(metric)

监测数据的指标，例如风力和温度。相当于关系型数据库中的table。

1.2 标签(tag)

指标项监测针对的具体对象，属于指定度量下的数据子类别。一个标签(Tag)由一个标签键(TagKey)和一个对应的标签值(TagValue)组成。

例如在监测数据的时候，指定度量(Metric)是“气温”，“城市(TagKey)= 杭州(TagValue)”就是一个标签(Tag)，则监测的就是杭州市的气温。更多标签示例：机房 = A 、IP = 172.220.110.1。

1.3 域(field)

在指定度量下数据的子类别，一般情况下存放的是会随着时间戳的变化而变化的数据。一个metric可支持多个field，如metric为风力，该度量可以有两个field：direction和speed。

1.4 度量值(value)

度量对应的数值，如56°C、1000r/s等(实际中不带单位)。如果有多个field，每个field都有相应的value。不同的field支持不同的数据类型写入。对于同一个field，如果写入了某个数据类型的value之后，相同的field不允许写入其他数据类型。

1.5 时间戳(Timestamp)

数据(度量值)产生的时间点。

1.6 数据点 (Data Point)

针对监测对象的某项指标(由度量和标签定义)按特定时间间隔(连续的时间戳)采集的每个度量值就是一个数据点。1个metric+1个field(可选)+1个timestamp+1个value + n个tag(n>=1)”唯一定义了一个数据点。相当于关系型数据库中的row。

1.7 时间序列(Time Series)

1个metric+1个field(可选) +n个tag(n>=1)”定义了一个时间序列。主要是针对某个监测对象的某项指标(由度量和标签定义)的描述。某个时间序列上产生的数据值的增加，不会导致时间序列的增加。

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分钟的和值、平均值、最大值、最小值等。

例如，当选定了某个城市某个城区的污染指数时，通常将各个环境监测点的指标数据平均值作为最终区域的指标数据，这个计算过程就是空间聚合。

拓展阅读

时序数据库

关于 https://github.com/armink/FlashDB 一个支持键值和时序数据的超轻量级数据库

TiDB TiDB 是一个开源的、云原生的、分布式的、与 MySQL 兼容的数据库，用于弹性伸缩和实时分析。免费尝试 AI 助力的 Chat2Query：

TDengine TDengine 是一个开源的、高性能的、云原生的时序数据库，专为物联网 (IoT)、联网汽车、工业物联网和 DevOps 优化。

时序数据库有哪些？为什么要使用

时序数据库是一种专门用于存储和查询时间序列数据的数据库类型。

时间序列数据是按时间顺序排列的数据点或事件序列，例如传感器数据、日志记录、金融交易等。

时序数据库的设计和优化旨在处理这种类型的数据，并提供高效的数据存储、查询和分析能力。以下是一些常见的时序数据库以及为什么要使用它们的原因：

  1. InfluxDB: InfluxDB 是一款开源的时序数据库，专注于高性能、高可用性和可扩展性。它被广泛应用于物联网（IoT）、监控系统和实时分析领域。InfluxDB 支持SQL查询语言，具有数据保留策略和自动数据压缩等功能。

  2. TimescaleDB: TimescaleDB 是一个建立在 PostgreSQL 之上的开源时序数据库扩展。它提供了对标准 SQL 的支持，同时具备强大的时序数据处理能力。TimescaleDB 可以无缝地集成到现有的 PostgreSQL 生态系统中，适用于需要结合时序数据和关系型数据的场景。

  3. OpenTSDB: OpenTSDB 是一个用 Java 编写的开源时序数据库，特别适用于存储大规模的时间序列数据。它的设计目标之一是处理海量的时间序列数据，并提供高度可扩展的架构。

  4. KairosDB: KairosDB 是另一个基于 Cassandra 的开源时序数据库，专注于存储和查询大规模的时间序列数据。它具有灵活的数据模型，适用于多种类型的应用，如监控、日志记录和分析。

为什么要使用时序数据库：

  1. 高效的时间序列数据处理：时序数据库经过优化，能够更有效地存储和查询时间序列数据。这包括数据的压缩、索引和数据保留策略等功能。

  2. 实时分析和监控：许多应用需要实时监控和分析时间序列数据，如设备传感器数据、网络流量等。时序数据库可以提供实时查询和分析能力，以支持实时决策。

  3. 快速的数据插入速度：时序数据库通常优化了数据的写入速度，因为大部分时间序列数据是连续不断地产生的，如传感器数据。

  4. 数据保留和归档：时序数据库支持设置数据保留策略，允许自动删除旧数据或将其归档到长期存储中，以节省存储空间。

  5. 跨足其他应用领域：虽然时序数据库主要用于时间序列数据，但许多时序数据库也支持标准 SQL 查询，使其能够处理其他类型的数据，如关系型数据。

  6. 可扩展性：许多时序数据库具备良好的可扩展性，可以根据数据量的增长进行水平扩展，以保持性能和吞吐量。

总之，时序数据库在处理时间序列数据方面具有优势，可以提供高效的数据存储、查询和分析能力，适用于各种需要处理时间相关数据的应用场景。

时序数据库的优势？对比传统数据库

时序数据库相对于传统数据库在处理时间序列数据方面具有一些明显的优势。

以下是时序数据库的优势，并与传统数据库进行了比较：

  1. 优化的存储和查询性能：
    • 时序数据库针对时间序列数据进行了专门的优化，可以实现更高效的数据存储和查询，减少了数据的冗余存储。
    • 传统数据库虽然可以处理时间序列数据，但在大规模数据集上可能会遇到性能问题，因为它们的设计更偏向于通用用途。
  2. 高速的数据插入速度：
    • 时序数据库通常采用了各种技术来优化数据的写入速度，以适应实时产生的数据流。
    • 传统数据库可能因为索引维护等原因，在大量数据插入时可能出现性能下降。
  3. 时间相关的索引和聚合函数：
    • 时序数据库提供了针对时间序列数据特定的索引和聚合函数，如时间范围查询、滑动窗口聚合等，使数据查询更加高效。
    • 传统数据库虽然可以进行类似的操作，但可能需要更多的手动优化和调整。
  4. 数据保留策略和归档：
    • 时序数据库通常支持自动的数据保留策略，可以根据时间或其他条件自动删除或归档旧数据，以节省存储空间。
    • 传统数据库也可以实现类似的功能，但时序数据库对于这种需求的支持更为直接。
  5. 处理实时监控和分析需求：
    • 时序数据库被广泛应用于实时监控和分析领域，支持快速查询和实时数据处理。
    • 传统数据库在这方面可能需要更多的优化和调整，以满足实时性要求。
  6. 可扩展性：
    • 很多时序数据库具备良好的可扩展性，可以根据数据规模的增长进行水平扩展，以保持性能和吞吐量。
    • 传统数据库也可以进行扩展，但时序数据库更专注于大规模时间序列数据的场景。

总的来说，时序数据库在处理时间序列数据方面的优势主要体现在其专门优化的存储、查询和分析能力上，能够更好地满足实时数据处理和监控需求。

传统数据库则更适用于通用的关系型数据存储和查询，但可能需要更多的调优来处理大规模的时间序列数据。

选择时序数据库还是传统数据库取决于应用的需求和数据特性。

时序数据库是每一列都是单独的字段吗？和列式数据库的关系是什么？

时序数据库通常使用一种称为”列存储”的技术，但并不意味着每一列都是单独的字段。列存储是一种数据库存储技术，它与传统的”行存储”（也称为行式存储）有所不同。让我们来详细了解一下：

列存储：

  • 在列存储中，数据按列进行组织存储。每个列被单独存储，而不是按照每一行的方式存储。
  • 对于时间序列数据来说，通常会有一个时间戳列和一个或多个测量值列。每个列都会被单独存储，这样可以更高效地操作和查询特定的数据。
  • 列存储有助于减少不必要的数据读取，因为查询通常只需要涉及特定的列。这可以提高查询性能，尤其是在大型数据集中。

行存储：

  • 在行存储中，数据按行进行组织存储。每一行包含记录的所有字段。
  • 传统的关系型数据库系统通常使用行存储，因为它们更适用于复杂的多表关联查询，其中需要检索整个记录的所有字段。
  • 对于时间序列数据来说，如果使用行存储，可能会导致不必要的数据传输和处理开销，因为查询可能只需要涉及时间戳和测量值字段。

时序数据库与列存储的关系：

  • 大多数时序数据库采用列存储技术，因为列存储更适合时间序列数据这种按时间顺序排列的数据类型。
  • 时序数据库将时间序列数据的不同列分开存储，以提高查询性能。例如，时间戳列会单独存储，测量值列也会单独存储。
  • 列存储的优势在于查询效率，特别是在大规模数据集上。时序数据库的列存储技术与传统的关系型数据库中的列存储有一些相似之处，但更专注于时间序列数据的特定需求。

总的来说，时序数据库采用列存储技术，但不是每一列都是单独的字段。它们通过分离时间序列数据的不同部分，以及使用时间索引等技术，实现高效的存储、查询和分析。

参考资料

influxdata 产品

https://blog.csdn.net/ggaofengg/article/details/129344212