歡迎訪問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 監控、業務資料監控等，會產生高基數時間線，進而導致倒排索引膨脹問題，寫入查詢效能會急劇變差。

- 寫入時由於索引的複雜性高，寫入耗時變高

- 查詢時由於索引的有效性低，查詢耗時變高

下圖為經典時序模型的示意圖：

![Image](https://img.alicdn.com/imgextra/i2/O1CN017WCT4Y1zoacRiROQJ_!!6000000006761-2-tps-612-135.png)

為瞭解決高基數的問題，CeresDB 受 InfluxDB IOx 以及各類分析型資料庫的啟發，採用以下方式對時序資料進行組織來實現儲存和查詢：

- 列式儲存 + 混合儲存

- 分割槽掃描 + 剪枝 + 高效 fitler

下圖展示了 CeresDB 內部的資料組織形式：

![Image](https://img.alicdn.com/imgextra/i3/O1CN01UWcOPV1OHUD1GH8jV_!!6000000001680-2-tps-435-398.png)

#### ▋ 分散式方案

CeresDB 採用儲存計算分離架構，如下圖所示。CeresDB 例項本身可以不儲存任何資料，在此基礎上可以較好實現關鍵的幾項分散式特性，比如：計算儲存彈性擴縮容、服務高可用和負載均衡等等。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01DrN6Uw2AGf3NB7x4F_!!6000000008176-2-tps-612-286.png)

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。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01vARud01uPn60A7UQF_!!6000000006030-2-tps-445-222.png)
Influxdb

![Image](https://img.alicdn.com/imgextra/i3/O1CN01cm85yd1pc5eZFGokN_!!6000000005380-0-tps-405-254.jpg)
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 生態產品：時序資料庫CeresDB 正式釋出 1.0 版本

相關文章