TDengine 集群资源规划与容量估算指南：内存、CPU、存储、网络与端口全面规划

TDengine 集群资源规划与容量估算指南：内存、CPU、存储、网络与端口全面规划

【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine

在构建基于 TDengine 的时间序列数据平台时，提前对计算资源、存储资源和网络资源进行详细规划，是保障平台高效稳定运行的前提。本篇技术指南以 TDengine 官方运维文档为核心，系统讲解taosd核心进程的内存估算公式、客户端（taosc / WebSocket / RESTful）内存开销、CPU 核数评估、存储与压缩比测算、多级存储、网络带宽与端口规划，并结合仓库内的数据库参数文档、多级存储配置文档与 taosBenchmark 工具说明，给出可直接复用的配置示例与验证手段。读完本文，你将能够独立完成一个 TDengine 集群从单机到多节点的资源预算与容量设计。

总体资源视角：哪些进程需要重点规划

TDengine 运行多个进程，包括核心数据库引擎taosd，以及配套的taosadapter（连接器适配）、taoskeeper（监控服务）、taos-explorer（Web 管理界面）和taosx（数据同步/迁移工具）。其中：

• taoskeeper、taos-explorer、taosadapter、taosx资源消耗相对较小，存储空间要求低，其 CPU 与内存占用一般为taosd的十分之一到几分之一；
• 特殊情况除外，例如数据同步和历史数据迁移场景，此时需要 TDengine 技术支持团队一对一服务；
• 系统管理员应定期监控这些进程的资源消耗并及时处理异常。

因此，本节将聚焦 TDengine 数据库引擎的核心进程taosd的资源规划。合理的资源规划能确保taosd高效运行，从而提升整个时间序列数据平台的性能与稳定性。

服务器内存需求估算

内存占用模型

每个数据库可以创建固定数量的 vgroup，默认值为 2。创建数据库时可通过vgroups<num>参数指定 vgroup 数量，副本数由replica<num>参数决定。由于 vgroup 中的每个副本对应一个 vnode，数据库占用的内存由vgroups、replica、buffer、pages、pagesize和cachesize参数共同决定。

基于这些参数，可以估算单个数据库所需的内存大小（具体数值需根据实际情况调整）：

vgroups × replica × (buffer + pages × pagesize + cachesize)

关键参数详解

这些参数的定义与取值范围可以在 数据库管理文档 中找到完整说明，以下为规划时最核心的几个：

例如创建一个数据库db，指定 10 个 vgroup、每个 vnode 分配 10 MB 写缓冲区：

create database if not exists db vgroups 10 buffer 10

内存由集群共享，而非单机承担

需要特别说明的是：上述内存资源并非由单台服务器承担，而是由集群中所有 dnode 共同分担。若集群中存在多个数据库，总内存需求需累加各数据库的需求。

更复杂的情况是：dnode 并非在部署初期全部到位，而是随着节点负载增加逐步扩容。此时，新增数据库可能导致新老 dnode 之间的负载不均衡，简单的理论计算不再准确，需要结合各 dnode 的实际负载情况进行综合评估。

用 SQL 查看 vnode 分布

系统管理员可以通过information_schema库中的ins_vnodes表（详见 系统信息 · 元数据）查询所有数据库 vnode 在各 dnode 上的分布：

select * from information_schema.ins_vnodes; dnode_id |vgroup_id | db_name | status | role_time | start_time | restored | =============================================================================================== 1| 3 | log | leader | 2024-01-16 13:52:13.618 | 2024-01-16 13:52:01.628 | true | 1| 4 | log | leader | 2024-01-16 13:52:13.630 | 2024-01-16 13:52:01.702 | true |

结合该查询结果，管理员可以判断各 dnode 上 vnode 分布是否均衡，辅助扩容决策。

客户端内存需求估算

原生连接方式（taosc）

客户端应用通过 taosc 与服务器通信会产生内存消耗，主要来自：写入操作中的 SQL、表元数据信息的缓存，以及固有的结构开销。假设：

• 数据库服务可支持的最大表数量为 N（通过超级表创建的每张表元数据开销约 256 B）；
• 最大并发写入线程数为 T；
• SQL 语句最大长度为 S（通常为 1 MB）。

则客户端内存消耗估算（单位 MB）为：

M = (T × S × 3 + (N / 4096) + 100)

示例：用户最大并发写入线程为 100，子表数量为 10,000,000，则客户端最低内存需求为：

100 × 3 + (10000000 / 4096) + 100 ≈ 2841 (MB)

即配置 3 GB 内存是最低要求。

WebSocket 连接方式

使用 WebSocket 连接进行数据写入时，通常无需过多关注内存占用；但执行查询操作时，WebSocket 连接会消耗一定内存。查询场景的内存使用如下：

客户端通过 WebSocket 发起查询请求时，必须预留足够的内存空间接收和处理查询结果。得益于 WebSocket 连接方式的特点，数据可以分批接收并解码，从而在单连接内存固定的前提下处理大量数据。

客户端内存计算方法较为简单：累加每个连接所需的读写缓冲区容量即可。通常每个连接额外消耗 8 MB 内存。因此，若有 C 个并发连接，总附加内存需求为8 × C（MB）。

示例：用户最大并发连接数为 10，则客户端最低附加内存需求为80 (8 × 10) MB。

RESTful 连接方式

与 WebSocket 相比，RESTful 连接方式消耗更多内存，包括缓冲区所需内存以及每个连接响应结果的内存开销。该内存开销与响应中 JSON 数据的大小密切相关，尤其是在查询大量数据时会显著增加内存消耗。

由于 RESTful 连接方式不支持分批获取查询数据，检索非常大的结果集时可能导致内存占用过大，甚至内存溢出。因此，在大型项目中推荐使用 WebSocket 连接方式实现流式结果集，避免内存溢出风险。

:::note 连接方式建议

• 推荐使用 RESTful/WebSocket 连接方式访问 TDengine 集群，而非原生 taosc 连接方式；
• 大多数场景下，RESTful/WebSocket 连接方式即可满足业务写入和查询需求，且这些方式不依赖 taosc，将集群服务器升级与客户端连接方式完全解耦，使服务器维护和升级更简单。

:::

CPU 需求评估

TDengine 用户的 CPU 需求主要受以下三个因素影响：

• 数据分片（Data sharding）：TDengine 中每个 CPU 核可服务 1 ~ 2 个 vnode。假设集群配置 100 个 vgroup 且采用三副本策略，推荐集群拥有 150 ~ 300 个 CPU 核以获得最佳性能。
• 数据写入：TDengine 单核每秒至少可处理 10,000 次写入请求。值得注意的是，每次写入请求可包含多条记录，一次写入 1 条记录与一次写入 10 条记录消耗的计算资源大致相同。因此，单次写入记录越多，写入效率越高。例如，若一次写入请求包含 200 条以上记录，单核可实现每秒写入 100 万条记录的速度。但这对前端数据采集系统提出了更高要求，需要先缓存记录再批量写入。
• 查询需求：虽然 TDengine 提供高效查询能力，但不同应用场景和查询频率下查询所需计算资源差异巨大，难以给出统一数值。用户需要基于实际场景编写查询语句，以更准确地确定所需计算资源。

综上，数据分片和数据写入的 CPU 需求可以估算，但查询需求的计算资源难以预测。实践中建议将 CPU 使用率控制在 50% 以下以保证系统稳定性和性能；一旦超过该阈值，可能需要考虑新增节点或增加 CPU 核数以提供更多计算资源。

存储需求与压缩

压缩能力概述

相比传统通用数据库，TDengine 在数据压缩方面表现出色，压缩率非常高。在大多数应用场景中，TDengine 的压缩率通常不低于 5 倍；某些特定情况下压缩率甚至可达 10 倍甚至数百倍，主要取决于实际场景中的数据特征。

原始数据量与压缩后存储

未压缩原始数据大小的计算方法：

RawDataSize = numOfTables × rowSizePerTable × rowsPerTable

示例：1,000 万只智能电表，每只电表每 15 分钟采集一次数据，每次采集 20 B，则一年原始数据量约为 7 TB，TDengine 大约需要 1.4 TB 存储空间。

数据保留策略与存储成本控制

针对不同用户在数据存储时长与成本上的个性化需求，TDengine 提供极大灵活性。用户可通过一系列数据库参数配置选项自定义存储策略，其中keep参数尤为值得关注——它允许用户独立设置数据在存储空间中的最大保留时长，从而根据业务重要性和数据时效性精确控制数据存储生命周期，实现存储成本的精细化管控。

keep参数定义（详见 数据库管理文档）：数据文件保留天数，默认值为 3650，范围 [1, 365000]，且必须大于等于duration参数值的 3 倍。数据库会自动删除超过keep值的数据以释放存储空间。keep支持带单位格式，如KEEP 100h、KEEP 10d，支持 m（分钟）、h（小时）、d（天）三种单位；也可不带单位，如KEEP 50，默认单位为天。

企业版支持多级存储，因此可以设置多个保留时间（逗号分隔，最多 3 个，满足keep0 <= keep1 <= keep2，如KEEP 100h,100d,3650d）；社区版不支持多级存储（即使配置多个保留时间也不生效，keep取最长保留时间）。

然而，仅靠keep参数优化存储成本仍显不足。为此，TDengine 进一步创新性地引入了多级存储策略（详见下文）。

此外，为加速数据处理，TDengine 支持配置多块硬盘实现数据并发写入和读取。该并行处理机制最大化利用多核 CPU 处理能力和硬盘 I/O 带宽，显著提升数据传输速度，很好地应对高并发、大数据量的应用场景。

如何估算 TDengine 压缩比

用户可使用性能测试工具 taosBenchmark 评估 TDengine 的数据压缩效果。通过-f选项指定写入配置文件，taosBenchmark 可向指定数据库参数和表结构写入指定数量的 CSV 样本数据。

写入完成后，在 TDengine CLI 中执行flush database命令强制将所有数据写入磁盘，然后使用 Linux 操作系统的du命令获取指定 vnode 数据文件夹的大小。最后，将原始数据大小除以实际存储数据大小，即可计算出真实压缩比。

以下命令可获取 TDengine 占用的存储空间：

taos> flush database <dbname>; $ du -hd1 <dataDir>/vnode --exclude=wal

taosBenchmark 快速上手

taosBenchmark 是 TDengine 自带的性能测试工具（作为服务器和客户端安装包的默认组件），支持插入、查询和订阅性能测试（详见 taosBenchmark 参考文档）。无参数运行即可基于默认配置快速体验写性能测试：

taosBenchmark

无参数运行时，taosBenchmark 默认连接/etc/taos/taos.cfg指定的 TDengine 集群。连接成功后，会创建智能电表示例数据库、超级表和 10,000 张子表，每张子表写入 10,000 条记录。如果测试数据库已存在，会先删除再创建。

命令行模式示例——创建数据库db、默认超级表meters、100 张子表，并使用参数绑定（stmt）为每张子表写入 1,000 条记录：

taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y

JSON 配置文件模式提供更丰富的配置选项：

taosBenchmark -f <json file>

写入完成后输出的性能指标示例：

SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms

第一行统计写入速度（Spent 为总写入时间，Real 为纯引擎调用时间，records/second 为写入速率）；第二行统计单次写入延迟的分位分布（min/avg/p90/p95/p99/max），可据此观察写入请求延迟的分布情况。

多级存储（Multi-Tier Storage）

除存储容量需求外，用户还希望在特定容量下降低存储成本。为此，TDengine 引入多级存储特性：近期生成且被频繁访问的数据存放于高成本存储设备，而较旧且访问频率低的数据存放于低成本存储设备。该特性实现以下目标：

• 降低存储成本：将海量极冷数据存放于廉价存储设备，显著降低存储成本；
• 提升写入性能：每一级存储支持多个挂载点，WAL 预写日志也支持在第 0 级多个挂载点并行写入，大幅提升写入性能（实测可持续写入每秒超过 3 亿条数据点），并在机械硬盘上实现极高的磁盘 I/O 吞吐（实测可达 2 GB/s）；
• 易维护：配置好各级存储挂载点后，数据迁移等任务无需人工干预，存储扩容更灵活便捷；
• 对 SQL 透明：无论查询的数据是否跨级，单条 SQL 即可返回全部数据，简单高效。

用户可根据热数据和冷数据的比例，决定高速与低成本存储设备之间的容量分配。

配置方法

多级存储支持 3 级，每级最多 128 个挂载点。典型配置方案：第 0 级配置多个挂载点，每个对应一块 SAS 硬盘；第 1 级配置多个挂载点，每个对应一块或多块 SATA 硬盘。

配置方法（配置文件/etc/taos/taos.cfg，可参考 打包配置示例）：

dataDir [path] <level> <primary>

• path：挂载点文件夹路径；
• level：存储介质级别，取值 0、1、2。第 0 级存放最新数据，第 1 级存放次新数据，第 2 级存放最旧数据，省略默认为 0。数据流向为第 0 级 → 第 1 级 → 第 2 级。同一存储级别可挂载多块硬盘，该级数据文件分布在各硬盘上。跨级数据移动由系统自动完成，无需用户干预；
• primary：是否为主挂载点，0（否）或 1（是），省略默认为 1。

配置中只允许一个主挂载点（level=0, primary=1），示例：

dataDir /mnt/data1 0 1 dataDir /mnt/data2 0 0 dataDir /mnt/data3 1 0 dataDir /mnt/data4 1 0 dataDir /mnt/data5 2 0 dataDir /mnt/data6 2 0

注意：

1. 多级存储不允许跨级配置，合法配置方案只有：仅第 0 级、第 0 级 + 第 1 级、第 0 级 + 第 1 级 + 第 2 级。不允许只配置第 0 级和第 2 级而不配置第 1 级；
2. 禁止手动移除使用中的挂载盘；当前挂载盘不支持非本地网络盘。

同级别负载均衡与选盘策略

多级存储中只有一个主挂载点，承担系统最重要的元数据存储，各 vnode 的主目录也位于当前 dnode 的主挂载点上，因此该 dnode 的写入性能受限于单块磁盘的 I/O 吞吐。从 TDengine 3.1.0.0 开始，若 dnode 配置了多个第 0 级挂载点，系统会将所有 vnode 的主目录均匀分布到各第 0 级挂载点上，使这些挂载点分担写入负载。当网络 I/O 等处理资源不是瓶颈时，测试证明整个系统的写入能力与第 0 级挂载点数量呈线性关系。

在同级中选择挂载点创建新数据文件时，默认采用轮询（round-robin）策略。但实际中各磁盘容量可能不同，或容量相同而写入数据量不同，导致各盘可用空间不均衡。为解决该问题，从 3.1.1.0 起引入minDiskFreeSize配置项：当磁盘可用空间小于等于该阈值时，该磁盘不再被选中生成新数据文件。该配置项单位为字节，例如设置为 2 GB 即跳过可用空间不足 2 GB 的挂载点。从 3.3.2.0 起新增disable_create_new_file配置项，控制禁止在某个挂载点生成新文件，默认值为false（各挂载点默认可生成新文件）。

完整的多级存储与共享存储配置说明见 高级存储选项。

网络带宽需求

网络带宽需求分为两大部分：写入查询和集群内部通信。

• 写入查询：指业务请求的带宽需求，即客户端向服务器发送数据执行写入操作所需带宽。
• 集群内部通信带宽：又分为两部分：
  • 节点间正常通信所需带宽，例如 leader 向各 follower 分发数据、taosAdapter 向各 vgroup leader 分发写请求等；
  • 集群响应维护命令所需的额外内部通信带宽，例如从单副本切换到三副本引起的数据复制、修复指定 dnode 触发的数据复制等。

入站带宽估算

估算入站带宽可采用以下方法：由于 taosc 写入在 RPC 通信中包含压缩功能，其写入带宽需求相对 RESTful/WebSocket 连接更低。这里以 RESTful/WebSocket 连接的带宽需求为基准估算写请求带宽。

示例：1,000 万只智能电表，每只电表每 15 分钟采集一次数据，每次采集 20 B，计算得出平均带宽需求约 0.22 MB。

考虑到智能电表会集中上报数据（聚类场景），计算带宽需求时必须根据实际项目情况上调。同时，考虑到 RESTful 请求以明文传输，实际带宽需求应乘以一个系数得到估算值。

网络规划建议

:::note

网络带宽和通信延迟对分布式系统的性能和稳定性至关重要，尤其是服务器节点之间的网络连接。

• 强烈建议为服务器节点间的网络划分专用 VLAN，避免外部通信干扰；
• 带宽选择上，建议使用万兆网络，或至少千兆网络，并确保丢包率低于万分之一；
• 若采用分布式存储方案，存储网络与集群内部通信网络必须分开规划。常见做法是使用双万兆网络，即两套独立的万兆网络，确保存储数据与集群内部通信互不干扰，提升整体性能；
• 对于入站网络，除保证足够的接入带宽外，丢包率也必须保持在万分之一以下，以减少数据传输中的错误和重传，提高系统可靠性和效率。

:::

服务器数量估算

基于前面内存、CPU、存储和网络带宽的估算，可以确定整个 TDengine 集群所需的总内存容量、CPU 核数、存储空间和网络带宽。如果数据副本数不为 1，则必须将总需求乘以副本数，才能得到实际所需资源。

得益于 TDengine 出色的水平扩展能力，可以方便地计算出资源需求总量。接下来只需将该总量除以单台物理机或虚拟机的资源量，即可大致确定需要采购多少台物理机或虚拟机来部署 TDengine 集群。

网络端口需求

下表列出了 TDengine 产品与组件的默认端口（涵盖 TSDB、IDMP、TDgpt 和 CLS）。这些端口可通过配置文件中的参数修改。

为简化防火墙和安全组配置，可一次性开放端口范围6030–6070（TCP；StatsD / collectd 相关端口还需 UDP）。该范围覆盖下表列出的所有默认端口，避免逐个开放。如果仅部署核心 TSDB（不含 IDMP、TDgpt 或 CLS），可将范围缩小至6030–6060。

规划实践建议小结

1. 内存：优先按vgroups × replica × (buffer + pages × pagesize + cachesize)估算taosd内存，再叠加客户端连接（taosc 按公式计算，WebSocket 按8 × CMB 估算）；RESTful 大结果集查询存在内存溢出风险，大型项目应改用 WebSocket 流式查询。
2. CPU：以“每核服务 1 ~ 2 个 vnode”为基准结合副本数规划，并利用批量写入提升单核写入效率；维持 CPU 使用率低于 50% 作为扩容触发线。
3. 存储：先按RawDataSize = numOfTables × rowSizePerTable × rowsPerTable估算原始数据量，再结合实测压缩比（taosBenchmark 造数 +flush database+du验证）与keep保留期确定存储容量；对冷数据占比高的场景引入多级存储，配合minDiskFreeSize、disable_create_new_file优化磁盘选盘与负载均衡。
4. 网络：为节点间通信规划专用 VLAN，推荐万兆网络并保持丢包率低于万分之一；分布式存储场景使用双万兆网络隔离存储与内部通信。
5. 端口：按部署形态一次性开放6030–6070（核心 TSDB 可缩至6030–6060）TCP 端口，按需补充 StatsD/collectd 的 UDP 端口。

通过上述方法，管理员可在部署前形成量化的资源预算，并在集群运行后结合information_schema.ins_vnodes、数据库参数视图（SELECT * FROM INFORMATION_SCHEMA.INS_DATABASES）与SHOW db_name.VGROUPS（查看 cacheload）等诊断手段持续校准，实现 TDengine 集群的精细化容量管理。

【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine