深入浅出时序数据库 – 智能互联系统基础设施-阿里云开发者社区

概述

未来遍布智能、互联产品的数字世界，时序数据将无处不在，IDC预测，全球联网物联网设备产生的数据将从2019年的17.3 ZB增长到2025年的73.1 ZB^[1]，其中绝大多说时带有时间戳的时序数据，这些数据是驱动企业产能升级，政府服务民生能力提升的关键。因此，面向海量时序数据存储、检索和分析技术及产品将成为支撑未来数字世界的关键基础设施。

时间是在监控一切可以观察的事物过程中不可或缺的维度。随着联网和移动设备的增长以及存储成本的降低，对时间序列数据库的需求在过去十年中快速增长。企业、政府越来越有兴趣分析这些数据以获得有价值的信息，并做出数据驱动的可靠决策。近几年信息技术的进步提高了收集、存储和分析时间序列数据的效率，从而增加了使用这些数据的需求。

什么是时序数据？

简单的说，时序数据就是带有时间戳的任何数据元组集合，且时间是对其他数值有意义的。真实场景时序数据包括股票交易数据、监控指标数据等。时序数据是对实体对象状态或生成的事件在时间维度的跟踪、监控、测量、降采样或聚合，这些数据包括多IT基础设施、汽车、飞机、工业设备的监控，应用性能监控（APM），网络性能监控，传感器数据、告警通知事件，用户点击行为，市场交易和分析数据。

“时序数据区别于其他数据的主要特征是：时序数据总是以时间维度为基准被检索。” -Gartner^[2]

通常采集到的时序数据有两种形式：周期数据和非周期数据。周期时序数据包括在指定频率周期（每n秒一次）采集的数据，比如从智能设备、传感器以特定时间间隔定期采集的数据。非周期时序数据通常是事件驱动的，可能是用户或外部触发事件产生的数据，比如点击事件流或来自用户与Web页面交互产生的数字足迹数据。对非周期数据的统计可以将其转换为周期时序数据。总的来说，时序数据集主要特点主要有：

新写入数据总是被存储在最快的访问区域。
旧数据通常不允许被修改（包括更新、删除）。
数据通常是以时间顺序排列存储。
所有数据都带有时间戳。

什么是时序数据库？

时序数据具有随时间渐逝、海量、高并发写的特点，因此需要在存取数据时特殊处理，时序数据库就是针对时序数据存取而特别设计的一类数据库。为了保障数据存储能力能够随数据累积量增加线性扩展，以适应黑盒交易（又称为算法交易、自动交易）、高级时序数据分析和异常趋势检测等场景的需要，时序数据库通常需要围绕时序数据特点全新的架构设计才能满足需要。

时序数据库对高通量时序数据存储做了特殊优化，通常采用的设计策略是基于能够快速写入海量数据的列存储模型设计。这些系统在快速写入的情况下，允许丢失部分数据，因为这些数据主要支撑的应用场景为监控，聚合计算指标查看趋势生成事件，不需要非常强的数据完整性保障。

技术特点

根据与其他类型数据库使用场景和关键技术对比，我们总结出以下四点时序数据库独有的技术特点：

时序数据库主要解决2个关键问题：1、非对称读写能力，提供快速海量数据写入和持久化；2、提供相比其他数据库更高效的时序数据读取能力。
对于时序数据库，存储空间使用效率非常关键，要以尽量小的存储空间支持监控数据存储，时序数据库数据存取成本优化极为重要。
针对时序数据模型特别设计研发的时序数据库会比基于通用型数据库（Hbase、Postgres等）具有更优秀的性能和可扩展性。
时序数据库为具备时间戳的数据存储和统计分析专门设计，对于其他类型数据并不适用。

应用场景

对于企业大多数时序数据存储分析应用场景，应用开发人员及数据科学家使用时序数据库应该遵循以下原则判断：

选择时序数据库需要考虑数据库数据存储、单节点、多节点集群架构以及查询能力（尤其是时序数据量和指标数量），数据可靠性，存储成本，数据写入和检索性能。
根据数据写入吞吐量、读取延迟和并发性的域要求，对时间序列数据库供应商进行仔细评估。市面上没有能够同时满足高速写入和低延迟、高度并发查询要求的完美时间序列数据库。
仔细研究评估查询时间序列数据库的利弊，因为有些数据库不支持或不能完全支持ANSI SQL。当希望将时间序列数据库连接到业务智能和数据可视化工具时，需要仔细评估双方的接口标准兼容性和检索能力。

从实际需求出发，时序数据库最主要的应用场景有以下几项：

物联网（IoT）：在机器对机器通信的IoT网络，绝大多数物联网传感器采集的数据为代时间戳的时序数据。物网时间序列数据库能够从设备捕获的数据中深入洞察。物联网设备数据通常通过数百到数十万个传感器或指标、高度并发负载下的实时查询以及警报、流处理和以千兆字节到 TB级别的数据进行机器学习。物联网数据的独特之处在于，它以极高的速度生成，并且需要以复杂的方式快速可靠地进行分析。
IT基础设施/应用系统监控：随着从单一结构向基于微服务的架构的转变，服务可靠性工程师（SRE）或DevOps 团队收集和需要实时监控的指标数量呈指数级增长。这是需要收集、存储和分析以发现使用模式趋势异常的所有时间序列数据。时间序列数据库为此类数据提供了理想的功能。
运营时序数据分析：分析来自零售、营销、广告和运输等的时间序列数据，可以快速识别趋势和定价，帮助企业提取有意义的统计数据和其他特征。
金融时序数据分析：金融场景下对高频交易时序数据、时间序列财务数据分析使用户能够更好地了解市场，提高企业生产质量预测的能力。

具备高性能、高可扩展性的大规模时序数据库正在成为企业数字化和工业 4.0 转型的关键组成部分。一些已建立的时间序列数据库正在增强其跨多维数据（可扩展性、性能和 SQL 支持）的能力，并与 BI 工具和其他企业和分析工具结合，形成系统化的完整解决方案。

目前，客户围绕业务场景选择时序数据库，除了市场上现有开源、商业版的on-premise私有化部署时序数据库（openTSDB、TimescaleDB、InfluxDB等）软件外，在云原生应用场景下，云服务提供商还通过阿里云、微软Azure 云的时间序列洞察和亚马逊AWS时间流数据处理、存储能力进入此市场。形成这种竞争格局的主要原因有以下几方面：

进入物联网市场的云供应商希望通过为时间序列数据提供最佳存储，整合其物联网平台和服务，形成更完整的数据洞察方案。
原有将时间序列数据存储在非原生时间序列模型数据存储中的方案无法满足快速增长的时序数据存储需要，会导致数据写入、检索与读取的性能不匹配，不能有效处理海量时间序列数据，分析、统计效率低性能差。

时序数据库深入浅出

时间序列数据库包含典型数据存储中的所有组件，时间序列数据库体系结构中的写入层优化了数据模型，这些数据模型因供应商而异，以最好地表示传入的数据。存储、查询和数据模型层在文档的详细信息部分进行了广泛的讨论。图 1 展示了时间序列数据库的整体体系结构设计。

数据采集系统用于从多个数据源中写入高速数据，这些数据源具有 UDP、TCP 或 HTTP 和接口等多种协议。
存储层负责将数据存储在正确的格式中，与本地供应商为存储数据而实现的相关数据模型配合使用。存储层还包括压缩、缓存、索引和元数据存储。
元数据组件存储相关元数据，主要用于数据库引擎的内部簿记。此元数据层不暴露在数据库的最终用户中。数据库引擎内部使用元数据进行查询优化和数据验证。

图 1 时间序列数据库通用体系结构设计

体系结构中存储子系统的索引组件是可选的配置，主要为加速检索时序数据构建快速检索索引。相比其他类型的业务数据，对高速写入的时序数据建立索引成本会更高。由于设计初衷不同，时序数据库选择的索引构建策略也有所差别，常见的策略有inverted index、radix trees、LSM（Log Structured Merge）trees和TSM（Time Structured Merge）trees。

存储子系统缓存组件主要设计用来提升检索性能，屏蔽一部分磁盘等永久存储I/O，节约数据从磁盘空间反序列化处理成本。
存储子系统元数据模型组件定义了存储引擎内部管理时序数据的数据模型，为其他子系统屏蔽底层数据存储形式。
存储子系统检索层提供了检索已存储数据的能力，通常需要提供SQL、自定义专用语言、函数、接口调用等多种范式的脚本语言支持能力。支持SDK、APIs接口方式实现用户与数据库的交互。

时序数据库常见类型

根据底层数据存储实现的差异来划分，市场上常见的时序数据库可以被划分为如表1所示五大类：

表1 时序数据库类型和主要厂商

面向特定场景的历史数据库：常见于物联网和工业制造领域，例如运维历史数据库，被设计用来快速写入大量传感器数据，并集成于数字化生产管理过程中提供实时过程监控，支撑仪表盘大屏指标展现。但是，随着实时数据处理和大数据处理技术快速发展，运维历史库对于高并发写入和读取场景下性能逐渐达到瓶颈。运维历史库为存储检索工业设备产生的数据而专门设计，未考虑在数据快速增加时需要的分布式架构部署、实时数据处理和对接机器学习和AI算法等高级数据分析系统等需求。
构建于文件存储系统和非关系数据库之上的时序数据库：设计重点权衡数据库分布式部署、高可扩展性设计，这些数据库在存储时序数据同时支持结构、无结构数据的存储，数据的schema定义比较灵活。
构建于关系数据库之上的时序数据库：通过改造、优化现有关系数据库，使之适用于时序数据存储。这些时序数据库通常需要在关系数据库引擎之上构建抽象层以适配时序数据，需要在上层定义额外的schema和数据索引。
基于专有架构全新设计的时序数据库：这类专有架构设计的原生时序数据库通常专门用来存储、分析时序数据，从存储层到检索、索引、查询接口都基于时序数据特点专门设计，兼顾高并发写、分布式部署和多模态脚本语言检索等特点。
云端云原生时序数据库：云端时间序列数据库主要以云原生方式提供，其定价策略和产品形态仍在演进过程中。这种时序数据库成本取决于写入的数据字节数、查询次数、存储类型（容量/性能云盘等）、数据保留时间、查询复杂性和其他参数。未来，工业场景时间序列存储会使用非常大容量的数据，每秒写入千万，甚至上亿时间点，运行数千次查询，云原生时序数据库可为此场景提供近乎无限的性能扩展能力和超高数据可靠性保障支撑。

以下分析了常见类型时序数据库主要优劣势:

a) 面向特定场景的历史数据库

优势

20年前技术构建，已在能源、制造行业使用较长的时间（某些电网、电厂客户生产部署近30年），因此技术成熟。
更适合部署在专用的.NET/Windows等服务器上(为对接OPC DA/HA协议接口)。

劣势

技术过时，只能利旧使用现有硬件和软件许可授权
非常适合 IoT 架构的运维技术（OT，Operation Technology）部分
专有技术，这可能会限制其处理平台中海量异构数据的能力
难以与其他类型数据库能力对接整合
分析能力有限，例如，可能不支持 JSON 格式

b) 基于NoSQL的时序数据库

优势

数据高压缩比有助于时间序列数据存储
更好的写入性能和线性扩展能力

劣势

缺乏 SQL 接口
管理和运维复杂的、成本高
二级索引构建能力受限
复杂的谓词可能难以处理
不支持多表Join连接操作

c) 基于关系数据库的时序数据库

优势

支持二级索引
轻松支持复杂的谓词
无缝对接SQL 接口
可以很容易地将存储在同一数据库中的相关数据切片或与数据检索结果关联

劣势

集群依赖关系数据库，相对困难
数据压缩比低，存储成本高
并发写能力有限
时序数据聚合等计算困难

如何选择时序数据库

当我们针对目标业务场景分析时序数据管理需求，评估该用哪种时间序列数据库时，需要考虑几个因素。图2在选择时间序列数据库时显示了一些架构考虑因素。

图2 时序数据库架构设计需要考虑的关键特性

评估时间序列数据库遵循的原则主要有以下几点，需要我们首先调研清楚应用场景范围、技术需求和数据特性。

数据量和写入速度：了解需要存储多少数据以及数据量增长的速度。确保所选数据库能够与数据吞吐量和速度进行扩展，并且不会在数据被摄入时丢失数据。选择数据量增长时提供自动伸缩功能的数据库。
数据存储模型：从灵活性和扩展模板的易用性以及添加新索引的角度研究基础时间存储的数据模型。对于广泛的工业时间序列分析，通常需要动态计划、文本搜索和用户定义的功能。
查询语言支持：大多数时间序列数据库不支持完全合规的 ANSI SQL。查看查询灵活性、执行搜索的能力、SQL 连接、用户定义的查询、子选择、异常检测、地理空间、窗口功能和 CTE。选择一个数据库，查询语言可以简化序列选择、连续查询功能和查询数据的转换。有些数据库与最近的数据具有更好的性能，而有些数据库在历史数据聚合方面表现更好。仔细分析时间序列数据库的功能，以提供高级时间序列分析功能（间隙填充、插值等）。
数据类型支持：您的数据是定期间隔还是不规则间隔？了解域所需的数据类型，因为某些时间序列数据库对字符串、Boolean 或嵌套数据类型没有很好的支持。
数据读写性能：时序数据库性能很大程度上和写入数据类型和方式相关。每个解决方案都有其优点和缺点，根据具体开发需要的工作量、吞吐量、延迟、并发性和查询的复杂性执行基准测试，了解性能特征至关重要，因为该序列的基数会随着时间的流和较高的并发性而增加。
操作管理功能：如果要部署的是基于工业物联网的操作数据库，例如自动监控、自动备份和点时恢复，则必须进行自动升级、维护和自动数据保留策略。
第三方系统集成能力：仔细评估数据库如何与外部摄入和数据访问工具和平台（尤其是 BI 工具）进行接口和集成，并与Prometheus、Grafana和 Telegraf 等工具兼容，实现摄取和可视化。
产品版本：仔细评估数据库开源版本和企业版本的能力差异和区别，InfluxDB等企业版和开源版功能差别会导致适用场景有所不同。
扩展功能：在选择之前了解应用负载变化情况，了解数据存储的纵向扩展（在同一节点上）和横向扩展（跨越多个节点）功能。通常，对于持续增加的工作负载，我们需要考虑数据库扩展能力，评估其是否可随着数据的增长而扩容，并在支持数据过期时删除数据节点，从而提供无宕机弹性扩展能力。

时序数据库优劣势总结

从数据库整体能力来看，相比其他类型数据库时间序列数据库的优点如下：

大多数时间序列数据库可以在各种摄入协议和数据传输机制中摄入高速时间序列数据。这对于在各种数据源中提供更广泛的集成功能非常重要。
支持多种压缩功能，以减少对物理存储空间的占用，这对于加快数据扫描以支持较低的查询延迟非常重要。
支持同一数据库中的常规和非常规时间序列数据，这允许将时间序列数据用于多用途使用案例。
时间序列数据库在许多记录中优化大规模数据扫描。它们通过面向列的存储和预聚合，以实现更好的查询性能。
某些时间序列数据库具有数据生命周期管理流程，可以随着数据老化而处理数据。这可以包括将旧数据聚合到更高级别的细节，以及创建数据保留策略。

以下是市场上时间序列数据库的一些弱点总结，在选择时序数据库时应尽量考虑规避：

时间序列数据库供应商尚未标准化用于查询时间序列数据库的语言。建立在关系数据存储之上的数据库具有 SQL 支持，而其他专有或建立在非相关数据存储之上的数据库则没有 SQL 支持。
某些数据库（如 Apache Druid）不支持毫秒级以上的粒度，这可能对某些应用造成限制。
与生态系统之外的时间序列分析工具的集成有限，尤其是 BI 工具和其他摄入工具。
某些数据库仅限于单节点，并且多节点功能仅适用于企业版本。
一些时间序列数据库不太善于处理高基数数据，并且对大型基数表现出较高的查询延迟。
确定性能/吞吐量和并发性的最佳配置设置可能比较棘手。
不支持跨度量加入的数据库可能非常有限，并可能妨碍提供统一报告功能的查询功能。

时序数据库应用评估指南

以下部分为希望使用时间序列数据存储来提供数据管理解决方案的技术专业人员提供使用指导。时间序列数据有两种形式：一种是可以存储传统常规定周期指标的，另一种是可以存储不定期产生事件的指标。时间序列数据库（如Graphite、RRD（Round Robin Database）和 OpenTSDB）仅支持常规时间序列指标。但是，对于这两种类型的数据，像InfluxDB这样的现代时间序列数据库都针对性地进行了优化。按照上一节中概述的准则选择时间序列数据库的同时，一些客户还需要存储时间序列数据的同时在时序数据上执行文本全文检索、图片视频等文件存储、图计算处理。对于此类客户，建议使用具备多模数据存储检索能力的数据库，比如阿里云云原生多模数据库Lindorm、原生多模数据库ArangoDB^[3]。在选择时间序列数据库之前，我们可以遵循以下步骤：

了解需要存储的目标场景所产生的时序数据的特征。
评估读/写吞吐量和查询延迟要求，特别是在进行选择之前，在选定的数据库中并发工作负载。
通过添加更多节点，确保数据库从存储和查询性能角度逐步扩展。
在集成 BI 或分析工具之前，了解这些数据库的查询功能和界面。
确保支持更改粒度、按时间跨度分组或执行自动回归综合移动平均线（ARIMA）时间序列分析等功能。

没有一个时间序列数据库适合每一个用途，并支持所有功能。拥有企业就绪绩效是企业采用准备的关键步骤。你应该为你的团队做好准备。在选择开源或商业时间序列数据存储时，需要考虑许多因素。您的要求可能与拥有工程和运营人员的大型组织的要求大相径庭。

要充分发挥时间序列数据库的存储优势能力，必须对现有技术团队能力赋能培训，并配备合适的技能组合进行培训。构建正确的技能集，以选择和使用时间序列数据库，并利用其权力与不同的查询连接数据的方式。

在选择解决方案时，运维的复杂性和成本通常被忽略。当选定的时间序列数据库之间其他一切都相等时，主要区别物就会成为操作的效率和整体复杂性。最佳方案是时间序列数据库在需要额外存储或计算时自动上下扩展。

时序数据库关键技术原理

本节深入浅出地介绍时间序列数据库的技术原理和架构设计关键内容，从整体架构和核心系统组件开始，进而深入探讨一些重要组件实现原理和参考设计，比如查询引擎、数据存储、数据索引和数据模型定义等。

架构设计

以时间戳为核心的数据存取，是整个时序数据库平台架构设计的核心。但是，仅仅能够按时查询并不能满足有效和高效的时间序列数据存储的所有要求。为了实现大而精细的时间序列数据的正确可扩展性和可用性，有必要在数据模型、存储系统和检索引擎方面设计一个trade off的组合策略。

时间序列数据库要围绕优化多维时序指标数据快速写、读、聚合、统计等特点，选择技术实现方案，设计系统架构。时间序列数据库需要解决两个根本问题：1、高通量数据写入；2、高并发数据检索读取。数据库处理的每个数据点都要求有时间戳、实际字段值和对映的元数据定义。写入的时序数据点实际字段通常不编入索引，而元数据是需要构建相映索引的。

时间序列数据的实效性格外重要，使得有必要尽可能快地在查询中检索新数据，尽管不是每个点都有业务价值。大多数时间序列数据被归纳为中间值，因为趋势提供的洞察力比单个数据点多。大多数时间序列数据库将数据划分为大块数据，每个区块都有其索引和自己的独立存储模块。这有利于用时间谓词或基于时间的聚合查询。与从磁盘读取相比，筛选器可减少数据扫描，并允许数据库选择优化的计划并在内存中执行计算。它还允许更好地使用哈希聚合等算法与分组聚合。

使用时间序列数据，人们总是会随着时间而提出问题。时间序列查询经常是随着时间的推移的聚合，在一定时间范围内扫描点，然后通过平均、最大或基于窗口的分析功能等摘要函数来减少。时间序列数据应用程序往往倾向于在基于时间维度的窗口查询会生成基于窗口的聚合数据和最新时间窗口数据点查询这两种模式中查询。图3描述了时间序列数据和访问方法中的不同查询类型。

图3 时序数据库常用架构设计

时序数据检索查询技术

时间序列数据有其特定的查询和计算方法，如图4所示大致包括以下类型。

点查询：根据基础数据模型的不同，名称、元数据或位置都可用于查询数据点。通常，时间线需要首先定位，该时间线基于一个或多个元数据字段的组合进行检索。
时间窗口查询：中的大部分范围查询都基于时间维度。范围查询具有开始时间线和结束时间线。一旦找到这些时间线，这些时间线内的数据就是查询。这些时间线的数据可以全部同位或分散在多个分区、碎片或大块数据集中。
聚合/滑窗：数据聚合是读取性能的关键组成部分。聚合可以在摄入期间异步应用，从而允许编写性能优化。聚合是通过在跨越时间间隔的数据上应用聚合函数来完成的。对于多个时间线的范围查询，结果通常会聚合在一起。预计时间序列数据存储将支持简单到复杂的聚合功能，如计数、百分位数和cumulative_sum，这些函数通常需要从原始数据构建数据可视化。
降采样查询：向下采样的逻辑与聚合的逻辑相似。不同的是，向下采样是针对单个时间线而不是多个时间线。向下采样在单个时间线的时间范围内聚合数据点。向下采样的主要目的之一是在大时间范围内显示数据点。另一个是降低存储成本。
时序数据分析：时间序列分析是一个广阔而研究广泛的领域。时间序列数据库可以轻松地用于执行高级时间序列分析，其功能包括检测数据异常、趋势、相似相关性和因果关系。

图4 时序数据库主要数据检索能力示意图

除了上述查询要求外，时间序列还具有其他一些面向具体问题的特定查询需求，例如：

加入或合并两个不同的时间序列合二为一。
重新采样，将高频时间序列聚合到低频时间序列。
修剪以快速删除旧数据。

时间序列数据库中的数据检索引擎通常执行以下步骤来执行查询：

确定查询类型：点/聚合/范围查询。
解析查询：执行语义检查并构建查询计划。
分离过滤数据的时间范围和条件表达式。
使用测量列表和查询时间框架，确定需要访问哪些碎片/块（用于分布式时间序列数据存储）。
指示存储引擎为每个碎片/块创建回发器。
合并在数据上执行后处理的电传输出。这些梯形器嵌套，形成一棵树。自下而上执行读取、过滤和合并数据以生成最终结果集。

时序数据查询优化技术

大多数时间序列数据查询都是聚合、统计后的数据，因为它提供了趋势。时间序列的实时性使得有必要尽快在查询中暴露新数据。优化查询性能需要找到每个序列的初始点，并利用柱存储高效扫描初始点之后的一序列点。时间序列数据库通常以列导向的形式存储磁盘上的数据，从而允许快速聚合。

大多数时间序列数据库自动维护内存索引，从而高效过滤。建立在关系存储之上的时间序列数据库利用其他筛选标准上的次要索引。建立在非相关数据存储之上的时间序列数据存储不可能提供次要索引。可以进一步优化索引，以保持序列草图和测量快速基数估计值。

一些时间序列数据存储支持自动卷起的智能规则，其中缓存和查询低粒度数据，主要是用于从短到长时间帧的仪表板。某些时间序列数据库不会将查询推下到节点，这意味着它必须将整个网络查询的所有数据点拉到查询引擎以执行计算。由于网络和 I/O 瓶颈，这可能导致更大的延迟，并可快速降低并发工作负载。

时序数据检索交互技术

基于关系数据存储的时间序列数据库通常支持基于 SQL 的查询接口。但是，大多数时间序列数据库没有标准查询语言。随着数据基数（Cardinality）的增加，性能可能会急剧下降，具体取决于基础存储架构。使用subselects和通用表表达式（CTE, Common Table Expression）来处理复杂的时间序列计算时，SQL 查询很容易变得非常冗长且复杂。

在选择时间序列数据库查询语言时，需要考虑尽可能使对接的应用方便选择时间序列、执行连续查询和转换查询数据。数据查询引擎应支持启用高级查询，例如将时间序列同时合并拆分，或者即时计算指定时间范围百分位和数据分布。

如果目标应用场景需要高级时间序列分析，则如果支持时间序列分析相关功能，需要在认真评估查询语言和引擎的功能的同时，判断是否可以插入第三方库以支持ML/AI算法辅助的复杂分析查询功能。

时序数据存储模型设计

对时间序列数据库来说，时序数据存储模型是必要基础支撑，该模型可以封装并构建对传入数据如何存储在基础数据存储中的抽象。基于基础存储机制（如表 2 中所示），数据模型是在每个数据点的数据摄入上创建的，然后进行压缩，并发送到存储层。

时间序列数据可以被认为是数据点或图集的一组集合字段。每个数据点都有一个时间戳和与之相关的测量。例如，来自数据库服务器的运行监控指标可能是IOPS、CPU利用率、每秒传输的字节数、接入连接数等。这些数据点还带有有关测量的元数据，比如，生成该序列的完全合格的主机名。目前处于业界领先的时间序列数据库之一InfluxDB使用下面描述的模型。数据点包括四个组件：测量、元数据、字段及带时间戳的数值。

测量提供了一种关联可能具有不同关联元数据或字段的相关点的方法；有关数据点的元数据是要存储的键值对的数据字典描述；字段集是一组写入的按点记录的数据扩展值，字段呗定义为对映测量而定义的多个指标以及与这些指标相关的数值；一组被称为标签集的元数据表示元数据字段和描述正在存储的测量的相应值。

举例来说，对于数据库服务器的指标测量：

SQL Server;IP=72.12.45.124,Location=DC1;BytesSent=32,IncomingConnection=100

监控数据采集对象是SQL Server.
元数据包括 IP, 服务器地点，主键，在标签集合 tagset中被称为 tag keys。对映此序列数据的数值有72.12.45.124 ，服务器地点为 DC1, 在标签集tag_set 中标记为 tag_values.
在field_set 中记录BytesSent=32, IncomingConnection=100，其中键值有BytesSent 和IncomingConnection, 并在 field_set 中被称为 field_keys。数值,32 和100, 在 field_set 中被称为 field_values.

写入原生时序数据库的每个数据点都存储在包含相关存储策略的数据存储层中。一个序列数据被定义为：存储策略+量测值+标签集的组合。更直观的数据模型定义如图5所示。

图5 时序数据模型图示

采用这种模式存储时序数据的主要优劣势有以下几点：

优势：

数据写入并发处理能力极强。
系统扩展性高，支持大规模集群。
高系统稳定性和数据可靠性保障。
如果数据与模型匹配，数据库性能优势明显。
不需要用户定义schema或索引，数据库自动管理。

劣势：

强制执行数据验证可能会比较困难。
缺乏对创建额外其他类型索引的支持。

相比原生时序数据库，另一种基于关系数据库Postgres数据库实现的时序数据库TimescaleDB的数据库模型截然不同。如图6所示，这种数据模型基于关系模型定义，支持40多种数据类型，所有Field和外键都支持索引。

图6 关系数据库时序模型

对于上面给出的例子，用TimscaleDB的数据模型定义可以用图7来描述：

图7 TimscaleDB存储时序数据格式示意图

这种基于关系数据库的时序数据模型优劣势有以下几点：

优势：

每条记录中包含的元数据和数据决定了需要宽表或窄表。
可以根据业务需要选择建立多个索引来加速数据检索，或权衡存储空间简化索引策略。
每条数据中的特有元数据和表级别的独立元数据都允许随时更新。
可以对写入数据做严格的数据schema格式校验。
支持对写入数据做唯一、非空等限制校验。

劣势：

索引创建维护比较复杂。
需要提前对数据schema定义。
需要定义对哪些Field做索引。
物理存储空间占用相对较高。

时序数据存储系统架构

当需要处理从大量分布异构数据源采集、写入数据库存储数据的场景时，选择高性能的时序数据库需要权衡内存存储和永久存储利弊，以支撑低延迟仪表盘展示或实时数据分析等场景的需要。在时序数据库内，新写入的数据记录会被存储在最靠前的区域，以时间顺序排列。为了能支持百万、千万或更高数量级采集指标并发写入能力，存储TB、PB甚至EB级别数据，并以更快的速度检索，存储的设计至关重要。

基于以上需求，首先时序数据库存储需要考虑优化数据模型，以最少的存储空间存储每一点数据，提供高压缩比的数据压缩算法进一步节约物理存储空间占用。大多数的时序数据点在压缩存储后不影响读取。

图8总结了在设计时序数据库底层存储引擎架构势需要考虑的主要因素。

图8 时序数据库存储架构特性

时序数据检索通常会以时间维度来聚合，扫描给定一个时间范围的时间点，并以平均、最大、最小、标准差、滑窗计算函数统计。列存储技术将数据以数据列来组织，数据压缩效果较好，物理存储利用率高，但从列存储删除指定数据成本也相对较高，因此，将数据按时间分块就显得比较必要。当数据定义的生命周期（TTL，Time-To-Live）结束，时间块数据会被整体清除掉，这就免去了大范围检索更新持久化数据删除成本来得低。

大部分时序数据库选择append-only文件存储新写入的时序数据，以保障写入性能。之后，数据文件分批与WAL（Write Ahead Log）日志同步。WAL也是append-only文件格式，在数据恢复过程中才会被用到。为了提升物理存储空间利用率，降低磁盘I/O，WAL中的数据会被分批压缩存储到磁盘中。

WAL设计用来简化数据写入处理，提升写入并发能力，但对数据读取不太友好。为了弥补不足，实现对新写入数据的快速访问，一般会在内存中划出空间建设高速缓存来提升检索性能。如图9时序数据库常用的存储层架构设计方案，WAL保障新写入数据持久化，缓存保障这些数据被检索的性能，但是对需要长期存储的历史数据，这些机制还不够。在数据库重启时WAL会被替换掉，因此，WAL大小需要被限制在合理的范围。