nerual-cache

ClickHouse 基本介绍

5 min read

ClickHouse 基本介绍

ClickHouse 是一个面向分析场景的列式数据库，核心目标不是处理高频事务，而是高效地完成海量数据上的聚合、过滤、扫描和统计查询。

如果用一句话概括：它更像“为报表、监控、日志、行为分析、实时看板而生的数据库”。

它适合解决什么问题

ClickHouse 主要适合这类场景：

  • 大量写入后很快就要被分析
  • 单次查询会扫描很多行，但只会读取少量列
  • 查询以聚合、分组、过滤、排序为主
  • 需要较高压缩率和较低查询延迟

典型例子包括：

  • 指标分析
  • 日志与可观测性
  • 用户行为分析
  • BI 报表
  • 实时数据看板

为什么它通常比传统 OLTP 数据库更适合分析

1. 列式存储

行式数据库通常按“整行”存储数据，而 ClickHouse 按“列”存储。
这意味着当查询只需要 event_time、user_id、cost 三列时，不需要把一整行里其他几十列也一起读出来。

这会直接带来两个结果：

  • 读盘更少
  • 同类型数据连续存储，更容易压缩

所以在分析型 SQL 中，列式存储通常天然比行式存储更占优势。

2. 面向聚合和扫描的执行方式

ClickHouse 的强项不是“按主键查一行”，而是“对几千万到几十亿行做统计”。
它会尽量把过滤、聚合、排序等操作组织成高吞吐的批处理执行流程，因此特别适合：

  • count
  • sum
  • avg
  • group by
  • 大范围 where

3. 面向分析的资源利用方式

官方资料长期强调 ClickHouse 在分析查询上会尽量吃满 CPU、I/O 和并行能力，以换取更短的查询耗时。
这和很多 OLTP 数据库的优化目标不同。后者更关注小事务、低延迟点查和并发事务隔离。

应该怎么理解它和 MySQL / PostgreSQL 的关系

一个很实用的理解方式是：

  • MySQL / PostgreSQL 更适合承接业务系统的事务写入和在线查询
  • ClickHouse 更适合承接分析流量和重查询

也就是说，很多系统不是“用 ClickHouse 替代所有数据库”，而是：

  1. 业务数据先进入 OLTP 数据库
  2. 再通过同步、埋点、日志或流式链路进入 ClickHouse
  3. 报表、监控、分析 SQL 再走 ClickHouse

这也是它经常出现在日志分析、监控平台、埋点平台和数仓链路里的原因。

使用 ClickHouse 时需要有的预期

它强在读分析，不强在事务语义

如果你的需求是：

  • 强事务
  • 高频单行更新
  • 复杂行级约束
  • 大量点查

那 ClickHouse 通常不是第一选择。

它不是“什么 SQL 都自动快”

ClickHouse 很强，但并不意味着随便写 SQL 都会好。
实际效果仍然会受这些因素影响：

  • 表引擎与表设计
  • 排序键
  • 分区策略
  • 过滤条件是否能减少扫描
  • 聚合与 Join 的写法
  • 是否命中缓存

一张简单的心智图

业务数据 / 日志 / 指标
        ->
    写入 ClickHouse
        ->
列式存储 + 压缩 + 并行扫描
        ->
聚合 / 过滤 / 分组 / 排序
        ->
报表 / 监控 / 实时分析

相关笔记

参考资料

Graph View

Backlinks