KairosDB 是一个开源的分布式时序数据库(KairosDB)，主要用于存储应用、系统和物联网产生的指标数据。它构建在 Cassandra 等键值存储之上，也支持 HBase 与用于开发的 H2。项目最初是对 OpenTSDB 的改写，采用 Java 编写，提供 Telnet 与 REST API 进行数据写入和查询，并支持聚合与分组，常被用作监控告警系统的后端存储。
定义
KairosDB 是一种时序数据库，用来按时间顺序保存标量数值，并允许为数据点附加标签形式的元数据。与关系数据库通常把某个时刻的单个数值存成一行不同，时序数据库一般把一段时间内的多个数值压缩进同一行，因此行数更少，索引也更容易放进内存，查询效率更高[1]。
它由 Java 编写，以 Cassandra 作为主要底层存储，同时也可运行在 HBase 上，并内置了用于开发的 H2 内存数据库[2]。数据既可以通过 Telnet 协议写入，也可以通过 HTTP 的 REST 接口写入和查询[3]。
原理
KairosDB 采用可插拔的存储引擎设计，底层数据的读写交由 Cassandra 一类的键值数据库完成。在 Cassandra 模式下，它利用宽行特性，把指标名称、行时间戳、数据存储类型以及标签串拼接成行键，行内则按时间偏移组织列，同一个指标的若干周数据被写入同一行。默认行宽设置为 3 周，原因是按毫秒级频率写入 3 周恰好略超过 10 亿列，而 Cassandra 的列上限为 20 亿[2]。
Cassandra 侧的存储结构由多个列族组成，包括保存数据点的 data_points、记录行键的 row_keys、按时间范围索引指标的 row_key_time_index、用于高频标签快速查找的 tag_indexed_row_keys，以及记录系统中全部指标名、标签名和标签值的 string_index 等[4]。查询时先读取索引表得到候选行键，再按标签过滤，最后从数据点表取出实际数值，这种先走索引再取数的方式减少了扫描的数据量。
写入与查询走两套接口。Telnet 端口 4242 接受形如 put 指标名 时间戳 数值 标签 的文本行，时间戳按毫秒或秒解释，小于 3,000,000,000 的数值被当作秒处理[5]。REST 接口默认在 8080 端口，以 JSON 承载数据点与查询，查询结果可按标签、时间范围或数值分组，并叠加内置聚合函数，常用的有平均值、最小值、最大值、计数、求和、标准差、百分位等[6]。查询阶段的聚合与写入阶段的聚合被有意分开，写入时不做事先聚合以保证性能，需要时再把聚合结果回写成新的指标。
发展历程
: KairosDB 的项目在 2013 年 2 月 23 日建立，最初是对 StumbleUpon 发起的 OpenTSDB 项目的改写，因此继承了后者的部分设计思路[7]。改写的主要出发点是把底层存储从 HBase 换到 Cassandra，官方称单节点可达到每秒写入 4 万个数据点[7]。
2013 年 4 月 11 日发布 Beta 1，加入安装包、客户端绘图、Cassandra 与 HBase 双支持、聚合器与分组器以及亚秒级指标等功能；同年 5 月 13 日的 Beta 2 增加了 OAuth 支持与按时间戳或数值分组查询；5 月 24 日发布修正死锁问题的 Beta 2A，并补充跨域资源共享与压缩上传[7]。2013 年 7 月 8 日项目放弃 beta 命名，改为 0.9 版本，随后在 8 月 22 日和 11 月 1 日分别发布 0.9.1 与 0.9.2[7]。
项目代码托管在 GitHub，按 Apache License 2.0 授权发布[8]。运行环境要求 Java 1.8 或更高版本，1.3 及之后的配置格式改用 Hocon[2]。
应用
KairosDB 的典型用途是承载监控指标。官方给出的例子包括记录网站服务器的访问次数，并与 MySQL 数据库的负载均值对照观察[7]。它常与消息队列配合使用，Kafka 一类组件作为前置缓冲，先把采集到的数据接住再转写入库[9]。
在具体系统中，它是 ZMon 分布式监控告警平台的底层时序存储[10]，也出现在 PortaOne 一类的系统中用于替代 RRD 保存统计数据。此外有适配器可以把 Prometheus 采集的指标转发到 KairosDB 存储[11]。
部署方面，KairosDB 自身基本无状态，适合放进 Kubernetes 运行，而它依赖的 Cassandra 在 Kubernetes 中高效运行则相对困难[1]。除 Cassandra 外，它也验证过与兼容 Thrift 接口的 ScyllaDB 配合使用[12]。
局限
KairosDB 依赖外部键值数据库提供存储能力，写入性能会受底层系统制约，且自身没有内置的压缩机制，占用存储空间较大，过期数据需要手动删除[9]。它的查询能力也相对有限，主要提供过滤和聚合，不支持 JOIN 操作。
标签的取值分布对性能影响明显。如果标签值过于离散，行键数量会大幅膨胀，导致查询性能下降，这与底层的存储结构直接相关[9]。此外，Cassandra 模式下首次创建集群时确定的行宽与时间粒度在 schema 建立后无法更改，需要事先规划[4]。
默认的 H2 存储速度较慢，官方定位是便于开发者在不必搭建 Cassandra 的情况下进行开发，不适合用于生产环境，后续版本也在逐步削减对 H2 的支持[2]。聚合回写功能在较早版本中按单个节点配置，节点之间不共享状态。
参见
参考资料
- Frequently Asked Questions¶ [引用日期2026-10-14]
- Getting Started¶ [引用日期2026-10-14]
- Pushing data¶ [引用日期2026-10-14]
- Cassandra Schema¶ [引用日期2026-10-14]
- Put — KairosDB 1.3.0 documentation [引用日期2026-10-14]
- Features¶ [引用日期2026-10-14]
- google.com 上的网页 [引用日期2026-10-14]
- Software:KairosDB [引用日期2026-10-14]
- KairosDB H2 vs Cassandra [引用日期2026-10-14]
- KairosDB¶ [引用日期2026-10-14]
- MSc Thesis Betchavas(PDF) [引用日期2026-10-14]
- Using KairosDB with ScyllaDB [引用日期2026-10-14]