-
从 PostgreSQL 12 + MySQL 5.7 + MongoDB 4.4 + Redis 5 + 原生 pg_dump + Navicat 单栈手工运维 → PostgreSQL 17 + Citus 13 + TimescaleDB 2.17 + pgvector 0.8 + Patroni 4 + PgBouncer 1.24 + pgBackRest 2.55 + Atlas + Flyway 11 + Liquibase 4.30 + ClickHouse 25 + DuckDB 1.2 + Redis 7.4 + KeyDB 6.4 + Dragonfly 1.27 + MongoDB 8.0 + MariaDB 11.6 LTS + MySQL 8.4 LTS + CockroachDB 24 + TiDB 8.5 + dbt 1.9 + Airbyte 0.70 + Debezium 3.0 + Materialize 0.130 全栈现代数据库工程化 87 天踩坑录:23 反模式 + 27 修法
27 位 DBA + 后端工程师 87 天把公司核心数据库栈从 PostgreSQL 12 + MySQL 5.7 + MongoDB 4.4 + Redis 5 + 原生 pg_dump + Navicat 单栈手工运维,整体重构到 2026 年 PostgreSQL 17 + Patroni 4 + Citus + TimescaleDB + pgvector + ClickHouse 25 …- 3
- 0
-
从 MySQL 5.7 + MyCat + Redis 5 + Elasticsearch 7 + InfluxDB + Pinecone → Postgres 17 + Citus 13 + Vitess 21 + Valkey 8 + Dragonfly + OpenSearch 3 + ClickHouse 24 + TimescaleDB 2.17 + Iceberg 1.7 + pgvector 0.8 全栈升级 73 天踩坑录:19 反模式 + 19 修法
21 位 DBA + 数据工程师 73 天把公司"交易 / 用户 / 商品 / 订单 / 风控 / 日志"6 套核心数据系统,从 MySQL 5.7 + MyCat + Redis 5 + MongoDB 4 + Elasticsearch 7 + InfluxDB 1.8 + Pinecone 整体迁移到 Postgres 17 + Citus 13 + Vitess 21 …- 0
- 0
-
ClickHouse 23.8 广告归因平台 11 个 MV 同步写放大导致存储 24TB 涨到 67TB + P99 480ms 飙到 38 秒的 14 天复盘:Refreshable MV + AggregatingMergeTree + Projection 6 套修法 + 12 条 OLAP 工程纪律
2026 年 4 月,我们一组 ClickHouse 23.8 + Kafka Engine + 物化视图(MV)的实时数据平台(广告投放归因分析,日入仓事件 84 亿、SQL 查询日均 280 万、20 节点 3 副本集群)在一次业务方新增 11 个 MV 后遭遇了双重雪崩:存储从 24TB 在 14 天内涨到 67TB(同样的原始数据)、报表 P99 从 480ms 飙到 38 秒、Backg…- 7
- 0
-
ClickHouse 核心表 parts 飙到 47832 看板全线超时的 6 天复盘:四因素叠加根因 + buffer/分区/merge 三层治理 + 接入决策树
2026 年 1 月,ClickHouse 集群核心表 some_events 的 parts 数飙到 47832,BI 看板全线超时,简单 count 跑 8 秒,报表 30 秒不出来。6 天深度排查定位四因素叠加:单条 INSERT 让 part 生产 QPS 2000 + merge 默认保守跟不上 + 按小时分区让 merge 无法集中 + parts_to_throw 被业务方调到 50…- 5
- 0
-
ClickHouse 生产 3 年实战:日 5 亿日志 + 200ms 聚合 + Doris 对比
ES 跑日志 5 亿/天聚合 20s,换 ClickHouse 后 200ms,资源省一半。本文实录表引擎选型 + ORDER BY/分区设计 + LowCardinality + Buffer 表 + 物化视图 + MaterializedMySQL CDC + 集群配置,对比 Doris 实战经验。- 0
- 0
ClickHouse
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×