# 1. 时序数据的特点，高写入吞吐、按时间范围查询、数据生命周期管理（降采样、删除、冷热分层）的工程挑战？ A 时序数据写入是随机更新型负载，因此需要优先优化随机读写性能 B 时序数据的生命周期管理只需关注当前数据，无需考虑降采样与冷热分层 C 时序数据以时间戳为主键、追加式写入，因此写入路径应针对顺序写与批量写优化 ✓ 正确答案 D 时序数据库的查询与关系型数据库一样，以随机点查为主
# 2. 时序数据库核心引擎，InfluxDB（TSM）、TimescaleDB（Chunk + 连续聚合）、Prometheus（TSDB）、QuestDB 的架构对比？ A TimescaleDB 的 hypertable + chunk 模型本质是 PostgreSQL 之上的扩展，利用 chunk 按时间切分数据 ✓ 正确答案 B InfluxDB 的 TSM 引擎是一个并发安全的关系型存储引擎 C Prometheus TSDB 采用列式存储并支持 ANSI SQL 查询 D QuestDB 采用行式追加存储，不支持向量化查询执行
# 3. 时序数据库的存储分层，热数据（内存/SSD）与冷数据（对象存储）的迁移与查询透明化 A 热冷分层仅能由用户手动指定，无法自动迁移 B 冷层数据只能用对象存储，且必须解压后才能查询 C 查询透明化的核心是元数据层记录数据分区的位置，按需路由到对应存储层 ✓ 正确答案 D 热数据不需要压缩，冷数据才需要压缩
# 4. TDengine 的“一设备一表 + 超级表（STABLE）+ 子表（Subtable）”三级模型如何组织海量 IoT 时序数据？为什么标签（Tag）要与数据列分离存储，按标签过滤/分组聚合在查询与存储上各带来什么收益，ALTER STABLE 在线加列/加标签如何传播到所有子表？ A 标签与数据列分离存储使数据列紧凑连续、标签索引高效，便于按标签过滤与分组聚合 ✓ 正确答案 B 超级表是存储表的物理实现，子表必须单独存储数据列 C 标签与数据列混存可以提高查询效率 D ALTER STABLE 加列只会影响新创建的子表，旧子表需手动重建
# 5. 降采样（Downsampling）与连续聚合（Continuous Aggregates）的查询加速，TimescaleDB 的 hypertable + chunk 的实现原理？ A 连续聚合每次刷新都重新计算整个历史数据 B 降采样只减少存储占用，对查询速度没有帮助 C hypertable 按时间切分为 chunk，查询通过 chunk 裁剪跳过无关分区 ✓ 正确答案 D 连续聚合只能在查询时临时计算，不支持物化存储
# 6. 时序写入路径优化，列式编码、倒排索引与 WAL 批量写入如何支撑高吞吐，写入放大与查询放大如何权衡？ A WAL 批量写入通过顺序追加与批量合并减少随机 IO，从而降低写入放大 ✓ 正确答案 B 列式编码提高了存储压缩率，但会显著增加查询时的扫描量 C 倒排索引只增加写入开销，对查询过滤没有帮助 D 压缩是免费的，不会增加任何写入端开销
# 7. 时序压缩算法，Gorilla（浮点 XOR）、Delta-Delta 与字典编码的压缩比与解码开销，为什么时序数据压缩率高？ A 时序数据压缩率高的原因是数据随机性大、熵高 B Delta-Delta 编码对时间戳做一阶差分即可，不需要二阶差分 C 字典编码适合浮点测量值，不适合离散状态字段 D Gorilla 压缩利用相邻浮点值 XOR 结果高位相似的特点，用较少比特表示变化 ✓ 正确答案
# 8. 时序数据的写入优化，按时间分区、批量写入与 WAL？ A WAL 的作用是随机写入数据，以提升写入吞吐 B 按时间分区使写入追加有序，并支持按时间范围裁剪查询与独立压缩清理 ✓ 正确答案 C 批量写入会增加系统调用次数，降低写入性能 D 按时间分区后无法实现独立过期删除
# 9. 时序数据库的压缩，Gorilla 浮点压缩与 Delta 编码？ A Gorilla 压缩利用相邻浮点值 XOR 的规律，Delta 编码利用相邻值差值的规律 ✓ 正确答案 B Gorilla 压缩针对时间戳，Delta 编码针对浮点测量值 C Delta 编码适合数值随机跳变的场景 D Gorilla 与 Delta 编码不能在同一列中组合使用
# 10. 时序数据库对乱序（out-of-order）写入的处理，缓存、合并与查询一致性 A 乱序写入不会破坏有序追加假设，无需特殊处理 B 查询时无需处理乱序数据，因为落盘后自然有序 C 乱序数据会被直接丢弃，以保证查询性能 D 系统通过缓存暂存乱序数据、后台合并归并，并在查询时按时间戳归并保证一致 ✓ 正确答案
# 11. 标签基数治理，标签命名规范、基数监控与索引内存控制 A 标签基数过高会导致索引膨胀与内存占用激增，需通过规范、监控与内存控制治理 ✓ 正确答案 B 用户 ID、请求 ID 等高基数变化量适合作为标签，便于过滤 C 倒排索引通常不驻留内存，因此基数高低不影响内存占用 D 标签命名规范对索引内存没有影响
# 12. 时序数据的高基数（High Cardinality）问题，标签爆炸对索引与内存的影响与缓解？ A 高基数主要由标签取值组合爆炸导致，会使索引内存膨胀并拖慢查询，应减少标签或把高基数维度移出标签 ✓ 正确答案 B 标签组合越多，序列总数越多，索引与内存占用越小 C 高基数问题只影响查询速度，不影响内存占用 D 增加标签数量可以缓解高基数问题
# 13. IoT 场景下时序数据库与消息队列（Kafka）的边界，写入路径与查询路径的分层架构？ A Kafka 负责结构化数据持久化与压缩，时序数据库负责高吞吐缓冲 B 典型的写入路径是设备经 Kafka 缓冲后进入时序数据库，Kafka 负责解耦与缓冲，时序库负责存储查询 ✓ 正确答案 C Kafka 与时序数据库功能完全重叠，可以任选其一 D 查询路径必须经过 Kafka 才能访问时序数据库
# 14. 查询语言差异，PromQL 与 InfluxQL 的函数与聚合语义差异，跨库迁移的改写成本？ A PromQL 与 InfluxQL 的函数与聚合语义完全一致，可直接迁移 B PromQL 以向量为操作对象，InfluxQL 以 SQL 风格的时间窗口聚合为核心，二者语义差异导致跨库迁移需要重写查询 ✓ 正确答案 C InfluxQL 也以即时向量为基本操作对象 D PromQL 的 rate 函数与 InfluxQL 的 rate 函数语义完全相同
# 15. 时序选型与基准，TSBS 等基准场景下 InfluxDB/TimescaleDB/Prometheus/QuestDB 的写入与查询差异如何影响选型？ A TSBS 基准结果可以完全替代业务需求分析 B TSBS 提供统一的 IoT 与监控场景负载，可量化各引擎差异，但选型还应结合业务场景与生态综合判断 ✓ 正确答案 C 所有时序引擎在 TSBS 各场景下表现完全相同 D TSBS 只测写入吞吐，不测查询延迟与存储占用
# 16. 时序数据的降采样与保留策略，压缩与过期删除？ A 保留策略只保留原始数据，不做降采样 B 降采样可减少数据量，保留策略以分区为单位自动过期删除，二者共同管理数据生命周期 ✓ 正确答案 C 过期删除必须逐条删除，成本很高 D 降采样不会减少存储成本
# 17. 时序查询模式，范围查询、降采样与聚合下推？ A 范围查询需要全表扫描才能定位数据 B 聚合下推把聚合操作下推到存储层执行，只返回聚合结果，减少传输与计算 ✓ 正确答案 C 降采样会增加查询返回的数据量 D 聚合下推无法与范围查询配合使用
# 18. 时序数据的聚合下推，预聚合与连续查询？ A 聚合下推必须在查询时实时扫描全部原始数据 B 预聚合会增加每次查询的计算量 C 连续查询只在用户手动触发时执行一次 D 连续查询按周期自动计算并物化聚合结果，使后续查询命中预聚合数据，从而降低查询延迟 ✓ 正确答案
# 19. 时序数据库选型对比，InfluxDB/Prometheus/TimescaleDB？ A InfluxDB 不支持标签与保留策略 B 三者都是通用的关系型数据库，选型无差别 C TimescaleDB 使用 PromQL 作为查询语言 D Prometheus 面向监控与告警、深度集成云原生生态，适合监控场景；TimescaleDB 适合需要 SQL 与关系融合的场景 ✓ 正确答案
# 20. 时序数据的时间戳精度（纳秒 vs 毫秒）对存储与查询的影响 A 时间戳精度越高，存储占用越小 B 越高精度的时间戳需要更大整数表示，可能降低压缩率、增加存储与索引开销，应根据业务需要选精度 ✓ 正确答案 C 纳秒级时间戳与毫秒级在存储与压缩上完全等价 D 时间戳精度不影响分区粒度与索引
