标签: #olap

한국어English日本語中文

← 全部文章

• 300 倍不是调 PostgreSQL 调出来的数字 —— 火山模型与向量化执行

  精确解剖随 pgrust 0.2 发布一起公开的那个 300 倍。这个数字不是改 PostgreSQL 配置得来的，而是把一个用 Rust 重写的数据库放到 ClickBench 上测出来的结果；而作者另外给出的 SUM 查询实验，是从火山模型的 1.3 秒到 SIMD 的 135 毫秒，也就是 9.6 倍。我们在代码层面跟一遍批处理、算子融合、SIMD 各自消掉了什么，并把作者自己讲明的局限，和你今天就能在真实 PostgreSQL

  2026-08-09 · 12 分钟阅读 #postgresql#database#performance#query-engine#simd

• 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

• DuckDB 有了客户端-服务器协议 — Quack 改变了什么，又没有改变什么

  2026 年 5 月 12 日，DuckDB 团队发布了 Quack。这是一套架在 HTTP 之上的客户端-服务器协议，让两个 DuckDB 实例互为客户端和服务器，使同一个数据库可以被多个进程同时读写。一个把「进程内」当作身份标签坚持了 7 年的项目，如今自己给自己装上了服务器 — 相比「改变了什么」，「没有改变什么」反而更重要。本文梳理了 Quack 的设计取舍(为什么是 HTTP、为什么不是 Arrow Flight SQL)、D

  2026-07-16 · 26 分钟阅读 #database#duckdb#olap#analytics#data-engineering

• 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