TDengine 容量规划完全指南从内存、CPU 到存储与网络的全栈估算方法【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengineTDengine 专为工业物联网IIoT场景设计的高性能时序数据库。在正式部署前对计算资源、存储资源和网络资源进行系统性的容量规划是保障时序数据平台长期稳定运行的前提。本文基于 TDengine 官方容量规划文档结合仓库内配置文件packaging/cfg/taos.cfg与系统表源码include/common/systable.h给出可落地的内存、CPU、存储、网络带宽与服务器数量的估算方法与实操命令帮助读者在购买硬件或划分虚拟机资源时做到心中有数。总体资源模型先认识 TDengine 的多进程架构若计划使用 TDengine 搭建一个时序数据平台须提前对计算资源、存储资源和网络资源进行详细规划以确保满足业务场景的需求。通常 TDengine 会运行多个进程包括 taosd、taosAdapter、taosKeeper、taosExplorer 和 taosX。在这些进程中taosKeeper、taosExplorer、taosAdapter 和 taosX 的资源占用相对较少通常不需要特别关注。此外这些进程对存储空间的需求也较低其占用的 CPU 和内存资源一般为 taosd 进程的十分之一到几分之一特殊场景除外如数据同步和历史数据迁移此类场景需技术支持团队一对一服务。系统管理员应定期监控这些进程的资源消耗并及时进行相应处理。因此容量规划的核心应聚焦于 TDengine 数据库引擎的核心进程taosd。合理的资源规划将确保 taosd 进程的高效运行从而提高整个时序数据平台的性能和稳定性。服务器内存需求内存占用模型每个数据库能够创建固定数量的 vgroup默认情况下为两个。在创建数据库时可以通过vgroups num参数指定 vgroup 的数量而副本数则由replica num参数确定。由于每个 vgroup 中的副本会对应一个 vnode因此数据库所占用的内存由参数vgroups、replica、buffer、pages、pagesize和cachesize确定。这些参数中buffervnode 写入缓冲池大小内存中缓存待落盘的数据块pagesvnode 元数据与数据页缓存数量与pagesize默认 4KB可取 4/8/16/32/64相乘得到页缓存总容量cachesizevnode 最近数据块的缓存大小用于加速最近时间窗口内的查询。根据这些参数可以估算出一个数据库所需的内存大小具体计算方式如下具体数值须根据实际情况调整vgroups × replica × (buffer pages × pagesize cachesize)内存由整个集群分摊需要明确的是这些内存资源并非仅由单一服务器承担而是由整个集群中的所有 dnode 共同分摊。若集群内存在多个数据库所需的内存总量还须将各数据库的需求累加起来。更为复杂的情形在于如果集群中的 dnode 并非一开始就全部部署完毕而是在使用过程中随节点负载上升逐步添加那么新加入的数据库可能会导致新旧 dnode 之间负载分布不均。此时简单地进行理论计算是不够准确的必须结合各 dnode 的实际负载状况进行综合评估。用 information_schema 查看 vnode 分布系统管理员可以通过如下 SQL 查看information_schema库中的ins_vnodes表获得所有数据库所有 vnodes 在各个 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 |从仓库源码看ins_vnodes是 TDengine 内置系统表之一其表名在 include/common/systable.h 中以宏TSDB_INS_TABLE_VNODES定义同文件还定义了ins_dnodes、ins_vgroups等一整套信息模式information_schema系统表include/common/systable.h。SHOW VNODES命令的完整字段说明可参考 docs/zh/05-tdengine-sql/09-system-info/03-show.md。借助这些视图管理员可以随时掌握各 dnode 上 vnode 的实际分布为后续扩容决策提供依据。客户端内存需求客户端连接方式不同内存模型差异很大需要分别估算。1. 原生连接方式taosc由于客户端应用程序采用 taosc 与服务器进行通信因此会产生一定的内存消耗。这些内存消耗主要源于写入操作中的 SQL、表元数据信息的缓存以及固有的结构开销。假设该数据库服务能够支持的最大表数量为 N每个通过超级表创建的表的元数据开销约为 256B最大并发写入线程数为 T以及最大 SQL 语句长度为 S通常情况下为 1MB。基于这些参数可对客户端的内存消耗进行估算单位为 MBM (T × S × 3 (N / 4096) 100)示例用户最大并发写入线程数为 100子表数为 10 000 000则客户端内存最低要求100 × 3 (10000000 / 4096) 100 ≈ 2841 (MB)即配置3GB 内存是最低要求。2. RESTful / WebSocket 连接方式当将 WebSocket 连接方式用于数据写入时如果内存占用不大通常可以不予关注。但在执行查询操作时WebSocket 连接方式会消耗一定量的内存。当客户端通过 WebSocket 发起查询请求时为了接收并处理查询结果必须预留足够的内存空间。得益于 WebSocket 连接方式的特性数据可以分批次接收和解码这样就能在确保每个连接所需内存固定的同时处理大量数据。计算客户端内存占用的方法相对简单只须将每个连接所需的读 / 写缓冲区容量相加即可。通常每个连接会额外占用8MB的内存。因此如果有 C 个并发连接那么总的额外内存需求就是8 × C单位 MB。示例如果用户最大并发连接数为 10则客户端额外内存最低要求是 808×10MB。与 WebSocket 相比RESTful 连接方式在内存占用上更大除了缓冲区所需内存以外还需要考虑每个连接响应结果的内存开销。这种内存开销与响应结果的 JSON 数据大小密切相关特别是在查询数据量很大时会占用大量内存。由于 RESTful 连接方式不支持分批获取查询数据在查询超大结果集时可能占用特别大的内存从而导致内存溢出。因此在大型项目中建议使用 WebSocket 连接方式实现流式结果集返回从而避免内存溢出的风险。连接方式选型建议建议采用 RESTful/WebSocket 连接方式来访问 TDengine 集群而不采用 taosc 原生连接方式。在绝大多数情形下RESTful/WebSocket 连接方式均满足业务写入和查询要求并且该连接方式不依赖于 taosc集群服务器升级与客户端连接方式完全解耦使得服务器维护、升级更容易。CPU 需求TDengine 用户对 CPU 的需求主要受以下 3 个因素影响数据分片在 TDengine 中每个 CPU 核心可以服务 1 至 2 个 vnode。假设一个集群配置了 100 个 vgroup并且采用三副本策略那么建议该集群的 CPU 核心数量为150~300 个以实现最佳性能。数据写入TDengine 的单核每秒至少能处理10,000 个写入请求。值得注意的是每个写入请求可以包含多条记录而且一次写入一条记录与同时写入 10 条记录相比消耗的计算资源相差无几。因此每次写入的记录数越多写入效率越高。例如如果一个写入请求包含 200 条以上记录单核就能实现每秒写入 100 万条记录的速度。然而这要求前端数据采集系统具备更高的能力因为它需要缓存记录然后批量写入。查询需求虽然 TDengine 提供了高效的查询功能但由于每个应用场景的查询差异较大且查询频次也会发生变化因此很难给出一个具体的数字来衡量查询所需的计算资源。用户需要根据自己的实际场景编写一些查询语句以便更准确地确定所需的计算资源。综上所述对于数据分片和数据写入CPU 的需求是可以预估的而查询需求所消耗的计算资源则难以预测。在实际运行过程中建议保持 CPU 使用率不超过 50%以确保系统的稳定性和性能。一旦 CPU 使用率超过这一阈值就需要考虑增加新的节点或增加 CPU 核心数量以提供更多的计算资源。存储需求压缩率与原始数据量估算相较于传统通用数据库TDengine 在数据压缩方面表现出色拥有极高的压缩率。在大多数应用场景中TDengine 的压缩率通常不低于 5 倍在某些特定情况下压缩率甚至可以达到 10 倍乃至上百倍这主要取决于实际场景中的数据特征。要计算压缩前的原始数据大小可以采用以下方式RawDataSize numOfTables × rowSizePerTable × rowsPerTable示例1000 万块智能电表电表每 15min 采集一次数据每次采集的数据量为 20B那么一年的原始数据量约 7TBTDengine 大概需要消耗1.4TB存储空间。存储生命周期管理keep 参数与多级存储为了迎合不同用户在数据存储时长及成本方面的个性化需求TDengine 通过一系列数据库参数配置选项来定制存储策略。其中keep 参数尤其重要它赋予用户自主设定数据在存储空间上的最长保存期限的能力。这一功能设计使得用户能够依据业务的重要性和数据的时效性精准调控数据的存储生命周期进而实现存储成本的精细化控制。然而单纯依赖 keep 参数来优化存储成本仍显不足。为此TDengine 进一步推出了多级存储策略详见下文。此外为了加速数据处理流程TDengine 特别支持配置多块硬盘以实现数据的并发写入与读取。这种并行处理机制能够最大化利用多核 CPU 的处理能力和硬盘 I/O 带宽大幅提高数据传输速度完美应对高并发、大数据量的应用场景挑战。实操实测压缩率与已占用存储空间如何估算 TDengine 压缩率用户可以利用性能测试工具 taosBenchmark 来评估 TDengine 的数据压缩效果通过使用-f选项指定写入配置文件taosBenchmark 可以将指定数量的 CSV 样例数据写入指定的库参数和表结构中该工具源码位于 tools/taosBenchmark其用例配置可参考 tools/taosBenchmark/case。完成数据写入后在taosshell 中执行flush database命令将所有数据强制写入硬盘。通过 Linux 操作系统的du命令获取指定 vnode 的数据文件夹大小。最后将原始数据大小除以实际存储的数据大小即可计算出真实的压缩率。通过如下命令可以获得 TDengine 占用的存储空间taos flush database dbname; $ du -hd1 dataDir/vnode --excludewal其中dataDir为 dnode 的数据目录默认位于/var/lib/taos可在 packaging/cfg/taos.cfg 中通过dataDir参数修改--excludewal用于排除 WAL 目录从而只统计已落盘的数据文件大小。多级存储除了存储容量的需求以外用户可能还希望在特定容量下降低存储成本。为了满足这一需求TDengine 推出了多级存储功能。该功能允许将近期产生且访问频率较高的数据存储在高成本存储设备上而将时间较长且访问频率较低的数据存储在低成本存储设备上。通过这种方式TDengine 实现了以下目标降低存储成本通过将海量极冷数据存储在廉价存储设备上可以显著降低存储成本。提高写入性能每级存储支持多个挂载点WAL 文件也支持 0 级的多挂载点并行写入这些措施极大地提高了写入性能实际场景中的持续写入速度可达 3 亿测点/秒在机械硬盘上也能获得极高的硬盘 I/O 吞吐实测可达 2GB/s。用户可以根据冷热数据的比例来决定高速和低成本存储设备之间的容量划分。TDengine 的多级存储功能在使用上还具备以下优点方便维护配置各级存储挂载点后数据迁移等工作无须人工干预存储扩容更加灵活、方便。对 SQL 透明无论查询的数据是否跨级一个 SQL 即可返回所有数据简洁高效。网络带宽需求网络带宽需求可以分为两个主要部分——写入查询和集群内部通信。写入查询是指面向业务请求的带宽需求即客户端向服务器发送数据以进行写入操作的带宽需求。集群内部通信的带宽需求进一步分为两部分各节点间正常通信的带宽需求例如 leader 将数据分发给各 followertaosAdapter 将写入请求分发给各 vgroup leader 等集群为响应维护指令而额外需要的内部通信带宽如从单副本切换到三副本导致的数据复制、修复指定 dnode 引发的数据复制等情况。入站带宽估算为了估算入站带宽需求可以采用以下方式由于 taosc 写入在 RPC 通信过程中自带压缩功能因此写入带宽需求相对于 RESTful/WebSocket 连接方式较低。在这里将基于 RESTful/WebSocket 连接方式的带宽需求来估算写入请求的带宽。示例1000 万块智能电表电表每 15min 采集一次数据每次采集的数据量为 20B可计算出平均带宽需求为 0.22MB。考虑到智能电表存在集中上报的情况在计算带宽需求时须结合实际项目情况增加带宽需求同时考虑到 RESTful 请求以明文传输实际带宽需求还应乘以倍数只有这样才能得到合理的估算值。网络质量建议网络带宽和通信延迟对于分布式系统的性能与稳定性至关重要特别是在服务器节点间的网络连接方面强烈建议为服务器节点间的网络专门分配 VLAN以避免外部通信干扰。在带宽选择上建议使用万兆网络至少也要千兆网络并确保丢包率低于万分之一。如果采用分布式存储方案必须将存储网络和集群内部通信网络分开规划。一个常见的做法是采用双万兆网络即两套独立的万兆网络确保存储数据和集群内部通信互不干扰提高整体性能。对于入站网络除了要保证足够的接入带宽以外还须确保丢包率同样低于万分之一。这将有助于减少数据传输过程中的错误和重传从而提高系统的可靠性和效率。服务器数量根据前面对内存、CPU、存储和网络带宽的预估可以得出整个 TDengine 集群所需的内存容量、CPU 核数、存储空间以及网络带宽。若数据副本数不是 1还需要将总需求量乘以副本数以得到实际所需资源。得益于 TDengine 出色的水平扩展能力可以轻松计算出资源需求的总量。接下来只须将这个总量除以单台物理机或虚拟机的资源量便能大致确定需要购买多少台物理机或虚拟机来部署 TDengine 集群。网络端口要求下表按产品与组件列出 TDengine 相关默认端口含 TSDB、IDMP、TDgpt、CLS。这些端口均可通过配置文件中的参数修改。为简化防火墙与安全组配置推荐一次性开放端口段6030–6070TCP其中 StatsD / collectd 相关端口同时需要 UDP即可覆盖下表所列默认端口避免逐个放行。若仅部署核心 TSDB不含 IDMP、TDgpt、CLS可收窄为6030–6060。产品组件端口协议说明TSDBtaosd6030TCP原生接口taosctaosKeeper6043TCP监控服务taosExplorer6060TCPWeb 管理界面taosMqtt6057TCPMQTT 订阅服务BnodetaosX6055TCPgRPCAgent / Xnode6050TCPREST APItaosAdapter6041TCPWebSocket 接口6041TCPRESTful 接口6044TCP/UDPStatsD 格式写入6045TCP/UDPcollectd 格式写入6046TCPOpenTSDB TELNET 格式写入6047TCPcollectd 使用 OpenTSDB TELNET 写入6048TCPicinga2 使用 OpenTSDB TELNET 写入6049TCPtcollector 使用 OpenTSDB TELNET 写入IDMPIDMP6034HTTPSHTTPS 访问生产推荐6037MCPMCP / AI Agent6038HTTP内嵌 H2 Web 控制台6039TCP内嵌 H2 数据库监听6040HTTP内部聊天服务 API6042HTTPWeb UI / REST APITDgptAnode6035TCPTDgpt 服务接口TDtsfm6061TCP时序基础模型服务Time-MoE6062TCP模型服务Chronos6063TCP模型服务Moirai6064TCP模型服务TimesFM6065TCP模型服务Moment6066TCP模型服务Reserved6067-6070TCP预留模型服务端口CLSCLS6059HTTPWeb UI / 许可证服务规划流程总结综合上述维度一份完整的 TDengine 容量规划可以按如下步骤推进盘点业务模型确定表数量尤其子表规模、采集频率、单条记录大小、数据保留周期keep、副本数replica与 vgroup 数vgroups。估算服务器内存按vgroups × replica × (buffer pages × pagesize cachesize)估算数据库内存并通过select * from information_schema.ins_vnodes;核对 vnode 在集群各 dnode 上的分布是否均衡。估算客户端内存原生连接按M (T × S × 3 (N / 4096) 100)估算WebSocket 按8 × C估算大型项目优先选用 WebSocket 流式结果集避免 RESTful 大结果集内存溢出。规划 CPU单核支撑 1~2 个 vnode单核写入能力至少 1 万请求/秒鼓励批量写入单请求 200 条以上记录可达百万条/秒运行时将 CPU 使用率控制在 50% 以下作为扩容信号。规划存储按RawDataSize numOfTables × rowSizePerTable × rowsPerTable估算原始数据量再按不低于 5 倍压缩率折算实际占用用flush database与du实测压缩效果结合 keep 参数与多级存储、多块硬盘并行 I/O 定制存储方案。规划网络估算入站带宽并按上报集中度与明文传输放大系数修正节点间网络独立 VLAN、万兆起步、丢包率低于万分之一分布式存储时双万兆分离存储网络与内部通信网络。确定服务器数量将内存、CPU、存储、带宽总量乘以副本数后除以单机资源量得出物理机或虚拟机台数。配置防火墙核心 TSDB 放行6030–6060完整部署含 IDMP、TDgpt、CLS放行6030–6070注意 StatsD / collectd 端口需同时开放 UDP。容量规划并非一次性工作。随着业务增长、节点逐步扩容建议定期通过information_schema视图监控 vnode 分布与资源水位将理论估算与实际负载相结合动态调整集群规模从而在成本与性能之间取得最佳平衡。【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考