最近我们在做一件事：把指标数据从 ByConity 迁移到 VictoriaMetrics（VM） 。
过程中重新梳理了 ClickHouse、ByConity、Prometheus、VictoriaMetrics 这四种存储的定位和差异。这篇文章把我的理解、对比图和迁移思考整理出来，方便后续选型和复盘。
一、先说结论：我最初的理解对，但不够本质
我一开始的理解是：
- ByConity 适合列式存储，比如海量日志数据；
- VM Storage 适合时序类型数据，比如指标数据。
按照官方定义，更准确的表述如下：
ByConity 本质是分析型数据仓库 ，强在日志、宽表、复杂 SQL 分析；
VictoriaMetrics 本质是专为时序设计的数据库，强在指标高吞吐写入、高压缩、PromQL 查询。
所以两者不是简单的"列式 vs 时序"，而是为完全不同工作负载做了深度优化 。
这也是为什么我们决定：日志和分析数据继续留在 ByConity，指标数据迁到 VictoriaMetrics。
二、四种存储的定位与核心差异
这四种存储大致可以分成两条路线：
- 分析型 / 列式路线：ClickHouse、ByConity
- 时序 / 指标路线：Prometheus、VictoriaMetrics
具体来看：
- ClickHouse：列式 OLAP 标杆，查询快，但存算一体。
- ByConity：基于 ClickHouse 内核，升级为存算分离，适合云上弹性分析。
- Prometheus：监控事实标准，PromQL 生态强，但大规模长期存储吃力。
- VictoriaMetrics：兼容 PromQL，专为大规模指标长期存储优化。
它们不是互相替代的关系，而是分别服务于不同的数据形态和查询模式。
三、ClickHouse vs ByConity：存算一体 vs 存算分离
1. ClickHouse 像"前店后厂"小作坊
text
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 节点 A │ │ 节点 B │ │ 节点 C │
│ 计算+存储 │ │ 计算+存储 │ │ 计算+存储 │
│ 本地磁盘 │ │ 本地磁盘 │ │ 本地磁盘 │
└─────────────┘ └─────────────┘ └─────────────┘
问题：
- 扩缩容要搬数据
- 写入和查询抢 CPU / 磁盘
- 为峰值买机器，闲时浪费2. ByConity 像"中央仓库 + 弹性工厂"
text
┌──────────────────────────┐
│ 计算层（无状态） │
│ 不够就加，多了就减 │
│ 读写分离，互不干扰 │
└───────────┬──────────────┘
│
┌───────────▼──────────────┐
│ 共享存储：S3 / HDFS │
│ 便宜、容量大、统一仓库 │
└──────────────────────────┘ByConity 省钱的核心逻辑：
text
原来：为峰值买 10 台机器，平时只用 3 台 → 7 台浪费
现在：存储放 S3，计算按需 3~10 台 → 只付实际用的所以"成本降低 50%"不是魔法，而是资源利用率上去了 。
云上配合定时扩缩容，常见能省 40%～50%。
3. ByConity 对 ClickHouse 的关键优化
| ClickHouse 痛点 | ByConity 解法 | 效果 |
|---|---|---|
| 存算一体 | 存算分离 | 存储用便宜对象存储，计算弹性伸缩 |
| 扩缩容搬数据 | 计算节点无状态 | 秒级扩缩容，无需数据迁移 |
| 读写抢资源 | 读写分离 / Virtual Warehouse | 写入查询互不干扰 |
| 远程 I/O 慢 | 本地 Disk Cache、Cache-aware 调度 | 弥补存算分离延迟 |
| 复杂查询弱 | CBO / RBO 优化器 | 复杂 Join、分析更强 |
四、Prometheus vs VictoriaMetrics：都会压缩，VM 更极致
1. Prometheus 的 Gorilla 压缩
Prometheus 并不是不压缩，它基于 Gorilla 算法：
- 时间戳：Delta-of-Delta 编码，利用采集间隔规律；
- 数值：XOR 编码，利用相邻值变化小。
效果：
text
原始数据：16 字节 / 点
Prometheus 压缩后：约 1.37 字节 / 点
压缩率已经超过 90%2. VictoriaMetrics 把压缩做到更极致
text
Prometheus：
时间戳：10:00:00 10:00:15 10:00:30 10:00:45
值： 12.1 12.2 12.2 12.3
存法：[完整时间戳][完整值] ...
占用：约 1.37 字节 / 点
VictoriaMetrics：
基准：10:00:00, 12.1
间隔：15秒、15秒、15秒
变化：+0.1、0、+0.1
存法：[基准][间隔规律][值的小变化] ...
占用：约 0.4 字节 / 点注意：VM 物理底层存的是变化量/差值，但逻辑上仍然保存完整时间序列点。
查询时它会解码还原原始样本，不是只存"变化事件"。
3. 效果对比
text
同样 100GB 指标数据：
Prometheus：████████████████████ 100GB
VictoriaMetrics：████ 30~40GB| 维度 | Prometheus | VictoriaMetrics |
|---|---|---|
| 压缩算法 | Gorilla | Delta-of-Delta 等更极致优化 |
| 每点占用 | 约 1.37 字节 | 约 0.4 字节 |
| 查询延迟 | 约 1.2 秒 | 约 0.2 秒 |
| 内存占用 | 100% | 约 50% |
| CPU 使用 | 100% | 约 70% |
| 集群能力 | 联邦 / 远程读 | 原生集群，Shared-Nothing |
| 适合场景 | 中小规模监控 | 大规模、长期指标存储 |
这里的关键差异是：
Prometheus 已经会压缩，VictoriaMetrics 是在它基础上又向前多走了一大步。
五、四种存储总览对比表
| 维度 | ClickHouse | ByConity | Prometheus | VictoriaMetrics |
|---|---|---|---|---|
| 本质定位 | 列式 OLAP | 云原生数据仓库 | 监控 TSDB | 高性能 TSDB |
| 核心负载 | 日志、复杂分析 | 日志、分析、多租户 | 监控指标 | 指标长期存储 |
| 数据模型 | 宽表 | 宽表 | Metric + Labels | Metric + Labels |
| 写入模式 | 支持更新/删除 | 支持更新/删除 | 纯追加 | 纯追加 |
| 查询语言 | SQL | SQL | PromQL | PromQL 兼容 |
| 架构 | 存算一体 | 存算分离 | 本地 TSDB | Shared-Nothing 集群 |
| 压缩 | 列存压缩 | 列存压缩 | Gorilla，约 1.37B/点 | 约 0.4B/点 |
| 扩展性 | 分片集群 | 计算存储独立弹性 | 联邦/远程读 | 原生集群 |
| 典型场景 | 日志分析 | 云上日志/分析 | 中小监控 | 大规模指标监控 |
| 适合指标？ | 可但不专 | 可但不专 | 是 | 是，更优 |
六、ByConity 能存指标数据吗？比如 CPU、JVM
技术上可以，但它并非为这个场景而设计。
把指标数据放在 ByConity 里，就像用卡车去跑短途快递------能跑，但油耗和成本都不划算。
1. ByConity 为时序数据做了什么？
ByConity 基于 ClickHouse 内核，确实具备一些处理时序数据的基础能力：
- 专用压缩编码 ：支持
DoubleDelta（针对时间戳）和Gorilla（针对数值）等编码，对时序数据有不错的压缩效果。 - 原生时间类型 ：提供
Date、DateTime、TIMESTAMP等数据类型，便于按时间分区和管理。 - 唯一键（Unique Key） ：支持
UPSERT语义，可以处理指标数据的更新或去重。
2. 为什么不推荐用它存指标？
尽管有上述能力，ByConity 的核心定位是云原生数据仓库 ，专为交互式查询、多表关联和即席分析设计。用它存指标，会面临几个结构性矛盾：
① 架构"重"，不适合高频小写入
指标数据通常是高频、小批量的追加写入 。而 ByConity 的存算分离架构虽然弹性好，但每次写入都可能涉及与远端存储的交互，其分布式事务和元数据管理（依赖 FoundationDB） 也为复杂分析设计，用于纯追加的时序场景显得过重。
② 查询生态"不匹配"
监控告警和看板依赖 PromQL 。ByConity 使用 SQL ，这意味着你需要把 rate()、sum_over_time() 等 PromQL 逻辑重写成 SQL，并自行维护一套复杂的聚合查询，无法直接复用 Grafana、告警规则等成熟生态。
③ 压缩与存储效率仍有差距
虽然 ByConity 有 Gorilla 编码，但 VictoriaMetrics 的存储引擎是专为时序数据从头设计的 ，压缩率可达 约 0.4 字节/点 ，而 ByConity 基于通用列存，即便使用 Gorilla 编码，压缩效率也通常低于 VM。对于海量指标，长期存储成本差距会很明显。
3. 一个有力的旁证
ByConity 自己的监控体系 ，就是选择 VictoriaMetrics 来存储其运行时指标（CPU、内存、查询延迟等）的。它自己都没有用 ByConity 来存自己的指标数据，这很能说明问题。
4. 场景推荐
| 场景 | 推荐存储 | 原因 |
|---|---|---|
| CPU、JVM 等指标数据 | VictoriaMetrics | 为时序优化，高压缩、PromQL 生态、资源占用低 |
| 日志、宽表分析 | ByConity | 为分析优化，复杂 SQL、多表关联、弹性扩缩容 |
所以，我们正在做的指标数据从 ByConity 迁移到 VM，方向是完全正确的。让专业的引擎做专业的事，才是成本和效率的最优解。
七、迁移时需要注意的点
-
数据模型映射
ByConity 表结构 → VM 的
metric + labels + timestamp + value。注意标签基数，高基数标签会拖垮 VM。
-
历史数据回填
从 ByConity 导出历史指标，转换成 VM 可导入格式，比如 remote write 或 vmimport。
-
双写 / 双读过渡
迁移期可以双写，Grafana 数据源逐步切换，保证监控不中断。
-
告警规则迁移
SQL 告警要重写成 PromQL，注意函数语义差异。
-
职责边界
日志数据、复杂分析继续留在 ByConity；指标、监控、告警交给 VM。
八、核心要点回顾
- ClickHouse：列式小作坊，快，但存算绑死。
- ByConity：中央仓库 + 弹性工厂，存算分离，省成本。
- Prometheus：会压缩的监控标杆，但大规模长期存储吃力。
- VictoriaMetrics：时序压缩大师，逻辑完整、物理变化编码，指标长期存储更优。
这次迁移的本质，不是谁替代谁，而是：
让专业的存储做专业的事。
日志分析数据归 ByConity，指标监控归 VictoriaMetrics。