我对 ClickHouse 选型的核心判断是：它从来不是”选最大的”，而是先回答自己的查询模式、数据温度与成本约束，再在 CPU、内存、磁盘和网络四条线上做取舍。
选型不是单点决策
tencent-cloud-clickhouse-cluster-sizing 把腾讯云 TCHouse-C 的实例规格摊开之后，真正重要的不是”选哪款机器”，而是把四条约束线拧成一组可验证的假设：
- 查询模式决定 CPU 与内存比例：宽表聚合、大量
GROUP BY、复杂JOIN会同时吃满 CPU 和内存；纯扫描型日志分析则更吃磁盘吞吐。 - 数据温度决定存储介质：热层需要 NVMe SSD 或增强型 SSD 云盘支撑低延迟随机读；冷层可以用 SATA HDD 或对象存储换取容量。
- 并发度决定节点数：单节点 CPU 被打满后，水平扩展 shard 才能继续提升吞吐；但 ClickHouse 的强项是单机并行，过早分片会增加
Distributed查询 fan-out 和运维面。 - 网络带宽决定集群规模上限：节点间复制、分布式查询和冷热分层回写都跑在内网上，带宽瓶颈往往在集群扩大到一定规模后才暴露。
计算节点：三类规格怎么选
腾讯云把 ClickHouse 计算节点打包成三种类型，本质上是在 CPU/内存配比 与 磁盘介质 这两个维度上做了预设：
- 标准型：CPU:内存 = 1:2，磁盘需另配。这是最稳妥的起点。如果你的工作负载还在变化、历史数据规模不大、没有明确的冷热分层策略，先上标准型，后续通过升配或加节点调整。
- 存储优化型：配备大容量 SATA HDD，单节点可达数十 TB。适合数据量大、查询以顺序扫描为主、对延迟不敏感的场景，比如离线报表、审计日志归档、大规模时序回溯。HDD 的随机读性能差，如果查询经常命中少量热数据，HDD 会成为瓶颈。
- 高性能型：配备 NVMe SSD，单节点磁盘容量相对小，但 IOPS 和延迟远优于 HDD。适合交互式分析、高并发点查、实时大盘或需要频繁回读热数据的场景。
这里的关键取舍是：同价格下，存储优化型给你更多容量，高性能型给你更低延迟。 没有标准答案，取决于你的查询分布。如果 80% 查询只命中最近 7 天数据，把热层放在高性能节点、冷层放在存储优化节点或对象存储，往往是更划算的分层策略。
CVM 实例族的精细映射
如果不用托管服务、而是自己在腾讯云 CVM 上部署 ClickHouse，实例族的选择需要更精细。以下是我基于 tencent-cloud-clickhouse-cluster-sizing 整理的 ClickHouse 场景映射：
通用分析场景：标准型 S/SA 系列
适合大多数 ClickHouse 工作负载，特别是查询模式多样、既有聚合又有扫描的混合场景。
| 优先级 | 实例族 | 推荐理由 | ClickHouse 适用场景 |
|---|---|---|---|
| 首选 | SA9 | 最新 AMD Turin-Dense，DDR5，6750万 PPS，睿频 3.4GHz | 需要高网络吞吐的大集群节点 |
| 首选 | S9 | 最新 Intel Sierra Forest，DDR5，3370万 PPS | 需要稳定单核性能的通用分析 |
| 次选 | SA9e | 全核睿频 4.1GHz，更高单核性能 | 复杂计算、大量函数调用的查询 |
| 次选 | S9pro | 睿频 3.6GHz，更高单核性能 | 高并发短查询场景 |
| 性价比 | SA5 | AMD Bergamo，DDR5，4500万 PPS | 预算敏感但需新一代性能 |
| 性价比 | S8 | Intel Emerald Rapids，DDR5，120Gbps 带宽 | 网络密集型查询 |
| 上一代 | SA4 | AMD Genoa，DDR5，100Gbps 带宽 | 已有存量或特殊价格优势 |
| 上一代 | S6 | Intel Ice Lake，DDR4，100Gbps 带宽 | 已有存量或特殊价格优势 |
ClickHouse 选型建议：
- 标准型是最稳妥的起点，SA9/S9 作为最新一代在内存带宽和网络性能上都有优势
- 如果查询以复杂计算为主（大量
JOIN、GROUP BY、窗口函数），优先选 SA9e/S9pro 这类高主频版本 - 如果集群节点间网络通信量大（多分片、多副本），优先选 SA9/SA5 这类高 PPS 版本
内存密集型场景：内存型 M/MA 系列
ClickHouse 对内存非常敏感。宽表聚合、复杂 JOIN、ORDER BY、字典缓存、mark cache 都需要大量内存。当标准型的内存成为瓶颈时，内存型是更经济的选择。
| 优先级 | 实例族 | 推荐理由 | ClickHouse 适用场景 |
|---|---|---|---|
| 首选 | MA9 | 最新 AMD Turin-Dense，DDR5，1:8 配比，6750万 PPS | 超宽表聚合、大量字典、复杂 JOIN |
| 首选 | M9 | 最新 Intel Sierra Forest，DDR5，1:8 配比 | 需要 Intel 生态的内存密集型场景 |
| 次选 | MA9e | 全核睿频 4.1GHz | 内存密集型 + 计算密集型混合 |
| 次选 | M9pro | 睿频 3.6GHz | 内存密集型 + 高并发短查询 |
| 性价比 | M8 | Intel Emerald Rapids，同规格内存价格最低 | 预算敏感的大内存场景 |
| 性价比 | MA5 | AMD Bergamo，同规格内存价格最低 | 预算敏感的大内存场景 |
| 上一代 | M6 | Intel Ice Lake，DDR4，同规格内存价格最低 | 已有存量或特殊价格优势 |
| 上一代 | MA3 | AMD Milan，DDR4，同规格内存价格最低 | 已有存量或特殊价格优势 |
ClickHouse 选型建议：
- 当标准型 1:2 配比的内存不够用时，内存型 1:8 配比可以在相同 CPU 下提供 4 倍内存
- 对于需要大量内存缓存的查询（如
join_algorithm = 'grace_hash'，大字典，max_memory_usage较高），内存型往往是更经济的选择 - 注意内存型网络带宽通常低于同代标准型，如果网络是瓶颈（如大量分布式查询），可能需要更高规格
热数据/低延迟场景：高 IO 型 IT/IA 系列
ClickHouse 的查询性能在很大程度上取决于磁盘 IOPS 和延迟。对于交互式分析、实时大盘、高频点查，本地 NVMe SSD 是必需的。
| 优先级 | 实例族 | 推荐理由 | ClickHouse 适用场景 |
|---|---|---|---|
| 首选 | ITA5 | 最新 AMD Bergamo，NVMe SSD，单盘 7140GB，整机最高 24 盘 | 热数据层，需要大容量 + 高性能 |
| 首选 | IT5 | Intel Cascade Lake，NVMe SSD，整机最高 205万 IOPS | 极致低延迟场景 |
| 次选 | IT3 | Intel Skylake，NVMe SSD，整机最高 180万 IOPS | 性价比热数据层 |
| 替代 | IA5se | 单副本 SSD，随机读写约 10万 IOPS，顺序 1GB/s | 成本敏感但需 SSD 的场景 |
ClickHouse 选型建议：
- 高性能型 ClickHouse 节点（托管服务）本质上就是高 IO 型实例的封装
- ITA5 单盘 7140GB 远大于 IT5/IT3 的 3570GB，适合热数据量大的场景
- 注意 IT/IA 系列不支持垂直变配（因为本地盘绑定物理机），选型时需要预留余量
- ITA5/IT5/IT3 的本地盘有数据丢失风险（宿主机故障时），ClickHouse 的多副本机制可以缓解这一风险，但仍需注意
冷数据/归档场景：大数据型 D 系列
对于历史数据归档、低频访问的冷层，大数据型实例提供极高的存储密度和顺序吞吐。
| 优先级 | 实例族 | 推荐理由 | ClickHouse 适用场景 |
|---|---|---|---|
| 首选 | D3 | 最高 24 块 4TB SATA HDD，94TB 本地存储，单盘 190MB/s 顺序读 | 冷数据归档，顺序扫描为主 |
| 次选 | D2 | 最高 12 块 12TB SATA HDD，144TB 本地存储，单盘 220MB/s 顺序读 | 超大规模冷数据归档 |
ClickHouse 选型建议：
- D 系列适合 ClickHouse 的冷数据层（通过
storage_policy配置 TTL move 到 HDD） - D2 单盘 12TB 比 D3 的 4TB 更大，总容量更高，但 D3 是更新一代
- HDD 的随机读性能差，不适合热数据查询。建议只用于通过 TTL 自动下沉的冷分区
- D 系列同样不支持垂直变配，且本地盘有数据丢失风险
计算密集型场景：计算型 C 系列
对于以复杂计算为主、内存需求不大的 ClickHouse 查询，计算型实例提供更高的单核性能。
| 优先级 | 实例族 | 推荐理由 | ClickHouse 适用场景 |
|---|---|---|---|
| 首选 | C6 | 最新 Intel Ice Lake，3.2GHz / 睿频 3.5GHz，100Gbps 带宽 | 高计算密度查询 |
| 次选 | C5 | Intel Cooper Lake，3.4GHz / 睿频 3.8GHz，支持 bfloat16 | 需要最高单核性能 |
| 上一代 | C4 | Intel Cascade Lake，3.2GHz / 睿频 3.7GHz | 已有存量或特殊价格优势 |
ClickHouse 选型建议：
- ClickHouse 的查询通常同时需要 CPU 和内存，纯计算型场景较少
- 如果查询以简单聚合（
count、sum）为主，且数据量不大，计算型可能性价比更高 - 但如果涉及宽表、大量列、复杂
JOIN，标准型或内存型通常更合适
ZooKeeper / Keeper：被低估的协调层
很多选型讨论把注意力全放在计算节点上，却低估了协调层的稳定性对集群的影响。ClickHouse 的副本同步、分布式 DDL、ReplicatedMergeTree 的元数据都依赖 ZooKeeper 或 Keeper。
腾讯云建议 Keeper 规格随负载上升而上升，但实际经验里，Keeper 的瓶颈通常不是 CPU 或内存，而是：
- 网络延迟：节点与 Keeper 之间的 RTT 直接影响副本同步速度和 DDL 分发效率；
- 连接数：每个 ClickHouse 节点会维持到 Keeper 的长连接，集群规模扩大时连接数线性增长；
- 磁盘延迟：Keeper 的 transaction log 需要低延迟磁盘写入，不适合与计算节点共享高负载磁盘。
因此 Keeper 节点不需要像计算节点那样追求大内存，但需要稳定的网络和低延迟磁盘。生产环境常见的配置是 4核16GB 或 8核32GB，重点是独立部署、不与其他高 IO 服务混跑。
网络性能的关键考量
ClickHouse 集群对网络的要求往往被低估。以下场景都会大量消耗内网带宽：
- 副本同步：
ReplicatedMergeTree的 parts 复制 - 分布式查询：
Distributed表向各 shard 发送子查询，再聚合结果 - 冷热分层：从对象存储读取冷数据到本地 cache
- 数据迁移：新增节点时的 rebalancing
腾讯云实例的网络性能与规格强相关：
- PPS（包每秒）：最高 6750万（SA9/SA9e 系列），超过 1000万 PPS 后建议用 DPDK
- 内网带宽：最高 300Gbps（SA9.192XLARGE2304）
- 队列数：最高 48 队列，影响网络并发处理能力
ClickHouse 选型建议：
- 对于 2 shards × 2 replicas 的小集群，标准型中等规格的网络通常足够
- 当扩展到 6+ shards 或大量副本时，网络会成为瓶颈，需要选更高 PPS 和带宽的规格
- 如果大量查询涉及跨 shard 的
JOIN或IN，网络带宽要求会显著增加 - 巨型帧（Jumbo frames，8500 字节）可以减少大包传输的协议栈开销，对 ClickHouse 的大结果集传输有帮助
与部署拓扑的联动
clickhouse-deployment-topologies 里强调的分片与副本决策，直接影响选型：
- 副本数增加 → 写入放大增加 → 单节点磁盘吞吐和 Keeper 连接数压力上升；
- 分片数增加 →
Distributed查询 fan-out 增加 → 内网带宽和协调开销上升； - 冷热分层 → 热节点需要高性能磁盘，冷节点可以用大容量低成本磁盘或对象存储。
所以在选型时，不应该孤立地看单节点规格，而要把节点规格、分片副本策略和冷热分层放在一起算总账。
具体选型推荐
基于以上分析，以下是不同 ClickHouse 场景的推荐配置：
场景一：通用 OLAP（中小规模，查询模式多样）
- 计算节点：标准型 SA9.8XLARGE128（32核128GB）或 S9.8XLARGE128
- 存储：增强型 SSD 云盘 2-4TB
- Keeper：标准型 SA9.LARGE16（4核16GB）
- 理由：平衡的计算、内存、网络资源，云盘可以独立扩容，适合大多数场景
场景二：内存密集型（宽表聚合、复杂 JOIN）
- 计算节点：内存型 MA9.8XLARGE256（32核256GB）或 MA9.16XLARGE512
- 存储：增强型 SSD 云盘 1-2TB
- Keeper：标准型 SA9.2XLARGE16（8核16GB）
- 理由：1:8 内存配比可以容纳更大的查询内存和缓存，减少磁盘 IO
场景三：热数据低延迟（实时大盘、交互式分析）
- 计算节点：高 IO 型 ITA5.8XLARGE128（32核128GB，2×7140GB NVMe）
- Keeper：标准型 SA9.LARGE16
- 理由：本地 NVMe SSD 提供最低延迟和最高 IOPS，适合热数据查询
- 注意：本地盘容量固定，不适合数据量快速增长的场景
场景四：海量冷数据归档（日志、审计、时序历史）
- 计算节点：大数据型 D3.8XLARGE128（32核128GB，12×3720GB HDD）
- 热层节点（可选）：标准型 + SSD 云盘，用于最近 N 天数据
- Keeper：标准型 SA9.LARGE16
- 理由：通过
storage_policy配置 TTL move，热数据在 SSD，冷数据自动下沉到 HDD
场景五：大规模生产集群（多 shard，高并发）
- 计算节点：标准型 SA9.16XLARGE256（64核256GB）
- 存储：增强型 SSD 云盘 4-8TB
- Keeper：专用标准型 SA9.2XLARGE16 或 SA9.4XLARGE32，独立部署
- 网络：确保实例规格的内网带宽 ≥ 25Gbps，PPS ≥ 500万
- 理由：高规格提供足够的 CPU、内存和网络余量，云盘可以独立扩容，便于运维
实用建议
- 先纵向，后横向：ClickHouse 单机性能很强，先通过升配（更大 CPU、更多内存、更快磁盘）解决问题，比过早分片更便宜、运维更简单。
- 热层优先投资 NVMe/SSD：如果预算有限，优先保证热数据所在节点有高性能磁盘，冷数据可以降级。
- Keeper 独立部署：不要把 Keeper 和计算节点混跑，尤其是高负载集群。Keeper 的网络抖动会直接影响整个集群的副本健康度。
- 预留网络带宽余量：内网带宽上限是硬约束，选型时注意规格表中的带宽指标，避免集群扩大后网络先成为瓶颈。
- 用真实查询验证：选型前的压测不要只跑
SELECT count()，要用真实业务查询（含JOIN、GROUP BY、ORDER BY、LIMIT）验证 CPU、内存、磁盘和网络的实际消耗。 - 考虑垂直变配限制：IT/IA/D 系列（本地盘实例）不支持垂直变配，选型时需要预留足够余量；标准型/内存型/计算型（云盘实例）支持垂直变配，更灵活。
- 关注代际差异：新一代实例（SA9/S9/MA9/M9，DDR5）相比上一代（SA3/S6/MA3/M6，DDR4）在内存带宽上有显著提升，ClickHouse 这种内存密集型应用会从 DDR5 中明显受益。
删减预算
- 本轮无删减候选：本次更新补充了完整的实例族映射和场景化推荐，与现有内容形成互补，不重复。
来源：tencent-cloud-clickhouse-cluster-sizing
相关页面：
- clickhouse-deployment-topologies — 分片、副本、Keeper 与对象存储的部署判断框架
- clickhouse-production-migration — 生产环境迁移的容量与拓扑决策
- clickhouse-common-pitfalls — 入门阶段的常见误区
- clickhouse-keeper-vs-zookeeper — 协调层选型边界
- clickhouse — ClickHouse 实体总览