时序数据库

可视化演示

展示时间序列数据点的采样与写入，Prometheus TSDB基于块（block）的存储与压缩，以及降采样策略如何减少数据量。

时序数据库的基本概念与核心定义

时序数据库（Time Series Database，简称TSDB）是专门为存储、查询和分析时间序列数据而设计的数据库系统。时间序列数据是按照时间顺序排列的一系列数据点，每个数据点由时间戳和对应的值组成。与传统关系型数据库不同，TSDB针对时间维度的数据写入和查询进行了深度优化，在高吞吐量写入、高效时间范围查询和海量数据压缩方面具有显著优势。时序数据库的核心理念是：时间是最重要的索引维度，数据的写入模式以追加为主，查询模式以时间范围为主导。

Prometheus是由SoundCloud于2012年开发、2016年加入CNCF的开源监控系统和时序数据库。Prometheus采用多维数据模型，每个时间序列由指标名称（metric name）和一组键值对标签（labels）唯一标识，数据点为浮点数和时间戳的组合。Prometheus内置了自己的TSDB存储引擎，采用基于块的存储格式和Gorilla压缩算法，支持高效的PromQL查询语言。截至2024年，Prometheus是云原生监控领域的事实标准，CNCF调查中超过百分之八十五的云原生团队在使用Prometheus。

InfluxDB是由InfluxData公司开发的开源时序数据库，采用行协议（Line Protocol）写入数据，数据模型由测量（measurement）、标签（tags）、字段（fields）和时间戳（timestamp）组成。InfluxDB使用自研的TSM（Time-Structured Merge Tree）存储引擎，基于LSM-Tree变体实现高吞吐写入和高效压缩。InfluxDB 2.x引入了Flux查询语言和Bucket/Task概念，支持连续查询、降采样和数据保留策略。InfluxData生态还包括Telegraf（数据采集）、Chronograf（可视化）和Kapacitor（告警），形成完整的TICK技术栈。

理解时序数据库需要掌握数据压缩理论（Gorilla压缩、delta编码、位打包）、存储引擎原理（LSM-Tree、列式存储、WAL）和分布式系统知识（分片、复制、一致性）。时序数据库与传统关系型数据库的区别在于：TSDB以追加写入为主极少更新删除、查询以时间范围扫描为主而非随机点查、数据按时间维度自然排序、强调写入吞吐量而非事务一致性。时序数据库与通用NoSQL的区别在于：TSDB针对时间维度有专门的索引和压缩优化、支持时间聚合函数（如滑动窗口、降采样）、内置数据保留和过期机制。Prometheus和InfluxDB都属于专用时序数据库，而TimescaleDB是基于PostgreSQL扩展实现的时序数据库方案。

时序数据库的工作原理与核心机制

时序数据库的存储引擎是决定性能的核心组件。Prometheus TSDB采用基于块（block）的存储格式，每个块覆盖约2小时的数据，包含块内数据文件（chunks）、索引文件（index）和元数据文件（meta.json）。写入时数据先进入内存中的Head块，通过WAL（Write-Ahead Log）保证持久性，定期压缩持久化为磁盘上的块。InfluxDB的TSM引擎基于LSM-Tree变体，写入时数据先进入缓存（Cache）和WAL，当缓存满后flush为TSM文件（类似于SSTable），后台通过compaction合并多个TSM文件。TimescaleDB基于PostgreSQL，使用Hypertable抽象将数据按时间分区为多个chunk，每个chunk是一个常规PostgreSQL表。

压缩算法是时序数据库实现高存储效率的关键。Facebook在Gorilla论文中提出了两种高效压缩算法：时间戳压缩采用delta-of-delta编码，利用相邻数据点时间间隔通常固定的特性，将时间戳压缩为1-2个bit的标记加少量数据位；浮点数值压缩采用XOR编码，利用相邻数据点值通常接近的特性，通过异或运算和前导零/尾随零优化将每个值压缩为平均1.37字节。Prometheus直接采用了Gorilla压缩算法，InfluxDB在TSM引擎中使用了类似的简单8位压缩和差分编码。这些压缩算法使时序数据通常能实现10倍以上的压缩比，大幅降低存储成本。

索引机制决定了时序数据库的查询效率。Prometheus为每个块构建倒排索引（inverted index），将标签键值对映射到对应的时间序列ID列表。查询时通过标签选择器（如host=server-01）在倒排索引中快速定位匹配的序列，再扫描对应的数据块。InfluxDB的TSM引擎使用系列索引（series index）将measurement加tag set映射到系列键，支持基于标签的快速过滤。高基数（high cardinality）标签会导致索引膨胀，因为每个唯一的标签值组合对应一个独立的时间序列，过多的唯一组合会使索引和序列数量爆炸式增长，这是时序数据库最常见的性能问题。

写入和读取路径是时序数据库工作流程的两条主线。写入路径以Prometheus为例：抓取指标数据后写入内存Head块和WAL，Head块中的数据按序列组织为chunk（默认120个数据点一个chunk），chunk满后压缩持久化。读取路径以Prometheus为例：解析PromQL查询语句，通过倒排索引找到匹配的序列集合，根据时间范围定位数据块，解压读取数据点，执行聚合和函数运算后返回结果。InfluxDB的写入路径类似（缓存+WAL+TSM文件），读取路径通过系列索引定位数据，在TSM文件中按时间范围扫描。两种数据库都支持远程读写（remote read/write）接口，允许将数据转发到外部长期存储系统。

时序数据库的主要类型与分类体系

时序数据库按架构形态可分为嵌入式TSDB、独立TSDB和扩展型TSDB三类。嵌入式TSDB以Prometheus为代表，TSDB作为监控系统的一部分嵌入运行，不独立部署，适合单节点监控场景。独立TSDB以InfluxDB为代表，作为独立的数据库服务运行，支持多种数据接入方式和更丰富的查询能力。扩展型TSDB以TimescaleDB为代表，在现有关系型数据库（PostgreSQL）上通过扩展实现时序能力，兼顾时序性能和关系型数据库的事务能力。其他知名时序数据库还包括VictoriaMetrics（高性能Prometheus替代）、QuestDB（基于SQL的高性能TSDB）、Druid（面向实时分析的时序数据仓库）和AWS Timestream（云托管TSDB）。

时序数据库按数据采集模式可分为拉取式（Pull）和推送式（Push）两类。Prometheus采用拉取模式，由Prometheus服务器主动定期访问目标服务的HTTP端点（通常是/metrics）抓取指标数据。拉取模式的优势在于服务端掌控采集频率、天然支持健康检查、目标变更时无需修改客户端配置。InfluxDB采用推送模式，由Telegraf等采集代理或应用程序主动将数据写入InfluxDB。推送模式的优势在于支持更高频率的数据采集、适合短生命周期任务（如批处理作业）和防火墙后的环境。两种模式的选择取决于基础设施架构和运维偏好，CNCF生态中拉取模式（Prometheus）是主流。

时序数据库按存储引擎可分为LSM-Tree型、列式存储型和块存储型三类。LSM-Tree型（InfluxDB TSM）通过内存缓存加有序磁盘文件加后台合并的方式实现高吞吐写入，适合写入密集型场景。列式存储型（TimescaleDB）基于PostgreSQL的列式存储扩展，适合需要复杂SQL查询和JOIN操作的场景。块存储型（Prometheus TSDB）将数据按时间分块存储，每块内采用Gorilla压缩，适合监控指标的高效存储和查询。VictoriaMetrics采用自研的列式存储加LSM合并的混合架构，在压缩率和查询性能上都有优势。不同存储引擎在写入吞吐、查询延迟、压缩率和功能丰富度之间有不同取舍。

Prometheus与InfluxDB与TimescaleDB的核心对比：Prometheus擅长云原生监控场景，生态成熟（Grafana、Alertmanager、Service Discovery），内置TSDB不支持长期存储（需配合Thanos或VictoriaMetrics），查询语言PromQL专为监控设计。InfluxDB擅长通用时序数据存储，支持更灵活的数据模型（measurement+tags+fields），查询语言Flux功能强大但学习曲线陡峭，适合IoT和DevOps场景。TimescaleDB基于PostgreSQL，支持完整SQL和JOIN，适合需要结合关系型数据和时序数据的场景，但写入吞吐量低于专用TSDB。在云原生监控领域Prometheus是首选，在IoT和通用时序场景InfluxDB更灵活，在需要SQL和关系型能力时TimescaleDB更合适。

时序数据库的实际应用场景与案例分析

时序数据库在基础设施和应用监控中是最核心的应用场景。某互联网公司使用Prometheus+Grafana构建统一的监控平台，采集数千个微服务的CPU、内存、网络、磁盘IO、请求延迟和错误率等指标，每秒写入超过200万个数据点。Prometheus的多维标签模型使团队能按服务名、环境、地域等维度灵活聚合和过滤指标。通过PromQL实现SLI/SLO监控（如过去5分钟内99分位延迟低于200毫秒的请求占比），配合Alertmanager实现多级告警。记录规则（Recording Rules）预计算常用聚合查询，将Dashboard加载时间从15秒降低到2秒。Prometheus联邦（Federation）机制实现跨数据中心的全局聚合视图。

时序数据库在物联网（IoT）数据采集中发挥关键作用。某智能工厂部署了超过10万个传感器，每秒产生温度、压力、振动等工业指标数据。团队选择InfluxDB作为时序数据存储，通过Telegraf采集MQTT协议数据并写入InfluxDB。InfluxDB的高吞吐写入能力支持每秒50万数据点的持续写入，TSM压缩引擎使年数据量从原始估计的50TB压缩到5TB。通过InfluxDB的连续查询（Continuous Queries）实现5分钟和1小时粒度的降采样，原始数据保留30天，降采样数据保留1年。Flux查询语言支持复杂的时间序列分析，如设备异常检测（基于滑动窗口标准差）和预测性维护（基于趋势分析）。

时序数据库在金融市场数据管理中有重要应用。某量化交易平台使用QuestDB存储股票和期货的Tick数据（逐笔成交数据）和K线数据，每秒处理超过100万条Tick记录。QuestDB的列式存储和SIMD向量化执行引擎使时间范围查询延迟低于1毫秒，支持高频交易策略的实时信号计算。时序数据库的降采样能力用于从Tick数据生成不同时间粒度的K线（1秒、1分钟、1小时等），满足不同策略的时间框架需求。数据保留策略自动清理3个月前的Tick数据，保留5年的日线数据，平衡存储成本和数据可用性。相比传统关系型数据库，专用时序数据库在金融数据场景下写入吞吐提升20倍，查询延迟降低100倍。

时序数据库在AI和机器学习领域中的应用日益重要。AI训练过程中产生大量指标数据（GPU利用率、显存占用、损失值、梯度范数、学习率等），需要实时监控和回溯分析。某AI团队使用Prometheus监控训练集群的GPU指标，通过DCGM-Exporter采集GPU温度、功耗和利用率，结合自定义Exporter采集训练loss和accuracy曲线。训练异常（如loss爆炸、梯度消失）通过Prometheus告警规则实时检测并通知。推理服务的QPS、延迟和错误率通过Prometheus监控，配合Grafana展示SLA仪表盘。特征工程中的特征值分布和漂移检测数据存入InfluxDB，支持按时间范围查询特征统计信息，辅助模型再训练决策。时序数据库为AI系统的可观测性和可靠性提供了数据基础。

时序数据库的优缺点分析与选型建议

时序数据库的核心优势包括：高写入吞吐量（针对追加写入优化，Prometheus单节点可处理每秒百万级数据点）、高效压缩（Gorilla压缩和delta编码使压缩比通常达到10倍以上，大幅降低存储成本）、时间范围查询优化（按时间维度索引和分块存储，范围查询效率远超传统数据库）、内置时间聚合函数（支持滑动窗口、降采样、百分位计算等时序专属操作）、自动数据过期（内置保留策略自动清理旧数据，无需手动维护）。这些优势使时序数据库在监控、IoT和实时分析等场景中成为不可替代的基础设施。CNCF调查显示时序数据库是云原生技术栈中使用率最高的数据库类型之一。

时序数据库的局限性包括：不支持事务（时序数据库通常不支持ACID事务，不适合需要强一致性的业务场景）、更新和删除能力有限（时序数据以追加为主，更新历史数据效率低甚至不支持）、高基数问题（标签组合过多导致序列数量爆炸，内存和存储消耗剧增，严重影响性能）、查询灵活性有限（PromQL等时序查询语言不适合复杂JOIN和多表关联查询）、生态差异大（不同TSDB的查询语言、数据模型和API差异大，迁移成本高）。此外，Prometheus原生不支持集群化和长期存储，需要配合Thanos或VictoriaMetrics等扩展方案，增加了架构复杂度。

时序数据库适合的场景包括：系统和应用监控（CPU、内存、网络、请求延迟、错误率等指标采集与告警）、IoT传感器数据（温度、湿度、压力、位置等设备数据的采集与分析）、金融行情数据（股票、期货、外汇的Tick数据和K线数据存储与查询）、业务运营指标（用户活跃度、交易量、转化率等业务指标的实时监控）、AI/ML训练监控（GPU利用率、loss曲线、模型性能指标的实时追踪）。这些场景的共同特点是数据按时间顺序追加写入、查询以时间范围为主、需要时间聚合和降采样、数据有自然的过期需求。

时序数据库不适合的场景包括：事务性业务系统（如订单处理、账户管理，需要ACID事务和强一致性）、复杂关联查询（需要多表JOIN和子查询的分析型场景，应选择关系型或分析型数据库）、全文搜索（需要文本分词和倒排索引的搜索场景，应选择Elasticsearch等搜索引擎）、图数据查询（需要节点和边遍历的图关系场景，应选择Neo4j等图数据库）、低延迟点查（需要按主键随机读取单条记录的场景，应选择Redis等KV数据库）。选型时应根据数据的时序特征占比和查询模式决定是否使用专用时序数据库，避免在非时序场景中滥用TSDB导致架构不合理。

时序数据库的进阶话题与发展趋势

长期存储和集群化是Prometheus生态的重要发展方向。Prometheus原生设计为单节点系统，不支持集群化和长期存储（默认保留15天）。Thanos项目通过Sidecar组件将Prometheus数据上传到对象存储（如S3），提供全局查询接口和长期存储能力。Cortex（现为Mimir）和VictoriaMetrics从架构层面解决了Prometheus的集群化问题，支持水平扩展和多租户。这些方案使Prometheus生态能够支撑企业级的大规模监控场景。Thanos的Store Gateway组件可以查询对象存储中的历史数据，Compactor组件负责降采样和数据压缩，Query组件实现跨实例的全局查询。截至2024年，Grafana Mimir（Cortex的继任者）和VictoriaMetrics是大规模Prometheus长期存储的主流方案。

云原生和Serverless时序数据库是重要趋势。AWS Timestream提供完全托管的时序数据库服务，自动管理底层基础设施的扩展和维护，按使用量计费。Azure Data Explorer（Kusto）提供近实时的时序数据分析能力，支持KQL查询语言。InfluxDB Cloud提供Serverless版和Dedicated版，Serverless版按使用量计费适合中小规模场景。这些云服务降低了时序数据库的运维门槛，但也带来了厂商锁定和成本不可控的风险。开源方案中，VictoriaMetrics凭借出色的性能和低资源消耗成为自建时序数据库的热门选择，其集群版支持水平扩展和多租户隔离。

边缘时序数据库是IoT和边缘计算场景的新兴方向。在边缘设备上运行轻量级时序数据库（如InfluxDB Edge、Prometheus Agent模式），实现本地数据采集、缓存和预处理，再通过批量上传或流式传输将聚合后的数据同步到中心云。这种边缘到云的分层架构减少了网络带宽消耗、支持断网场景下的本地自治、降低了中心云的存储压力。VictoriaMetrics的vmagent组件支持边缘侧的数据采集和转发，支持数据压缩传输和多目标复制。在工业IoT场景中，边缘时序数据库还可以配合流处理引擎实现实时异常检测和本地告警，减少对云端的依赖。

AI与时序数据库的融合是前沿发展方向。时序异常检测方面，通过将Prometheus或InfluxDB中的指标数据接入机器学习模型（如Isolation Forest、LSTM自编码器），实现比传统阈值告警更智能的异常检测。预测性分析方面，利用时序预测模型（如Prophet、ARIMA、Transformer）对历史指标数据进行趋势预测，辅助容量规划和故障预警。模型监控方面，时序数据库用于存储AI模型推理服务的延迟、吞吐、准确率等指标，实时监控模型性能退化（model drift）。大语言模型辅助时序分析方面，通过将自然语言查询转换为PromQL或Flux查询语句，降低时序数据查询的门槛。这一趋势正在推动时序数据库从数据存储向智能分析平台的演进。

时序数据库的实践指南与最佳实践

数据建模最佳实践是时序数据库使用的基础。Prometheus指标命名应遵循层次化命名规范（如httprequests_total、nodecpu_secondstotal），使用下划线分隔单词，后缀表示类型（total、count、sum、bucket）。标签设计应避免高基数标签（如userid、sessionid、requestid等唯一标识符），每个标签的基数应控制在数千以内。InfluxDB的tag应用于索引和过滤（低基数），field用于存储实际数值（高基数不受限），measurement对应一个数据集概念。TimescaleDB应合理设置chunktime_interval（通常为1天到7天），过小导致chunk数量过多影响查询，过大导致单chunk数据量过大影响压缩。所有时序数据库都应遵循一个核心原则：标签组合数量（基数）是决定性能的关键因素，必须严格控制。

数据保留和降采样策略是控制存储成本的核心手段。Prometheus通过--storage.tsdb.retention.time设置保留时间（默认15天），长期数据需配合Thanos上传到对象存储。InfluxDB通过Bucket的retention policy设置保留时间，通过Task（或连续查询）实现降采样。降采样的典型策略是：原始数据保留短期（如7-30天），5分钟聚合数据保留中期（如3-6个月），1小时聚合数据保留长期（如1-2年）。降采样应在数据写入时通过后台任务异步执行，避免影响写入性能。TimescaleDB通过连续聚合（Continuous Aggregates）实现自动降采样，通过压缩策略（Compression Policy）自动压缩历史数据，通过保留策略（Retention Policy）自动删除过期数据。

基数管理是时序数据库运维的重中之重。高基数的根因通常是标签中包含了唯一性标识符（如用户ID、请求ID、错误消息全文等）。检测高基数的方法包括：Prometheus的prometheustsdb_headseries指标监控活跃序列数量，TSDB的/api/v1/status/tsdb接口查看标签基数统计，Grafana的 Cardinality Dashboard可视化标签基数分布。解决高基数的策略包括：将高基数标签改为非索引字段（InfluxDB中从tag改为field）、使用recording rules预聚合消除高基数标签、限制标签值的取值范围（如将错误消息截断为错误类型）、使用exemplar存储少量高基数样本而非全部索引。在Prometheus中，每个活跃序列消耗约1-3KB内存，1000万活跃序列将消耗10-30GB内存，因此基数管理直接影响系统的稳定性。

运维和查询优化最佳实践包括：容量规划（根据数据点写入速率、序列基数和保留时间预估内存和存储需求，预留50%以上余量）、查询优化（避免大范围时间查询，使用recording rules预计算常用聚合，避免在查询中使用高基数的group by或join操作）、监控TSDB自身健康（监控Prometheus的内存使用、写入延迟、WAL大小、chunk flush速率等指标）、备份策略（对Prometheus通过snapshot API备份TSDB数据，对InfluxDB通过influx backup命令备份，长期数据备份到对象存储）、告警最佳实践（使用多级告警避免告警风暴，使用for字段过滤瞬时波动，使用recording rules优化告警规则评估性能）。在大规模部署中，还应考虑联邦集群、远程读写分片和查询负载均衡等高级架构策略。

AI 应用场景

Python 演示

#!/usr/bin/env python3# 时序数据库概念模拟器：写入、查询、降采样、数据保留from dataclasses import dataclass, fieldfrom typing import Dict, List, Tuple, Optionalfrom collections import defaultdictimport timeimport math  @dataclassclass DataPoint:    timestamp: int    value: float  class TimeSeries:    # 单个时间序列：由metric name和labels唯一标识    def __init__(self, metric: str, labels: Dict[str, str]):        self.metric = metric        self.labels = tuple(sorted(labels.items()))        self.points: List[DataPoint] = []     @property    def series_id(self) -> str:        label_str = ','.join(f'{k}={v}' for k, v in self.labels)        return f'{self.metric}{{{label_str}}}'     def append(self, ts: int, value: float):        self.points.append(DataPoint(ts, value))     def query_range(self, start: int, end: int) -> List[DataPoint]:        return [p for p in self.points if start <= p.timestamp <= end]  class GorillaCompressor:    # Gorilla压缩算法模拟：delta-of-delta时间戳 + XOR浮点数压缩    @staticmethod    def compress_timestamps(timestamps: List[int]) -> List[int]:        if len(timestamps) < 3:            return timestamps        deltas = []        for i in range(1, len(timestamps)):            deltas.append(timestamps[i] - timestamps[i - 1])        dod = [0]        for i in range(1, len(deltas)):            dod.append(deltas[i] - deltas[i - 1])        return dod     @staticmethod    def compress_values(values: List[float]) -> List[float]:        if len(values) < 2:            return values        xors = [0.0]        for i in range(1, len(values)):            xors.append(values[i] - values[i - 1])        return xors  class Downsampler:    # 降采样器：将高频数据聚合为低频数据    @staticmethod    def downsample(points: List[DataPoint], interval: int, agg: str = 'avg') -> List[DataPoint]:        if not points:            return []        buckets: Dict[int, List[float]] = defaultdict(list)        for p in points:            bucket_key = (p.timestamp // interval) * interval            buckets[bucket_key].append(p.value)        result = []        for ts in sorted(buckets.keys()):            vals = buckets[ts]            if agg == 'avg':                result.append(DataPoint(ts, sum(vals) / len(vals)))            elif agg == 'max':                result.append(DataPoint(ts, max(vals)))            elif agg == 'min':                result.append(DataPoint(ts, min(vals)))            elif agg == 'sum':                result.append(DataPoint(ts, sum(vals)))        return result  class RetentionPolicy:    # 数据保留策略：自动删除过期数据    def __init__(self, retention_seconds: int):        self.retention_seconds = retention_seconds     def enforce(self, series: TimeSeries, now_ts: int) -> int:        cutoff = now_ts - self.retention_seconds        before = len(series.points)        series.points = [p for p in series.points if p.timestamp >= cutoff]        return before - len(series.points)  class TimeSeriesDB:    # 时序数据库：支持写入、查询、降采样和数据保留    def __init__(self):        self.series_map: Dict[str, TimeSeries] = {}        self.compressor = GorillaCompressor()     def write(self, metric: str, labels: Dict[str, str], ts: int, value: float):        series = TimeSeries(metric, labels)        sid = series.series_id        if sid not in self.series_map:            self.series_map[sid] = series        self.series_map[sid].append(ts, value)     def query(self, metric: str, labels: Dict[str, str], start: int, end: int) -> List[DataPoint]:        series = TimeSeries(metric, labels)        sid = series.series_id        if sid not in self.series_map:            return []        return self.series_map[sid].query_range(start, end)     def get_cardinality(self) -> int:        return len(self.series_map)     def apply_retention(self, policy: RetentionPolicy, now_ts: int) -> int:        total_deleted = 0        for series in self.series_map.values():            total_deleted += policy.enforce(series, now_ts)        return total_deleted  if __name__ == '__main__':    db = TimeSeriesDB()    base_ts = 1700000000    for i in range(100):        db.write('cpu_usage', {'host': 'server-01', 'region': 'us-east'}, base_ts + i * 60, 50.0 + i * 0.5)    print('=== Query Range ===')    points = db.query('cpu_usage', {'host': 'server-01', 'region': 'us-east'}, base_ts, base_ts + 3600)    print(f'Found {len(points)} points')    print('\n=== Downsampling (5min avg) ===')    downsampled = Downsampler.downsample(points, 300, 'avg')    print(f'Downsampled to {len(downsampled)} points')    print('\n=== Retention Policy ===')    policy = RetentionPolicy(retention_seconds=1800)    deleted = db.apply_retention(policy, base_ts + 7200)    print(f'Deleted {deleted} expired points')    print(f'Cardinality: {db.get_cardinality()}')

1. class TimeSeries:时间序列类，由metric名称和labels标签集唯一标识一个序列，对应Prometheus的指标模型和InfluxDB的measurement加tag set模型。
2. def __init__(self, metric: str, labels: Dict[str, str]):初始化时间序列，将labels排序为元组以保证同一组标签生成相同的序列ID，对应时序数据库中序列标识的唯一性保证。
3. def append(self, ts: int, value: float):追加数据点到时间序列，时序数据库以追加写入为主极少更新，这是TSDB高吞吐写入的基础。
4. def query_range(self, start: int, end: int) -> List[DataPoint]:按时间范围查询数据点，这是时序数据库最核心的查询模式，Prometheus和InfluxDB都支持时间范围过滤。
5. class GorillaCompressor:Gorilla压缩算法模拟器，Facebook在Gorilla论文中提出的时序数据压缩算法，被Prometheus直接采用。
6. def compress_timestamps(timestamps: List[int]) -> List[int]:时间戳压缩：计算delta（相邻时间戳差值）再计算delta-of-delta（差值的差值），利用时间间隔通常固定的特性实现高压缩比。
7. def compress_values(values: List[float]) -> List[float]:浮点数值压缩：计算相邻值的差分（模拟XOR编码），利用相邻数据点值通常接近的特性减少存储空间。
8. class Downsampler:降采样器，将高频数据按时间窗口聚合为低频数据，是控制存储成本和提升长期查询效率的关键机制，对应InfluxDB的Task和TimescaleDB的连续聚合。
9. def downsample(points: List[DataPoint], interval: int, agg: str = 'avg') -> List[DataPoint]:按指定时间间隔将数据点分桶聚合，支持avg/max/min/sum聚合函数，对应InfluxDB的降采样查询和Prometheus的rate聚合。
10. class RetentionPolicy:数据保留策略，自动删除超过保留期的历史数据，对应Prometheus的retention配置和InfluxDB的Bucket retention policy。
11. def __init__(self, retention_seconds: int):设置数据保留时间，超过此时间的数据将被自动清理，这是时序数据库区别于传统数据库的内置数据生命周期管理能力。
12. def enforce(self, series: TimeSeries, now_ts: int) -> int:执行保留策略：删除早于cutoff时间戳的数据点，返回删除数量，对应Prometheus TSDB的block compaction和InfluxDB的shard drop。
13. class TimeSeriesDB:时序数据库核心类，整合时间序列存储、压缩、降采样和保留策略，模拟Prometheus TSDB和InfluxDB TSM引擎的核心功能。
14. def write(self, metric: str, labels: Dict[str, str], ts: int, value: float):写入数据点：根据metric和labels查找或创建时间序列，追加数据点，对应Prometheus的scrape写入和InfluxDB的Line Protocol写入。
15. def query(self, metric: str, labels: Dict[str, str], start: int, end: int) -> List[DataPoint]:查询数据点：根据metric和labels定位时间序列，返回指定时间范围内的数据点，对应PromQL的范围查询和InfluxDB的range查询。
16. def get_cardinality(self) -> int:获取当前基数（活跃时间序列数量），基数是时序数据库最重要的健康指标，过高会导致内存溢出和性能下降。
17. def apply_retention(self, policy: RetentionPolicy, now_ts: int) -> int:对所有时间序列执行保留策略，返回总删除数据点数，对应Prometheus的后台retention goroutine和InfluxDB的retention service。
18. db.write('cpu_usage', {'host': 'server-01', 'region': 'us-east'}, base_ts + i * 60, 50.0 + i * 0.5)模拟写入CPU使用率指标，每分钟一个数据点，标签包含host和region，对应Prometheus采集nodecpu指标的场景。
19. downsampled = Downsampler.downsample(points, 300, 'avg')将1分钟粒度数据降采样为5分钟平均值，对应InfluxDB的连续查询和TimescaleDB的连续聚合，用于减少长期数据存储量。
20. deleted = db.apply_retention(policy, base_ts + 7200)执行保留策略删除30分钟前的数据，模拟Prometheus的retention机制，演示时序数据库自动数据过期的能力。

常见问答

常见误区

参考来源

• docPrometheus Storage - Prometheus DocumentationPrometheus官方文档，介绍了TSDB存储引擎、块结构、WAL和压缩机制
• docInfluxDB Storage Engine - InfluxData DocumentationInfluxDB官方文档，介绍了TSM存储引擎、WAL、Cache和Compaction机制
• paperGorilla: A Fast, Scalable, In-Memory Time Series Database - VLDB 2015Facebook Gorilla论文，提出了delta-of-delta时间戳压缩和XOR浮点数压缩算法，被Prometheus等广泛采用
• docTimescaleDB Documentation - Hypertables and CompressionTimescaleDB官方文档，介绍了Hypertable、连续聚合和压缩策略等核心概念
• docThanos Design - Thanos DocumentationThanos官方文档，介绍了Prometheus长期存储和全局查询的架构设计