CeresDB 1.0 正式发布，Rust 高性能云原生时序数据库

CeresDB 是一款高性能、分布式的云原生时序数据库，采用 Rust 编写。其开发团队近日宣布：经过近一年的开源研发工作，时序数据库 CeresDB 1.0 正式发布，达到生产可用标准。

CeresDB 1.0 官方中文文档：https://docs.ceresdb.io/cn/

---

CeresDB 1.0 核心特性介绍

存储引擎

• 支持列式混合存储

• 高效 XOR 过滤器

云原生分布式

• 实现了计算存储分离（支持 OSS 作为数据存储，WAL 实现支持 OBKV、Kafka）

• 支持 HASH 分区表

部署与运维

• 支持单机部署

• 支持分布式集群部署

• 支持 Prometheus + Grafana 搭建自监控

读写协议

• 支持 SQL 查询与写入

• 实现了 CeresDB 内置高性能读写协议，提供多语言 SDK

• 支持 Prometheus，可以作为 Prometheus 的 remote storage 进行使用

多语言读写 SDK

• 实现了四种语言的客户端SDK：Java、Python、Go、Rust

---

CeresDB 架构介绍

CeresDB 是一个时序数据库，与经典时序数据库相比，CeresDB 的目标是能够同时处理时序型和分析型两种模式的数据，并提供高效的读写。

在经典的时序数据库中，Tag列（InfluxDB称之为Tag，Prometheus称之为Label）通常会对其生成倒排索引，但在实际使用中，Tag的基数在不同的场景中是不一样的 ———— 在某些场景下，Tag的基数非常高（这种场景下的数据，我们称之为分析型数据），而基于倒排索引的读写要为此付出很高的代价。而另一方面，分析型数据库常用的扫描 + 剪枝方法，可以比较高效地处理这样的分析型数据。

因此 CeresDB 的基本设计理念是采用混合存储格式和相应的查询方法，从而达到能够同时高效处理时序型数据和分析型数据。

下图展示了 CeresDB 单机版本的架构

 ┌──────────────────────────────────────────┐ │ RPC Layer (HTTP/gRPC/MySQL) │ └──────────────────────────────────────────┘ ┌──────────────────────────────────────────┐ │ SQL Layer │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Parser │ │ Planner │ │ │ └─────────────────┘ └─────────────────┘ │ └──────────────────────────────────────────┘ ┌───────────────────┐ ┌───────────────────┐ │ Interpreter │ │ Catalog │ └───────────────────┘ └───────────────────┘ ┌──────────────────────────────────────────┐ │ Query Engine │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Optimizer │ │ Executor │ │ │ └─────────────────┘ └─────────────────┘ │ └──────────────────────────────────────────┘ ┌──────────────────────────────────────────┐ │ Pluggable Table Engine │ │ ┌────────────────────────────────────┐ │ │ │ Analytic │ │ │ │┌────────────────┐┌────────────────┐│ │ │ ││ Wal ││ Memtable ││ │ │ │└────────────────┘└────────────────┘│ │ │ │┌────────────────┐┌────────────────┐│ │ │ ││ Flush ││ Compaction ││ │ │ │└────────────────┘└────────────────┘│ │ │ │┌────────────────┐┌────────────────┐│ │ │ ││ Manifest ││ Object Store ││ │ │ │└────────────────┘└────────────────┘│ │ │ └────────────────────────────────────┘ │ │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ │ Another Table Engine │ │ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ └──────────────────────────────────────────┘ 

---

性能优化与实验结果

CeresDB 组合使用了列式混合存储、数据分区、剪枝、高效扫描等技术，解决海量时间线（high cardinality）下写入查询性能变差的问题。

写入优化

CeresDB 采用类 LSM（Log-structured merge-tree）写入模型，无需在写入时处理复杂的倒排索引，因此写入性能上较好。

查询优化

主要采用以下技术手段提高查询性能：

剪枝：

• min/max 剪枝：构建代价比较低，在特定场景，性能较好

• XOR 过滤器：提高对 parquet 文件中的 row group 的筛选精度

高效扫描：

• 多个 SST 间并发：同时扫描多个 SST 文件

• 单个 SST 内部并发：支持 Parquet 层并行拉取多个 row group

• 合并小 IO：针对 OSS 上的文件，合并小 IO 请求，提高拉取效率

• 本地 cache：缓存 OSS 拉取文件，支持内存和磁盘缓存

性能测试结果

采用 TSBS 进行性能测试。压测参数如下：

• 10个 Tag

• 10 个 Field

• 时间线（Tags 组合数）100w 量级

压测机器配置：24c90g

InfluxDB 版本：1.8.5

CeresDB 版本：1.0.0

写入性能对比

InfluxDB 写入性能随着时间下降较多。CeresDB 在写入稳定后，写入速率趋于平稳，并且总体写入性能表现为 InfluxDB 的 1.5 倍以上（一段时间后可达 2 倍以上差距）

下图中，单行 row 包含 10 个 Field。

上图为Influxdb，下图为CeresDB

查询性能对比

低筛选度条件（条件：os=Ubuntu15.10），CeresDB 比 InfluxDB 快 26 倍，具体数据如下：

• CeresDB 查询耗时：15s

• InfluxDB 查询耗时：6m43s

高筛选度条件（命中的数据较少，条件：hostname=[8个]，此时理论上传统倒排索引会更有效），这是 InfluxDB 更有优势的场景，此时在预热完成条件下，CeresDB 比 InfluxDB 慢 5 倍。

• CeresDB：85ms

• InfluxDB：15ms

---

2023 年 roadmap

开发团队表示，2023 年，在 CeresDB 1.0 发布之后，他们大部分工作将聚焦在性能、分布式与周边生态方面的工作。尤其周边生态的对接支持工作，希望能让各种不同的用户更加简单的用上 CeresDB：

周边生态

• 生态兼容，包括 PromQL、InfluxdbQL、OpenTSDB 等常用时序数据库协议兼容

• 运维工具支持，包括 k8s 支持、CeresDB 运维系统、自监控等

• 开发者工具，包括数据导入导出等

性能

• 探索新的存储格式

• 增强不同类型索引，强化 CeresDB 在不同工作负载下的表现

分布式

• 自动负载均衡

• 提高可用性、可靠性