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 在不同工作负载下的表现
分布式
-
自动负载均衡
-
提高可用性、可靠性
还没有评论,来说两句吧...