标签: #clickhouse

한국어English日本語中文

← 全部文章

• 把观测数据放进 ClickHouse 意味着什么 — schema、rollup、TTL 与职责划分

  当 trace 和日志每天膨胀到数 TB 规模，单靠一个搜索引擎或时序数据库就很难撑住了。本文从列式存储、压缩与排序键的角度，梳理 ClickHouse 为什么适合观测数据，并用真实的 DDL 设计 trace 表和日志表。文中讲清属性该用 Map 还是 JSON 类型的判断标准、如何用物化视图做 rollup、如何用分区和 TTL 控制成本。最后整理在已经用着 Prometheus 和 OpenSearch 的前提下，三者的职责该怎么

  2026-08-02 · 22 分钟阅读 #observability#clickhouse#opentelemetry#data-modeling#cost

• ClickHouse 的 Lazy Materialization — LIMIT 10 的小技巧是如何长成 FINAL 和 JOIN 的

  ClickHouse 的 lazy materialization 是一种在排序和 LIMIT 完成之前不读取 SELECT 列的优化，它在 25.4(2025 年 4 月)以「仅在 LIMIT 10 及以下时才生效」的保守姿态首次登场。此后，在把逐行 lookup 改造成 join 式批量获取的 25.12 中，这道闸门被提高到 10,000；进入 2026 年后，同一个思路又扩展到 26.2 的 UNION ALL 全部分支、26.

  2026-07-17 · 22 分钟阅读 #database#clickhouse#olap#query-optimization#performance

• OLAP 引擎 2025 对比指南：DuckDB、ClickHouse、Snowflake、StarRocks、Pinot、Druid、Trino，基准测试的陷阱，引擎布局（2025）

  Season 5 Ep 3。没有哪一个引擎能覆盖全部 OLAP。DuckDB 带来单节点的革命，ClickHouse 负责实时 OLAP，Snowflake 与 BigQuery 提供托管式的便利，StarRocks、Doris、Pinot、Druid 承担实时 MPP，Trino 负责联邦查询。涵盖各引擎的强项与弱项、基准测试的陷阱、因地制宜的布局模式，以及面向韩国企业的选型指南。

  2026-04-15 · 16 分钟阅读 #olap#duckdb#clickhouse#snowflake#bigquery