概述
时序数据库（Time-Series Database）针对物联网场景中设备按时间戳上报的传感器数据优化，是物联网数据存储的核心。与关系型数据库按行存储不同，时序数据库采用列式存储、时间分区、专用压缩算法，利用时序数据"时间有序、多测点、高写入、范围查询为主"的特点，实现百万点/秒的写入吞吐与毫秒级的时间范围查询。在能源监控、工业采集、环境监测、智能表计等场景中，时序数据库是不可替代的存储引擎。
物联网时序数据的特点：数据点以(设备, 指标, 时间戳, 值)形式产生，同一设备的多个指标常一起上报；查询多为"某设备某指标在某时间范围的聚合或明细"；数据具有时效性，近期数据热、历史数据冷。时序数据库针对这些特点做了存储、索引、查询的专门优化。
核心特性
高写入与压缩
百万点/秒写入，支持批量写入（Batch Insert）优化。列式存储+Delta编码+压缩算法，压缩比可达10:1以上。按时间分区，便于过期删除与并行查询。
降采样与聚合
内置AVG、SUM、MAX、MIN等聚合函数。支持降采样：将1分钟粒度数据聚合为1小时、1天，减少存储与加速大范围查询。支持连续查询（Continuous Query）自动预聚合。
保留策略与分层
按时间自动过期删除（如保留90天）。支持热数据SSD、冷数据HDD分层存储。与数据微服务、流式处理、数据可视化紧密集成。
典型产品与选型
InfluxDB：开源流行，生态丰富。TDengine：国产、高性能、压缩比高，物联网场景表现突出。TimescaleDB：基于PostgreSQL的扩展，SQL兼容好。OpenTSDB：基于HBase，适合大数据生态。选型需考虑写入性能、查询能力、压缩比、运维成本、与现有技术栈的集成。
时间戳序列的存储布局
测点以时间为主键被压缩存放
时序库把“谁、在什么时间、测到什么”按时间相邻的关系存放，写入以追加为主，查询按时间范围读取，并利用相邻点的差值做压缩。它服务的是一段时间内的明细或聚合，不承担任意字段上的事务更新。设备档案和客户合同留在关系库，图片与镜像留在对象存储。库里的标签用来过滤设备或测点，标签的取值应稳定，而且种类有限。
同一设备同时上报的多个测点，可以落在同一行的多个列，也可以拆成多条系列。列多而稀疏时，查询一个测点会读进大量空列。系列拆得过细时，一次取出该设备的全部测点又要合并太多系列。布局按主要查询来定：是单测点的长时间范围，还是同一时刻的多个测点。单位在入库前换算完。库里同时存在摄氏和华氏、秒和毫秒时，聚合函数无法判断哪一个值可用。单位和空值的整理见数据清洗。
降采样与保留期要一起设计
原始精度只在近期有追查价值、远期只看趋势时，才做降采样。连续查询或外部作业按小时、按天写出粗粒度系列，原始系列单独使用较短的保留期。粗粒度用哪一个函数要先和业务核对：电量用求和，温度除了均值还要另存极值，状态量不能用均值冒充“多数时间所处的状态”。
保留期到期是删除，不是自动归档。审计仍需要原始点时，应在到期前导出，并记下导出的时间范围和校验。热数据与冷数据分层后，跨层查询要允许更长的响应，接口不能对冷数据承诺和热数据相同的时延。库内连续查询和库外作业只能保留一个写入口，避免两个过程同时写同一条粗粒度系列。导出文件的存放方式见分布式存储，键里带上时间范围，便于以后按段取回。
时间戳单位、乱序和标签基数
有的设备用秒，有的用毫秒，有的用未带时区的本地时间字符串。入库若不统一精度和时区，点会落在 1970 年附近，或被放大后落到遥远的未来，分区被撑出大量空块。写入接口应拒绝无法解析的时间，而不是写入零时刻。乱序点超过库允许的窗口时，可能被拒绝，或写进错误的压缩块，查询曲线出现回跳。超窗点进入拒收日志，等设备校时后再补。
标签基数是另一类容量问题。把每次请求的随机标识、完整报文或不断增长的告警文案放进标签，索引会随设备数乘上文案种类膨胀，压缩也失效。标签只放用来过滤的有限枚举，变化频繁的内容放进测点值。删除设备后若不处理其系列，旧系列仍占着保留期内的空间。设备主数据的删除清单和时序过期要用同一份名单。查询若对很长的时间跨度直接要全部设备的原始点，会绕开为降采样准备的系列。接口应按跨度强制走粗粒度系列。