想象你是一位老字号账房的账房先生。每天的流水账只干一件事：在最后一页写下新的一行——日期、入账、出账，从不修改旧账。日子一长，账本越来越厚，查上个月的账要翻几百页纸。于是你想出一个办法：按月分册，一月一本；月底封存旧册，月初另起新册。掌柜问“这个月共入账多少？”你翻翻当月册子的汇总页就能答上来。这套管理思路，正是 TimescaleDB 的一切。 TimescaleDB 是一个“时序数据库”，专门处理像流水账一样不断追加、随时间增长的数据——服务器监控、智能电表读数、股票行情。它把一张逻辑上的大表（超表）自动按时间切成许多小块（分块），数据永远只写最新的一块；旧块封存后可以压缩、可以定期销毁；还可以提前把“每日汇总”算好存成物化视图。更贴心的是，这一切都建立在 PostgreSQL 之上，你以前会写的 SQL 全都照常可用。本文就以这位“智能账房先生”为主角，带你从零看懂 TimescaleDB 的工作原理、关键策略和实战用法。

岗位关联

对 AI 从业者而言，时序数据是模型训练、系统监控和特征工程的重要底座；读懂 TimescaleDB，你就能在数据管线设计、存储选型和性能调优中做出更专业的决策。

目录
  1. 可视化演示
  2. 时序数据特性
  3. 超表架构原理
  4. 块生命周期
  5. 压缩策略
  6. 连续聚合
  7. 性能优化
  8. 迁移与生态
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

时序数据特性

账房先生的流水账有一条铁规矩：只添新页，绝不动旧行。日期写在一行最前面，所有账目按时间先后排得整整齐齐。这样的账本，看一眼日期就知道先后，随手一翻就能定位到某一天。如果某天突然有人要求“把三年前的账目改一个数字”，账房先生会当场拒绝——旧账不能动，这是底线。

时序数据就是这种“流水账”式的数据：智能电表每分钟上报的电量、服务器每秒钟的 CPU 使用率、股票每一笔成交价，它们都带着时间戳，只追加、不修改、按时间顺序到达，而且量级巨大。传统关系型数据库把每条记录当成独立行来存，索引维护成本高，写入容易随机化，时间范围查询要扫描大量无关数据。时序数据库（Time Series Database，TSDB）专门优化这类场景，TimescaleDB 就是其中的代表选手。

TimescaleDB 在建模上依然沿用关系型思维：一张表里就是 （时间戳，标签，指标值） 这样的行。它的聪明之处在于改变存储策略——按时间列来组织数据，让新数据自然落到“账本尾部”，查询时则沿着时间轴快速定位区间。一条时序记录可以写成：

正因为数据天生按时间有序，账房先生才能把记账变成简单的“往末尾追加新页”。如果把这套逻辑做成软件，第一步就是让表能够自动按时间分册——这就是超表的由来。

rowi=(ti, di,1, di,2, ⋯ , di,k)\displaystyle row_{i} = (t_{i},\ d_{i,1},\ d_{i,2},\ \cdots,\ d_{i,k})
这条公式说明：时序数据本质是一行行“时间戳 + 多个指标值”的组合。$t_i$ 是第 $i$ 条记录发生的时间，$d_{i,j}$ 表示该时刻的第 $j$ 个观测值。
  1. 记录编号$i$ 是第几条记录，流水账的第几行。
    i=1,2,3,⋯\displaystyle i = 1, 2, 3, \cdots
  2. 时间戳$t_i$ 表示这条记录发生在什么时刻，也是分账的关键依据。
    ti\displaystyle t_i
  3. 观测向量$(d_{i,1}, d_{i,2}, \cdots, d_{i,k})$ 是同一时刻采集的 $k$ 个指标，比如一台服务器的 CPU、内存、磁盘余量。
    (di,1, di,2, ⋯ , di,k)\displaystyle (d_{i,1},\ d_{i,2},\ \cdots,\ d_{i,k})

超表架构原理

如果流水账十年只装订成一大厚本，账房先生翻一天也找不到上个月某笔账。他的解法是：按月分册。一月底封存一册，二月一号另起一册。对掌柜来说，这些薄册子拼在一起依然是一整本流水账，只是内部分开了。

TimescaleDB 的超表（Hypertable）就是这种“分册的流水账”。对外，它是一张普通的 PostgreSQL 表，应用该怎么写 INSERT 就怎么写，该怎么 SELECT 就怎么 SELECT；对内，这张表被按时间列自动切成许多小块，每块叫做一个分块（Chunk）。每个分块覆盖一个时间区间，比如“2025-01-01 00:00:00 到 2025-01-02 00:00:00”。

创建超表的典型语句是 SELECT create_hypertable('conditions', by_range('time', INTERVAL '1 day'))。这里的 INTERVAL '1 day' 就是“每册账本覆盖多少天”。分块数量由数据总时间跨度决定：

超表的分块细节完全由内核自动管理，DBA 不需要手动建几十张子表。每本账册都有自己独立的索引和存储文件，查某一天的数据时，系统会“看目录”直接锁定那一两本册子，而不是翻完整套账。分块如何从空白长到写满、再被归档，则是下一节要讲的生命周期。

C=⌈Tend−TstartΔT⌉\displaystyle C = \left\lceil \frac{T_{end} - T_{start}}{\Delta T} \right\rceil
公式的含义是：把这批数据从最早到最晚的时间长度，除以每块的时间长度，向上取整，就得到需要的分块数。就像把三年流水按每月 1 本分成 36 本再加可能多出的 1 本。
  1. 数据时间跨度$T_{end} - T_{start}$ 表示最早一条记录和最晚一条记录之间隔了多久。
    Tend−Tstart\displaystyle T_{end} - T_{start}
  2. 每块时间跨度$\Delta T$ 是每个分块覆盖的时间长度，例如 1 天。
    ΔT\displaystyle \Delta T
  3. 取整与分块数$\left\lceil \cdots \right\rceil$ 向上取整，最后一段不满也单独算一本册子，得到总块数 $C$。
    C=⌈Tend−TstartΔT⌉\displaystyle C = \left\lceil \frac{T_{end} - T_{start}}{\Delta T} \right\rceil

块生命周期

新的一月开始，账房先生拿出一本空白册子。每天记账，册子越来越厚；到了月底最后一天，册子写满或时间到了，他把册子合上、封箱、贴上日期标签，放到货架上，再拿出一本新册子。从此，新账永远不会写进旧册。

TimescaleDB 的每个分块（Chunk）也遵循同样的生命周期：创建 → 写入 → 封存归档。新数据到达时，路由层根据时间戳把数据分发到对应的分块；覆盖当前时间窗口的分块称为“活动块”（Active Chunk），它持续接受写入。当一个分块达到限制条件——时间跨度到点、行数或字节数达到阈值——它就会被标记为只读，不再接受新行；与此同时，系统自动创建一个新的活动块接手后续数据。

这个机制保证了写入永远是顺序追加：新数据永远落在最后一个活动块上，就像新账永远记在最后一本册子的最后一页。分块从创建到写满的耗时，取决于块容量上限和写入速率：

封存的分块不会被新数据打扰，这为后两节的操作提供了前提：旧册子可以被压缩得更小，也可以到期被搬走销毁。货架上的账册越积越多，就得想办法给它们“瘦身”。

Tfill=Smaxr\displaystyle T_{fill} = \frac{S_{max}}{r}
一个分块多久会被写满（$T_{fill}$），等于块存储上限（$S_{max}$）除以平均写入速率（$r$）。写入越快，块越小，封存轮换就越频繁。
  1. 块容量上限$S_{max}$ 是单个分块允许的最大存储量，超过它就封存。
    Smax\displaystyle S_{max}
  2. 平均写入速率$r$ 是每秒/每分钟新进入的数据量。
    r\displaystyle r
  3. 填满耗时$T_{fill}$ 用于预估多久轮换一个块，方便设置压缩与保留策略的触发频率。
    Tfill=Smaxr\displaystyle T_{fill} = \frac{S_{max}}{r}

压缩策略

账房里的旧账册堆满了三个货架。账房先生想出一个主意：用细密的小字把旧账重新誊写一遍，一页能装下原来十页的内容。平时这些册子不展开，只有查某笔老账时才逐字还原。三个月后，三个货架变一个货架，省下大量空间。

TimescaleDB 的压缩机制就是这个思路，而且做得极其精细。它只压缩封存的分块，因为活动块还在高频写入，压缩解压反而拖慢速度。压缩采用列式存储：把同一列的数据连续存放，然后对时间戳做增量编码、对重复值做字典编码，最后用通用压缩算法（如 LZ 或 ZSTD）压缩。查询旧数据时，系统透明解压，应用完全无感知。

开启压缩只需一条 DDL，例如 ALTER TABLE conditions SET (timescaledb.compress, segment_by = 'device_id')。之后可以配合压缩策略定期自动压缩到期分块。压缩效果的度量公式：

压缩让账房先生能存下更久的历史数据，但掌柜经常要问“今天一共入账多少”。如果每次都把本月几百页流水重算一遍，依旧太慢。所以账房先生又养成了一个好习惯：每晚提前写好汇总页。

ρ=1−ScS0\displaystyle \rho = 1 - \frac{S_{c}}{S_{0}}
压缩率 $\rho$ 表示省掉了多少空间：$\rho=0$ 表示没节省，$\rho=0.9$ 表示压缩后只剩原来的一成空间。时序数据常常能压到原来的 5%~10%。
  1. 原始大小$S_0$ 是压缩前该分块占用的存储空间。
    S0\displaystyle S_{0}
  2. 压缩后大小$S_c$ 是采用列式存储加压缩算法后的空间。
    Sc\displaystyle S_{c}
  3. 压缩率计算$1 - S_c / S_0$ 越大越省空间，通常物联网指标能达到 0.9 以上。
    ρ=1−ScS0\displaystyle \rho = 1 - \frac{S_{c}}{S_{0}}

连续聚合

掌柜每天打烊后都喜欢问一句：“今天共入账多少银两？”账房先生从不现场翻一整天的流水，因为他在每晚亥时已经抽空把当日合计写好，放在账册最前面的汇总页。第二天一问，张口就来。

TimescaleDB 的连续聚合（Continuous Aggregate）就是这个“汇总页”机制。它本质上是一个物化视图（Materialized View）：系统按指定的时间桶（比如 1 小时、1 天）持续对原始数据做 avg、sum、count 等聚合，把结果存成一张新表。你查询“最近 24 小时平均 CPU 使用率”时，命中的是这张汇总表，而不是扫描上亿行原始记录。

创建方式像普通的视图语句，例如：

配合一个刷新策略，系统会定期只增量刷新最近变化的窗口。聚合窗口的数学描述是：

有了汇总页，掌柜查账快得惊人。而日常更常见的优化——从几百本账册中只挑出需要的那几本——靠的则是分区裁剪。这就进入性能优化的话题。

A(b)=f({ ri∣b≤ti<b+ΔT })\displaystyle A(b) = f\left( \{\, r_i \mid b \le t_i < b + \Delta T \,\} \right)
$A(b)$ 是以 $b$ 为起点的聚合结果，$f$ 是聚合函数（均值、求和等），大括号里是所有落在窗口内的原始记录。查询落在窗口上，就无需再翻原始流水。
  1. 窗口起点$b$ 是时间桶的起点，例如整点 "14:00"。
    b\displaystyle b
  2. 窗口内记录$\{\, r_i \mid b \le t_i < b + \Delta T \,\}$ 表示收集所有时间戳落在这个区间的记录。
    { ri∣b≤ti<b+ΔT }\displaystyle \{\, r_i \mid b \le t_i < b + \Delta T \,\}
  3. 聚合函数$f(\cdot)$ 对这些记录求平均、求和或计数。
    f(⋅)\displaystyle f(\cdot)
  4. 汇总结果$A(b)$ 存进物化视图，查询直接读取。
    A(b)\displaystyle A(b)
sql7 行
CREATE MATERIALIZED VIEW conditions_hourlyWITH (timescaledb.continuous) ASSELECT time_bucket('1 hour', time) AS bucket,       device_id,       avg(temperature) AS avg_tempFROM conditionsGROUP BY bucket, device_id;

性能优化

掌柜说：“查一下今年 3 月 15 日那天的账。”笨账房先生会从十年前第一页开始翻；聪明的账房先生抬头看一眼账架上的日期标签，径直取出一本册子。这一步之差，就是几十倍的速度差距。

TimescaleDB 性能优化的核心正是分区裁剪（Chunk Pruning）：查询语句带有时间范围条件时，优化器直接排除不相关的分块，只扫描命中的块。配合这个机制，还有三类常用手段。第一是索引设计：对 (device_id, time DESC) 建复合索引，让“查某个设备某段时间”变成目录检索。第二是并行查询：多个分块可以被多个工作进程并行扫描，享受多核红利。第三是内存配置：合理设置 shared_buffers、work_mem 等参数，让常用索引和排序操作留在内存。

裁剪带来的加速比可以用一个直观的公式衡量：

优化做到位后，账房先生查账几乎是指哪打哪。但故事还没完——如果这家账房原本用别的记账软件，要怎么搬过来呢？这就引出了迁移与生态。

S=NallNscan\displaystyle S = \frac{N_{all}}{N_{scan}}
加速比 $S$ = 总块数（$N_{all}$）除以实际扫描的块数（$N_{scan}$）。你的查询只碰 1 本账册而总共有 100 本，速度就接近 100 倍。
  1. 总块数$N_{all}$ 是超表当前全部分块数量，对应账架上所有账册。
    Nall\displaystyle N_{all}
  2. 扫描块数$N_{scan}$ 是执行计划中真正被扫描的分块数量。
    Nscan\displaystyle N_{scan}
  3. 加速比$S$ 越大说明裁剪效果越好，查询响应越快。
    S=NallNscan\displaystyle S = \frac{N_{all}}{N_{scan}}

迁移与生态

老板决定换掉祖宗传下来的旧账房系统，引入 TimescaleDB。新账房先生自我介绍的第一句话是：“我完全按老账房的记账格式来，所有 SQL 我都会，你原来的伙计不用重新学。”

这句话是真的。TimescaleDB 不是从零造的数据库，而是 PostgreSQL 的扩展。它继承了完整的 SQL 能力：事务、JOIN、窗口函数、UDF 全支持。相比之下，InfluxDB 等时序数据库使用专用查询语言，迁移时团队要重新学习。而迁移到 TimescaleDB，很多系统只需要改数据库连接串即可。

迁移过程中最实在的问题是时间预估。把历史数据搬进新账房，耗时取决于数据量和网络带宽：

生态方面，pg_dump 可以把原 PostgreSQL 数据直接搬进超表；Grafana、Prometheus、Telegraf 等监控生态也有现成适配器。换账房很简单，难点从来不在账本格式，而在账房先生是否真能继承全部旧手艺——TimescaleDB 选择了全兼容这条路，这也是它快速被采纳的原因。

Tmigrate=DallBnet\displaystyle T_{migrate} = \frac{D_{all}}{B_{net}}
迁移时间（$T_{migrate}$）= 总数据量（$D_{all}$）÷ 迁移带宽（$B_{net}$）。实际项目中还要算上压缩重算、索引重建的时间，但带宽永远是第一约束。
  1. 总数据量$D_{all}$ 是待迁移的历史数据总大小，单位常用 GB 或 TB。
    Dall\displaystyle D_{all}
  2. 迁移带宽$B_{net}$ 是源库与目标库之间的有效传输速率。
    Bnet\displaystyle B_{net}
  3. 预估耗时$T_{migrate}$ 用于规划停机窗口和同步方案。
    Tmigrate=DallBnet\displaystyle T_{migrate} = \frac{D_{all}}{B_{net}}

AI 应用场景

智能电表数据平台

阶段：数据存储与管理

解决的问题：传统方案用 MySQL 存亿级电表读数，存储膨胀到数百 GB，月度汇总报表跑一次要半小时。改用 TimescaleDB 后，超表按天分块，历史块压缩 90%，连续聚合预计算每日电量，报表秒级返回。

具体案例：某智慧园区部署 10 万只电表，每 5 分钟上报一次读数。运维团队把数据迁入超表，设置 1 天分块间隔、开启压缩策略、建立“每日 kWh 汇总”连续聚合。运行半年后，存储成本下降 85%，日结算任务从 40 分钟降到 3 秒。

金融行情特征底座

阶段：特征工程数据底座 / 时序特征计算

解决的问题：量化模型需要多年逐笔 tick 行情做回测，原始数据量极大且需要按时间切片查询。TimescaleDB 以标准 SQL 提供时序存储，分钟级 K 线通过连续聚合持续物化，显著降低特征计算延迟。

具体案例：某量化团队把日频 tick（每年约 2 亿行）迁入超表，按天分块并压缩。原先用内存 DataFrame 重算日均价的脚本需要 20 分钟，现在直接查连续聚合视图，耗时 200 毫秒，回测迭代速度大幅提升。

DevOps 可观测性平台

阶段：监控数据流水线

解决的问题：Prometheus 长期存储成本高，默认本地存储难以支撑百台以上服务器的年级指标。TimescaleDB 提供 Prometheus 适配器，把指标落库，并利用保留策略自动清理过期分块，压缩后存储成本仅为原来的十分之一。

具体案例：SRE 团队将 1000 台机器的 CPU、内存、网络指标接入 TimescaleDB，设置 180 天保留窗口，每天凌晨由保留策略执行 drop_chunks 删除过期块。配合 Grafana 大盘，历史告警回溯直接从超表查询。

Python 演示

python68 行
import zlibimport mathimport statisticsfrom datetime import datetime, timedelta  class TimescaleDBDemo:    """极简 TimescaleDB 概念模拟器：按时间分块 + 块压缩 + 预聚合"""     def __init__(self, chunk_interval_seconds=10):        self.chunk_interval = timedelta(seconds=chunk_interval_seconds)        self.chunks = {}       # 桶起始时间 -> 原始数据点        self.compressed = {}   # 桶起始时间 -> 压缩后字节        self.view = {}         # 桶起始时间 -> 预聚合结果     def _bucket(self, timestamp):        seconds = int(timestamp // self.chunk_interval.total_seconds())        return datetime.fromtimestamp(seconds * self.chunk_interval.total_seconds())     def insert(self, timestamp, value):        bucket = self._bucket(timestamp)        self.chunks.setdefault(bucket, []).append((timestamp, value))        self.compressed.pop(bucket, None)        self.view.pop(bucket, None)     def compress_inactive_chunks(self, active_bucket):        for bucket, rows in list(self.chunks.items()):            if bucket == active_bucket:                continue            payload = "\n".join(                "{:.3f}:{:.6f}".format(ts, v) for ts, v in rows            ).encode("utf-8")            self.compressed[bucket] = zlib.compress(payload, level=6)     def aggregate(self, bucket, func):        if bucket in self.view:            return self.view[bucket]        if bucket in self.compressed:            raw = zlib.decompress(self.compressed[bucket]).decode("utf-8")            rows = []            for line in raw.splitlines():                ts, v = line.split(":")                rows.append((float(ts), float(v)))        else:            rows = self.chunks.get(bucket, [])        values = [v for _, v in rows]        if not values:            return None        result = func(values)        self.view[bucket] = result        return result  if __name__ == "__main__":    db = TimescaleDBDemo(chunk_interval_seconds=10)    start_ts = 1_700_000_000.0    for i in range(2000):        db.insert(start_ts + i * 0.1, math.sin(i * 0.01) + 5.0)     active = db._bucket(start_ts + 1999 * 0.1)    db.compress_inactive_chunks(active)     print("原始活动块数:", len(db.chunks))    print("已压缩块数:", len(db.compressed))     bucket0 = db._bucket(start_ts)    avg = db.aggregate(bucket0, statistics.mean)    print("第一个分块平均值:", round(avg, 4))
目的：演示 TimescaleDB 的三个核心概念——按时间分块、封存块压缩、聚合结果物化缓存。
  1. self.chunk_interval = timedelta(seconds=chunk_interval_seconds)设置每个分块的时间跨度，对应超表的 chunk_interval。
  2. self.chunks.setdefault(bucket, []).append(...)新数据总是落入对应时间桶，类似 TimescaleDB 把行写入对应分块。
  3. self.compressed.pop(bucket, None)一旦桶有新数据写入，必须让压缩缓存失效，就像 TimescaleDB 先解压再写入新行。
  4. if bucket == active_bucket: continue只压缩非活动块，活动块保持可写状态以维持写入性能。
  5. zlib.compress(payload, level=6)用 zlib 做列级序列化后的行压缩，模拟 TimescaleDB 对封存分块的压缩。
  6. self.view[bucket] = result聚合结果缓存到物化视图，第二次查询直接命中，对应连续聚合。

常见误区

误区既然它被归在“时序与键值数据库”目录里，那它一定是 MongoDB 那样的 NoSQL 数据库，不需要 SQL 就能用。

正解TimescaleDB 本质是 PostgreSQL 的扩展，是百分之百的关系型数据库。标准 SQL、事务、JOIN、窗口函数全都支持。“时序数据库”只是按业务场景分类，而“是否使用 SQL”是另一条技术线。把它比作 NoSQL，就像把一位会用毛笔的会计误认为不会用计算器。

为何常见：课程目录和很多对比文章都把它与 InfluxDB、MongoDB 放在一起分类，初学者很容易被“标签”带偏，忽略了它底层的 PostgreSQL 血缘。

误区超表是时序专用引擎，肯定只能做简单的 INSERT 和 SELECT，不能和普通表 JOIN。

正解超表对应用是透明的。在 TimescaleDB 里，超表就是一张普通的 PostgreSQL 表，JOIN、GROUP BY、窗口函数、子查询都能直接执行。因为它没有发明新的查询语言，而是把逻辑表映射为多个子表（分块），查询层完全复用 PostgreSQL 的优化器与执行器。

为何常见：InfluxDB 等时序产品牺牲了 SQL 能力来换取写入性能，见过这些产品的用户容易把“时序数据库”和“专用查询语言”绑定在一起。

误区每次查询旧数据都要先解压，所以压缩后的块查询一定变慢。

正解压缩针对只读的封存块，数据以列式布局存放。查询时只需要解压被涉及的列，而且列式存储让每次 I/O 读取的有效数据密度大幅提高。磁盘 I/O 往往是查询瓶颈，压缩后读得更少，整体反而更快。活动块不压缩，保证热数据的写入与查询速度。

为何常见：凭直觉认为“解压是额外 CPU 开销”，忽略了存储引擎的瓶颈通常在磁盘带宽而非 CPU，也忽略了列式存储带来的 I/O 减少。

误区分块越多并行度越高，所以把 `chunk_interval` 设成 1 分钟甚至 1 秒，查询肯定更快。

正解每个分块都有元数据、索引和路由成本。块过小会产生大量小文件，查询计划的开销反而超过裁剪收益。正确的做法是根据写入速率设置间隔，让每个块保持在几十 MB 到几百 MB 量级，既保证裁剪效率，又不至于让元数据膨胀。

为何常见：“分治等于并行”的直觉没错，但忽略了数据库在每个分块上固定的管理和调度成本，盲目追求块数量反而适得其反。

误区创建了连续聚合之后，每次查询都能拿到最近一秒的聚合值。

正解连续聚合是物化视图，数据在刷新策略指定的时刻才会增量更新。默认刷新周期可能是数分钟到数小时，所以查询结果会有一定滞后。TimescaleDB 提供“实时聚合”选项，把未刷新的新数据实时叠加到视图上，但它也有自己的语义边界，需要理解后再使用。

为何常见：名称里的“实时”两字让很多人误以为是流式计算。实际上它是周期性物化 + 可选的实时补偿，本质仍是批量刷新。

面试题

Q1. TimescaleDB 本质上属于哪一类数据库？

单选题 · easy

  • A.关系型数据库← 正确答案
  • B.键值型数据库
  • C.图结构数据库
  • D.文档型数据库

答案：A。TimescaleDB 是 PostgreSQL 的扩展，天然是关系型数据库，支持标准 SQL、事务和 JOIN。它被归入时序数据库类别只是按业务场景划分，并不改变其关系型本质。键值、图、文档是其他数据模型。

Q2. 超表（Hypertable）主要按哪一列自动分块？

单选题 · easy

  • A.时间列← 正确答案
  • B.姓名列
  • C.哈希列
  • D.任意列

答案：A。时序数据天然按时间组织，超表通过时间列把数据切成多个分块，这也是写入顺序追加、查询按时间裁剪的基础。按其他列分块无法享受时间维度上的收益。

Q3. 下列哪个分块不适合做压缩？

单选题 · mid

  • A.旧历史块
  • B.封存归档块
  • C.最新活动块← 正确答案
  • D.一周前块

答案：C。活动块仍在高频接收新数据，压缩和解压会显著拖慢写入。TimescaleDB 只压缩封存后的非活动块，保证热路径性能。旧历史块、归档块都是冷数据，适合压缩。

Q4. 删除三个月前的旧数据，最佳做法是？

单选题 · mid

  • A.逐行删除
  • B.清空整表
  • C.按时间裁剪← 正确答案
  • D.重建数据库

答案：C。TimescaleDB 提供 drop_chunks 按时间直接删除整个分块，比逐行 DELETE 快几个数量级，因为它是整文件级别的清理。逐行删除要写大量 WAL 日志，成本极高。

Q5. 连续聚合把什么内容提前算好？

单选题 · mid

  • A.原始采样数据
  • B.窗口汇总结果← 正确答案
  • C.时间戳索引
  • D.压缩字典表

答案：B。连续聚合维护的是物化视图，把每个时间桶的聚合结果（均值、求和等）提前算好并落表。查询直接读汇总而不是现场聚合原始数据，这与普通视图完全不同。

Q6. TimescaleDB 压缩旧块时采用哪种存储形式？

单选题 · easy

  • A.行式存储
  • B.列式存储← 正确答案
  • C.键值存储
  • D.对象存储

答案：B。列式存储把同一列的连续值放在一起，配合增量编码和字典编码压缩率极高。行式存储难以高效压缩，键值存储和对象存储与 TimescaleDB 的压缩实现无关。

Q7. TimescaleDB 常用的性能优化手段有哪些？

多选题 · hard

  • A.时间范围裁剪← 正确答案
  • B.合理设置索引← 正确答案
  • C.禁用所有缓存
  • D.并行查询分块← 正确答案

答案：ABD。时间裁剪只扫命中分块，复合索引加速“设备+时间”查询，并行查询让多个分块利用多核并行扫描。禁用缓存显然错误，缓存对索引和热数据至关重要。

Q8. 查询要命中连续聚合视图，通常需要满足什么？

单选题 · mid

  • A.窗口小于等于聚合窗← 正确答案
  • B.窗口大于聚合窗口
  • C.与原表没有任何关系
  • D.必须聚合全部时间

答案：A。连续聚合按固定时间桶（比如 1 小时）预计算。当查询的时间窗口不超过聚合窗口并能对齐到物化层时，优化器才可能改写查询命中视图。窗口过大就需要扫描多个物化区间或回退原始表。

Q9. 关于时序索引设计，下列哪些说法正确？

多选题 · hard

  • A.标签加时刻有效← 正确答案
  • B.时刻加标签有效← 正确答案
  • C.仅时间索引最优
  • D.无需任何索引

答案：AB。(device_id, time DESC) 和 (time, device_id) 两种复合索引在不同查询模式下都有用，前者适合“按设备查时间范围”，后者适合“按时间遍历多设备”。仅时间索引在按设备过滤时会退化，无索引则全分块扫描。

Q10. TimescaleDB 压缩方案的优势有哪些？

多选题 · hard

  • A.大幅降低存储← 正确答案
  • B.查询自动解压← 正确答案
  • C.热块也可压缩
  • D.增加 I/O 开销

答案：AB。列式压缩能将时序数据压缩到原体积的 5%~10%，查询时透明解压，应用无感知。热块压缩会拖慢写入，因此系统只压缩封存块。压缩减少 I/O 而不是增加 I/O，所以 D 错误。