OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本

欢迎访问OceanBase官网获取更多信息:https://www.oceanbase.com/

CeresDB 是一款拥有计算存储分离架构的分布式时序数据库,其存储层可以基于 OceanBase KV、OSS 等。经过近一年的开源研发工作,CeresDB 1.0 现已正式发布,达到生产可用标准。


CeresDB 团队已经在时序数据领域进行了 5 年的深耕。但是随着在领域内研究的深入以及用户场景的逐渐复杂化,我们发现了若干传统时序数据库尚未很好解决的一些技术问题,比如:

  • 高效处理高基数 Tag 组合(时间线膨胀问题)与分析型工作负载
  • 现代且完备的分布式技术方案
  • 云原生与计算存储分离

因此,CeresDB 开源项目发起之初,我们就将其定义为下一代的云原生时序数据库。希望它能同时较好支持传统时间序列工作负载(timeseries workload)与分析型工作负载(analytic workload),并且能拥有一个现代的云原生分布式技术架构,支持从简单的单节点到庞大分布式集群等各种部署场景。

这样的设计目标,也直接决定了我们过去一年在研发 CeresDB 1.0 过程中主要的精力投入方向。目前,随着 CeresDB 1.0 的正式发布,我们认为以上问题均得到了基本的解决。

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 在过去一年投入的几个重点方向的技术方案,由于篇幅限制,这里仅作简要说明。

▋ 存储引擎探索

经典时序模型会使用倒排索引的方式对数据进行组织。然而在某些场景如短生命周期 pod 监控、业务数据监控等,会产生高基数时间线,进而导致倒排索引膨胀问题,写入查询性能会急剧变差。

  • 写入时由于索引的复杂性高,写入耗时变高

  • 查询时由于索引的有效性低,查询耗时变高

下图为经典时序模型的示意图:

OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本_第1张图片

为了解决高基数的问题,CeresDB 受 InfluxDB IOx 以及各类分析型数据库的启发,采用以下方式对时序数据进行组织来实现存储和查询:

  • 列式存储 + 混合存储

  • 分区扫描 + 剪枝 + 高效 fitler

下图展示了 CeresDB 内部的数据组织形式:

OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本_第2张图片

▋ 分布式方案

CeresDB 采用存储计算分离架构,如下图所示。CeresDB 实例本身可以不存储任何数据,在此基础上可以较好实现关键的几项分布式特性,比如:计算存储弹性扩缩容、服务高可用和负载均衡等等。

OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本_第3张图片

CeresDB 分布式集群主要由以下部分组成:

CeresMeta Cluster:集群的元数据中心,负责集群的整体调度;
CeresDB:一个 CeresDB 实例, 负责时序数据组织与存储;
WAL Service(外部):WAL 服务,在集群方案中,用于存储实时写入的数据;
Object Storage(外部):对象存储服务,用于存储从 memtable 生成的 SST 文件。

详细的集群方案可以参看官方文档:https://docs.ceresdb.io/cn/design/clustering.html

性能优化与实验结果

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。

OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本_第4张图片
Influxdb

OceanBase 生态产品:时序数据库CeresDB 正式发布 1.0 版本_第5张图片
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 在不同工作负载下的表现

▋ 分布式

自动负载均衡

提高可用性、可靠性

*代码主仓库的 GitHub 地址为:https://github.com/CeresDB/ceresdb

*CeresDB 1.0 官方文档:https://docs.ceresdb.io

欢迎访问OceanBase官网获取更多信息:https://www.oceanbase.com/

你可能感兴趣的:(新闻动态,oceanbase,时序数据库,rust)