时序数据库是一类专门用于存储和分析时间序列数据的数据库。时间序列数据通常包含时间戳和对应的指标值,用于监控和分析某个目标的变化趋势。时序数据库需要高效存储大量时间序列数据,并支持相关的分析与运算,如聚合、下采样、滚动窗口等。
起源
时序数据库的起源可以追溯到20世纪70年代。随着工业控制和SCADA系统的兴起,人们需要存储和处理大量时间序列数据。这促进了时序数据库的出现。
时序数据库的主要发展阶段包括
-
关系型数据库扩展(1970-2000年)
早期,人们通过在关系型数据库(如MySQL)中添加时间序列支持来实现简单的时序数据管理。这种方式表现不佳,难以处理大规模时序数据。 -
专用时序数据库(2000-2010年)
该阶段出现了许多专门为时序数据设计的数据库,如InfluxDB、OpenTSDB和KairosDB等。这些数据库采用列式存储,专用于海量时序数据的高效管理和查询。 -
云原生时序数据库(2010年至今)
近年来,随着云计算和Docker的流行,云原生时序数据库开始兴起。代表产品有InfluxDB、TimescaleDB和QuestDB等。这些数据库天然运行在云和Docker环境中,可弹性伸缩,更适合现代的分布式架构。 -
规范和生态圈成熟(2015年至今)
OpenMetrics、Prometheus和Grafana等开源项目的出现,促进了时序数据格式和查询规范的统一。生态圈也更加丰富,在集成、可视化和分析领域提供更多选型。
时序数据库经历了从简单扩展到专用数据库,再到云原生时序数据库的演变。随着数据规模的增长和体系架构的变化,时序数据库也在不断演进以适应新的需求和场景。其核心优势在于高效地处理大规模时序数据,这也是其区别于其他数据库类型的关键所在。
概述
时序数据库与其他数据库相比,有以下主要特点
- 专为时间序列数据设计。有丰富的时间序列相关功能,可以在数据库层面进行时间序列分析优化。
- 追求高写入和实时查询性能。需要支持大规模时间序列数据的实时收集与监控。
- 简单轻量级部署。提供简易的单节点版本,易于在容器和云上部署,适合DevOps运维模式。
- 时间戳是一个重要字段。时间戳为时间序列数据的索引,支持快速查询给定时间范围的数据。
- 支持监控和告警。具有实时数据处理和告警能力,可以检测时间序列数据的异常变化并触发告警。
常见的开源时序数据库包括InfluxDB、Prometheus、TimescaleDB和QuestDB等。商业解决方案也有Azure Time Series Insights和Amazon Timestream等。
时序数据库内部实现
时序数据库通常采用以下技术来优化时间序列数据的存储和分析:
- 列式存储:
可以高效压缩时间序列数据并加速聚合分析查询。特别适合时间戳等时间序列字段。 - 数据分区:
通常按照时间戳范围进行分区,支持快速查询给定时间范围的数据。 - 索引优化:
在时间戳和其他维度字段上创建索引,加速查询筛选和聚合。 - 向量化运算:
针对批量时间序列数据进行向量化的运算和压缩,大幅提高计算效率。 - 数据编码:
使用定长或变长编码对时间序列数据进行压缩,减少存储空间占用。 - 滚动和下采样:
支持在数据库层面自动进行数据滚动和下采样,简化数据维护和分析。 - 事件处理:
具有低延迟的数据处理机制,可以实时分析数据变化,触发告警并获取预警信息。
时序数据库和列式数据库
既然时序数据库用到了列式存储来存储数据,为什么不直接用列式数据库呢?
首先,时序数据库和列式数据库都是为特定数据存储场景设计的数据库类型。主要区别在于:
时序数据库:
- 专注于时间序列数据的存储和管理。时间序列数据是按时间顺序记录的一系列数据点。
- 应用场景主要在监控、物联网和运维事件跟踪等领域。
- 核心特征是时间范围查询,支持按时间范围过滤和检索数据。
- 典型的时序数据库有InfluxDB、TimescaleDB、QuestDB和OpenTSDB等。
列式数据库:
- 采用列式存储,将同一列的数据存储在一起。这使得列式数据库可以高效地处理大规模数据。
- 场景广泛,常用于大数据分析、数据仓库和OLAP等领域。
- 核心优势是数据压缩和向量化计算,可进行实时业务分析。
- 知名的列式数据库有ClickHouse、Apache Druid 和Apache Cassandra等。
- 与行式数据库(如MySQL)相比,读写性能更高,更适合数据统计和分析。
时序数据库是一种专业的列式数据库,主要用于时间序列数据。所有的时序数据库默认采用列式存储,但并非所有的列式数据库都适用于时序数据。
两者的比较:
类别 | 时序数据库 | 列式数据库 |
---|---|---|
数据类型 | 时间序列数据 | 各类结构化/半结构化数据 |
核心功能 | 时间范围查询 | 数据压缩与向量化计算 |
场景 | 监控/物联网 | 数据分析/BI |
产品例子 | InfluxDB、QuestDB | ClickHouse、Apache Druid |
时序数据库可以看作列式数据库的一种专业实现,主要面向时间序列数据存储和处理。但列式数据库的应用范围更广,不仅限于时序数据。
从设计目标和功能的角度分析
时序数据库和列式数据库虽然在存储格式上有重合,但在设计目标和功能上有所不同:
时序数据库:
设计目标是高效存储和查询时间序列数据。时间序列数据通常有以下特点:
- timestamps连续且递增。
- 查询以时间范围或间隔为主,需要快速筛选和聚合。
- 数据更新频繁,需要高吞吐写入。
- 常用于监控与报警场景,需要实时性。
因此,时序数据库通常具有以下功能:
- 针对时间戳进行优化,支持快速筛选时间范围的数据。
- 支持时间序列相关运算:下采样、滚动窗口等。
- 内置实时告警和事件处理机制。
- 采用时间序相关的数据模型,如Metric、Tag、Field等概念。
- 重视实时性,追求高吞吐的写入和实时查询。
列式数据库:
设计目标更加广泛,是为任意大规模数据分析和OLAP而生。不局限于时间序列数据。因此,列式数据库通常更注重:
- 数据压缩和查询性能。采用列式存储可以高效压缩数据并向量化运算。
- 更加灵活和强大的查询功能。通常采用SQL,支持各种聚合、JOIN和分析函数。
- 更加丰富的数据类型支持。不限于Metrics和时间戳,可以存储各种结构化和半结构化数据。
- 不一定追求实时性,更侧重离线分析与数据仓库场景。
时序数据库一定采用列式存储,以满足对时间序列数据高效率的读写需求。但是并非所有列式数据库都专注于时间序列数据和实时分析,有更广泛的应用场景。时序数据库可以看作列式数据库的一个子集,在此基础上进行专业化优化。因而,并非所有的列式数据库都能完全替代时序数据库,两者可以结合使用,以发挥各自的优势。
两者的优势对比
列式数据库和时序数据库各有优势,是否可以相互取代主要取决于具体场景和需求。
列式数据库的优势:
- 数据压缩和向量化运算,读写性能远超传统数据库,更适合BI和数据分析。
- 通用性更强,可以存储各种结构化、半结构化数据,不限于时间序列数据。
- 生态更丰富,在数据建模、可视化和ML方面有更多选型。
时序数据库的优势:
- 专为时间序列数据设计,有更高的存储效率和查询性能。
- 内置时间序列相关功能,如间隔、降采样、缩放等,更易于时序数据管理。
- 针对监控和IoT场景进行了优化,可实现实时告警和事件处理等。
所以,如果系统只涉及大规模时间序列数据的存储和分析,时序数据库可能更合适。它可以提供更高的性能和更丰富的时间序列支持。
但如果需要复杂的多维数据分析,或者时序数据仅是数据的一部分,列式数据库会更好。它可以提供一个统一的存储和计算平台,不会被时序数据的限制。
因此,两者可以相互补充,而不是完全取代:
- 列式数据库可以通过添加时间序列功能,在部分场景下替代时序数据库。例如InfluxDB和TimescaleDB就是在此基础上发展而来的。
- 时序数据库也在不断提高通用性,增加对非时序数据的支持,以扩展其应用范围。如QuestDB可以存储各类事件数据。
- 在复杂场景下,最佳方案是将两者结合,利用各自的优势。例如使用列式数据库进行综合分析,再将时序数据导入列式数据库进行专业管理。
列式数据库和时序数据库各有特性,可以在部分场景下相互取代,但更理想的方式是结合使用,发挥各自的优势。这可以获得更高性能、更广范围的数据存储和分析能力。
时序数据库采用列式存储主要有以下优势:
-
压缩率高,节省空间。
时序数据通常包含大量相同或相似的数据,特别是timestamps字段。采用列式存储可以对这些字段进行高效压缩,节省大量存储空间。 -
查询性能高。
列式存储可以轻易筛选和聚合相同的字段,加速查询。时序数据库的查询通常也是在相同的字段上进行,如按时间范围或标签值过滤数据。列式存储可以通过向量化运算高效完成这些查询,性能远超行存储。 -
写入性能高。
列式存储只需要将新插入的数据依次追加到对应列的末尾,写入效率很高。时序数据库通常要求高吞吐的插入,以支持大规模的时间序列指标数据,列式存储可以满足这一要求。 -
支持时间序列相关函数。
列式存储可以高效实现时间序列相关的功能,如下采样、滚动窗口等。这些功能需要访问相邻的时间序列数据,列式存储可以直接读取相应的列,而不需要扫描全部行。大大加速这些时间序列运算。 -
SSD友好。
列式存储只需要顺序读写每个列,容易利用SSD的高吞吐特性。SSD的随机访问性能较差,但顺序读写能发挥最高性能。这与时序数据库在SSD上的部署需求不谋而合。
列式存储天然适合存储和分析时间序列数据。它可以高效压缩和查询时间序列,加速时间序列相关的计算,并且性能在SSD上最优。这使得它成为时序数据库的理想选择。时序数据库通过采用列式存储,可以显著超越基于行存储的关系型数据库,成为大规模时间序列数据管理的首选方案。
附录
列式数据库的起源可以追溯到20世纪70年代。随着数据规模的 exponential 增长,传统的行式数据库难以高效存储和处理大数据。这催生了列式数据库的出现。
列式数据库的主要发展历程包括:
-
象形文字数据库(1970-1990年)
早期的象形文字数据库如IMS已经采用了类似列式存储的格式来压缩数据和加速读取。但其查询功能受限,难以普及。 -
网状数据库(1990-2005年)
Sybase IQ和Vertica等网状数据库引入了更明显的列式存储格式和向量化运算,大幅提高了分析查询性能。但其 Florida 许可证费用高昂,用户基础有限。 -
开源列式数据库(2005年至今)
开源项目的兴起使列式数据库得以快速普及。代表作包括:
- Infobright(2005): MySQL的列式版本,性能较高但社区活跃度低。
- MonetDB(2004): 学术项目,功能强大但部署复杂,用户量较小。
- Apache Pinot(2013): 旨在实时OLAP分析,主要用于LinkedIn内部。
- Apache Druid(2011): 面向OLAP分析,已在eBay、PayPal和百度广泛使用。
- ClickHouse(2016): 功能强大,性能高效,已经成为最流行的开源列式数据库之一。
- 云原生列式数据库(2010年至今)
云计算和Docker的流行使新一代的云原生列式数据库成为可能。代表产品有Snowflake、Rockset和TimescaleDB等,更易于在云上弹性伸缩,采用Serverless架构,无需运维。
列式数据库自20世纪70年代起步以来,经历了几代产品的演进,目前已经成为海量数据存储和分析的主流选择。其核心优势在于采用列式存储和向量化运算,可以高效压缩数据并加速读查询,大幅超越传统的行式数据库。