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 在不同工作负载下的表现
分布式
-
自动负载均衡
-
提高可用性、可靠性
