时序数据库 CeresDB 1.0 正式发布
经过近一年的开源研发工作，我们很高兴地和大家同步：时序数据库 CeresDB 1.0 正式发布，达到生产可用标准。
代码主仓库的GitHub 地址为：https://github.com/CeresDB/ceresdb
CeresDB 1.0 官方文档：https://docs.ceresdb.io
1.
设计目标
CeresDB 团队已经在时序数据领域进行了5年的深耕。但是随着在领域内研究的深入以及用户场景的逐渐复杂化，我们发现了若干传统时序数据库尚未很好解决的一些技术问题，比如：
高效处理高基数 Tag 组合（时间线膨胀问题）与分析型工作负载
现代且完备的分布式技术方案
云原生与计算存储分离
因此，CeresDB 开源项目发起之初，我们就将其定义为下一代的云原生时序数据库。希望它能同时较好支持传统时间序列工作负载（timeseries workload）与分析型工作负载（analytic workload），并且能拥有一个现代的云原生分布式技术架构，支持从简单的单节点到庞大分布式集群等各种部署场景。
这样的设计目标，也直接决定了我们过去一年在研发 CeresDB 1.0 过程中主要的精力投入方向。目前，随着 CeresDB 1.0 的正式发布，我们认为以上问题均得到了基本的解决。
2.
CeresDB 1.0 核心特性介绍
存储引擎
支持列式混合存储
高效 XOR 过滤器
云原生分布式
实现了计算存储分离（支持 OSS 作为数据存储，WAL 实现支持 OBKV、Kafka）
支持 HASH 分区表
部署与运维
支持单机部署
支持分布式集群部署
支持 Prometheus + Grafana 搭建自监控
读写协议
支持 SQL 查询与写入
实现了 CeresDB 内置高性能读写协议，提供多语言 SDK
支持 Prometheus，可以作为 Prometheus 的 remote storage 进行使用
多语言读写 SDK
实现了四种语言的客户端SDK：Java、Python、Go、Rust
3.
核心技术方案
这里简单介绍一下 CeresDB 在过去一年投入的几个重点方向的技术方案。由于篇幅限制，这里仅作简要说明。本文的最后包含 CeresDB 发布会技术分享视频，里面有更加详细的介绍。
存储引擎探索
经典时序模型会使用倒排索引的方式对数据进行组织。然而在某些场景如短生命周期 pod 监控、业务数据监控等，会产生高基数时间线，进而导致倒排索引膨胀问题，写入查询性能会急剧变差。
写入时由于索引的复杂性高，写入耗时变高
查询时由于索引的有效性低，查询耗时变高
下图为经典时序模型的示意图：
为了解决高基数的问题，CeresDB 受 InfluxDB IOx 以及各类分析型数据库的启发，采用以下方式对时序数据进行组织来实现存储和查询：
列式存储 + 混合存储
分区扫描 + 剪枝 + 高效 fitler
下图展示了 CeresDB 内部的数据组织形式：
分布式方案
CeresDB 采用存储计算分离架构，如下图所示。CeresDB 实例本身可以不存储任何数据，在此基础上可以较好实现关键的几项分布式特性，比如：计算存储弹性扩缩容、服务高可用和负载均衡等等。
CeresDB 分布式集群主要由以下部分组成：
CeresMeta Cluster：集群的元数据中心，负责集群的整体调度；
CeresDB：一个 CeresDB 实例, 负责时序数据组织与存储；
WAL Service（外部）：WAL 服务，在集群方案中，用于存储实时写入的数据；
Object Storage（外部）：对象存储服务，用于存储从 memtable 生成的 SST 文件。
详细的集群方案可以参看官方文档（https://docs.ceresdb.io/cn/design/clustering.html）
4.
性能优化与实验结果
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
5.
2023 年 roadmap
2023 年，在 CeresDB 1.0 发布之后，我们的大部分工作将聚焦在性能、分布式与周边生态方面的工作。尤其周边生态的对接支持工作，希望能让各种不同的用户更加简单的用上 CeresDB：
周边生态
生态兼容，包括 PromQL、InfluxdbQL、OpenTSDB 等常用时序数据库协议兼容
运维工具支持，包括 k8s 支持、CeresDB 运维系统、自监控等
开发者工具，包括数据导入导出等
性能
探索新的存储格式
增强不同类型索引，强化 CeresDB 在不同工作负载下的表现
分布式
自动负载均衡
提高可用性、可靠性
6.
加入我们
CeresDB 团队致力于将开源社区打造成一个开放和有创造力的社区。欢迎任何形式的参与，包括且不限于提问、代码贡献、技术讨论等。期待收到社区想法和反馈，以推动项目往前进一步发展。
邮箱: ceresdbservice@gmail.com
微信群：
钉钉群: