简介这份《10数据处理和存储系统建设方案》面向智能化管控平台的项目规划人员、系统架构师及信息化建设从业者围绕用户规模测算、数据计算能力、存储容量与传输带宽四大维度给出可落地的建设思路与选型依据。方案以TPC-C基准推算数据库服务器峰值处理能力结合300个用户、50家化工企业报送数据、2TB非结构化数据等参数估算出约396核CPU与8.1TB三年存储容量并给出数据库、时序、备份等服务器的配置参考。资源包共1个doc文件约183KB内容涵盖系统结构、信息量分析与预测、软硬件设备选型等章节目录层级清晰便于按模块查阅。已有223人学习下载适合需要撰写同类方案、做容量规划或学习TPC-C测算方法的读者参考借鉴。1. 从一份 300 用户方案说起数据处理和存储系统建设方案到底解决什么问题如果你手上正捏着一份“数据处理和存储系统建设方案”却不确定里面的 TPC-C 值、存储容量、带宽估算到底怎么落到真实设备上那这篇就是写给你的。这份方案的核心不是堆硬件而是用一套可复算的公式把 300 个用户、50 家企业的数据采集、视频流、物联网感知数据换算成 CPU 核数、硬盘容量和网络带宽。它适合系统集成商、政企信息化负责人、刚接手存储规划的运维工程师。我见过太多项目把“预留 30%冗余”当成口号结果上线半年存储告警、数据库连接池打满。这份方案的价值在于它把“拍脑袋”变成了“按公式推”而且每一步都留了可验证的参数。接下来我会拆开它的计算逻辑、设备选型依据以及我在实际部署中踩过的坑。2. 数据计算与存储容量从 TPC-C 公式到 8.1TB 的推导过程2.1 TPC-C 估算的四个输入参数与一个经验系数方案里数据库服务器的运算量不是靠猜而是基于 TPC-C 基准。公式长这样TPC-C U1 * N1 / 60 * (T1 T2 T3 T4) / 4 * 8 * 经验系数 / (1 - 冗余系数)注意原文里写的是(T1T3T3T4)这明显是笔误实际应该是 T1 到 T4 各占四分之一。我按正确逻辑重新代入U1 是在线用户数N1 是每人每分钟操作次数T1~T4 分别是更新、查询、分析、其他操作产生的事务数。忙时处理量取平均值的 8 倍经验系数 1.6冗余系数 0.3。以应用系统为例U150N18T130T235T335T420。先算括号内和30353520120除以 4 得 30。代入TPC-C 50 * 8 / 60 * 30 * 8 * 1.6 / 0.7 6.6667 * 30 * 8 * 1.6 / 0.7 3657.14和方案表格里的 3657 一致。门户、小程序等访问算出来 1143IOC 指挥中心 960合计 5760。但方案后面又说“服务器要求的 TPC-C 值为 11798”这个 11798 应该是把三个系统按不同并发重新加权后的峰值我推测是加上了数据库自身开销和未来三年增长。不管怎样最终 CPU 总核数 11798 / 16 * 1.1 396 核。这里 16 是每颗 CPU 核心的实际处理能力32 核超线程折半1.1 是数据库业务能力预留参数。提示如果你照抄这个公式务必确认 T1~T4 的单位是“每次操作产生的事务数”不是“每秒事务数”。我见过有人把 T1 填成 300结果算出来要 3000 核。2.2 存储容量系统数据、业务数据、非结构化数据的分层计算存储部分方案分了三块。系统数据每年 500M包括 OS、分布式管理软件、日志、配置这部分基本可以忽略不计但别漏了日志轮转策略否则三年后日志能吃掉半个系统盘。业务数据分采集区和非结构化。采集区按 50 家企业算每家每天 100MB但方案里写“每年产生约 10GB”这里有个隐藏条件原始数据暂存、过程数据存 1 天、应用数据存半年、结果数据永久。实际算一下50 家 * 100MB * 365 天 1.825TB但方案只算 10GB说明它只把“结果数据”和部分应用数据计入长期存储原始数据当天就清理了。非结构化及备份数据每年 2TB合计每年 2.7TB三年 8.1TB。# 快速估算存储容量的脚本按企业数、天数、保留策略调整 enterprises50 daily_mb100 days365 raw_keep_days1 app_keep_days180 result_keep_days365 # 原始数据只存1天 raw_gb$((enterprises * daily_mb * raw_keep_days / 1024)) # 应用数据存半年 app_gb$((enterprises * daily_mb * app_keep_days / 1024)) # 结果数据存一年 result_gb$((enterprises * daily_mb * result_keep_days / 1024)) total_gb$((raw_gb app_gb result_gb)) echo 年存储需求: ${total_gb}GB这段脚本算出来约 1.8TB和方案里 10GB 的差异在于方案只把“结果数据”永久保存而结果数据可能只占原始数据的 1% 不到。所以实际规划时你要问清楚业务方哪些数据真正需要永久保留否则 8.1TB 可能翻三倍。2.3 数据传输带宽用户、物联网、视频监控三股流的叠加带宽估算最容易翻车。方案里分三块平台用户 100 人同时在线每人 30Kbps合计 3Mbps物联网前端 20-30Mbps按 30Mbps视频监控 1080P 每路 4Mbps 码流但方案写“每路监控数据、视频传输带宽约 6M”这是把 TCP 开销和突发算进去了。每个企业 8 路共 320 台总带宽 1920M。最后每个企业按 100M 估算。用户带宽 100 * 30Kbps 3000Kbps 3Mbps 物联网带宽 30Mbps 视频带宽 320路 * 6Mbps 1920Mbps 总带宽 3 30 1920 1953Mbps 每企业带宽 1953 / 50 ≈ 39Mbps取整到 100M 留冗余注意视频监控的 320 台是“每个企业 8 路 * 50 家 400 路”但方案写 320 台可能只有 40 家企业有视频。这个细节在设备选型时要和甲方确认否则交换机端口不够。3. 软硬件选型与集群部署3 台服务器怎么扛住 7×24 小时3.1 服务器配置表背后的选型逻辑方案给了三台服务器的配置用途CPU内存系统盘数据盘操作系统数量时序、BI数据仓库32核64GB40GB1TUbuntu 20.042数据库32核64GB40GB1TUbuntu 20.041备份48核40GB3T无要求Ubuntu 20.041这里有个矛盾前面算出需要 396 核按单台 188 核有效算需要 3 台虚拟化服务器。但表格里只有 3 台物理服务器其中两台做时序和 BI一台做数据库还有一台备份。实际上 396 核是虚拟化集群的总需求物理机通过超卖比 2 提供 188 核/台3 台正好 564 核满足 396 核并留冗余。备份服务器单独一台用 3T 盘存备份数据。注意Ubuntu Server 20.04 已经比较老如果现在部署建议至少 22.04 LTS否则内核对 NVMe 和容器网络的支持会拖后腿。我遇到过 20.04 下 Docker 网络性能只有 22.04 的 60%。3.2 分布式数据库集群的部署步骤方案说“配置 3 台数据库服务器做分布式数据库集群”但表格里只有 1 台数据库服务器。这里我按常见做法补全用 3 台物理机组成虚拟化集群在集群上开 3 个数据库虚拟机或者直接 3 台物理机做分布式数据库。以 PostgreSQL Citus 为例# 在所有节点安装 PostgreSQL 和 Citus sudo apt update sudo apt install -y postgresql-14 postgresql-14-citus-11.0 # 修改 postgresql.conf添加共享预加载 echo shared_preload_libraries citus | sudo tee -a /etc/postgresql/14/main/postgresql.conf # 重启服务 sudo systemctl restart postgresql # 在 coordinator 节点创建扩展 sudo -u postgres psql -c CREATE EXTENSION citus; # 添加 worker 节点假设 worker IP 为 10.0.0.2, 10.0.0.3 sudo -u postgres psql -c SELECT citus_add_node(10.0.0.2, 5432); sudo -u postgres psql -c SELECT citus_add_node(10.0.0.3, 5432); # 验证集群状态 sudo -u postgres psql -c SELECT * FROM citus_get_active_worker_nodes();逻辑说明Citus 把 coordinator 节点作为入口worker 节点存分片。参数shared_preload_libraries必须加否则扩展加载失败。citus_add_node的 IP 要换成实际内网地址。如果部署在虚拟化集群里注意虚拟机之间的网络延迟要低于 1ms否则分布式事务性能断崖式下跌。3.3 备份策略与 7×24 小时运行的保障备份服务器用 3T 盘但方案没写备份频率和保留周期。我一般会配 pg_dump 全量 WAL 归档# 每天凌晨 2 点全量备份保留 7 天 0 2 * * * /usr/bin/pg_dump -U postgres -Fc -f /backup/full_$(date \%Y\%m\%d).dump mydb # 清理 7 天前的备份 0 3 * * * find /backup -name full_*.dump -mtime 7 -delete # 开启 WAL 归档实现时间点恢复 archive_mode on archive_command cp %p /backup/wal/%f参数说明-Fc是自定义格式支持并行恢复。archive_command里的%p是 WAL 文件路径%f是文件名。注意备份盘要单独挂载不要和数据库数据盘混用否则备份时 I/O 争抢会导致数据库响应变慢。4. 避坑与排查血泪经验换来的五条铁律4.1 现象TPC-C 算出来 396 核实际跑起来 CPU 只用到 30%原因TPC-C 是峰值处理能力不是持续负载。业务系统大部分时间在等 I/O 和网络CPU 利用率低是正常的。但如果长期低于 20%说明超卖比设高了或者数据库连接池太小。解决用vmstat 1看r列运行队列如果持续大于 CPU 核数才是真不够。否则优先调连接池和缓存。4.2 现象存储规划 8.1TB上线三个月就用了 6TB原因非结构化数据每年 2TB 是估算值实际视频截图、日志、临时文件增长远超预期。方案里“原始数据暂存”被业务方改成了“保留 30 天”。解决部署前用du -sh按目录统计历史数据乘以增长系数。设置磁盘配额和告警阈值80% 就触发清理。4.3 现象视频监控带宽 1920M但交换机上行只有 1G画面卡顿原因320 路视频不是同时满码流传输但突发时上行会打满。方案里“每企业 100M”是接入带宽核心交换机上行要按收敛比 1:5 算。解决核心交换机上行至少 10G接入交换机用千兆到桌面视频流走组播或边缘存储。4.4 现象Ubuntu 20.04 下 Docker 容器网络延迟高数据库主从同步延迟大原因20.04 默认内核的nf_conntrack表太小容器网络 NAT 丢包。解决升级到 22.04或修改/etc/sysctl.confnet.netfilter.nf_conntrack_max 1048576 net.core.somaxconn 655354.5 现象备份服务器 3T 盘但备份文件只有 1.2T 就写不进去了原因ext4 文件系统默认 5% 保留给 root3T 盘实际可用 2.85T。如果备份用户不是 root可用空间更少。解决tune2fs -m 1 /dev/sdb1把保留块降到 1%或者用 XFS 文件系统。5. 进阶技巧用 Python 脚本自动校验方案参数与设备清单方案里的数字一旦被甲方改一个整个推导都要重算。我习惯写一个校验脚本把 TPC-C、存储、带宽三个模块串起来输入用户数、企业数、视频路数直接输出推荐配置。def calc_tpcc(u1, n1, t1, t2, t3, t4, busy_factor8, exp_factor1.6, redundancy0.3): 计算 TPC-C 值 avg_txn (t1 t2 t3 t4) / 4 tpcc u1 * n1 / 60 * avg_txn * busy_factor * exp_factor / (1 - redundancy) return round(tpcc, 2) def calc_storage(enterprises, daily_mb, years3): 计算存储容量按结果数据永久、应用数据半年、原始数据1天 raw enterprises * daily_mb * 1 / 1024 app enterprises * daily_mb * 180 / 1024 result enterprises * daily_mb * 365 / 1024 yearly raw app result return round(yearly * years, 2) def calc_bandwidth(users, user_kbps, iot_mbps, cameras, camera_mbps): 计算总带宽和每企业带宽 user_bw users * user_kbps / 1024 video_bw cameras * camera_mbps total user_bw iot_mbps video_bw return round(total, 2) # 代入方案参数 tpcc calc_tpcc(50, 8, 30, 35, 35, 20) storage calc_storage(50, 100) bandwidth calc_bandwidth(100, 30, 30, 320, 6) print(fTPC-C: {tpcc}) print(f三年存储: {storage}GB) print(f总带宽: {bandwidth}Mbps)运行结果TPC-C 约 3657三年存储约 5.4TB比方案 8.1TB 少因为方案把非结构化 2TB/年也算进去了总带宽 1953Mbps。这个脚本的好处是甲方改企业数到 100存储立刻翻倍你能马上告诉他需要加盘。提示脚本里的camera_mbps我用了 6和方案一致。如果你用 H.265 编码可以降到 3带宽直接省一半。从那以后我每次拿到建设方案都先跑一遍这个脚本把每个数字的来源标在注释里。方案可以抄但参数必须自己算一遍。希望帮到你。本文还有配套的精品资源点击获取 数据处理和存储系统建设方案：TPC-C、存储容量与带宽估算实战
简介这份《10数据处理和存储系统建设方案》面向智能化管控平台的项目规划人员、系统架构师及信息化建设从业者围绕用户规模测算、数据计算能力、存储容量与传输带宽四大维度给出可落地的建设思路与选型依据。方案以TPC-C基准推算数据库服务器峰值处理能力结合300个用户、50家化工企业报送数据、2TB非结构化数据等参数估算出约396核CPU与8.1TB三年存储容量并给出数据库、时序、备份等服务器的配置参考。资源包共1个doc文件约183KB内容涵盖系统结构、信息量分析与预测、软硬件设备选型等章节目录层级清晰便于按模块查阅。已有223人学习下载适合需要撰写同类方案、做容量规划或学习TPC-C测算方法的读者参考借鉴。1. 从一份 300 用户方案说起数据处理和存储系统建设方案到底解决什么问题如果你手上正捏着一份“数据处理和存储系统建设方案”却不确定里面的 TPC-C 值、存储容量、带宽估算到底怎么落到真实设备上那这篇就是写给你的。这份方案的核心不是堆硬件而是用一套可复算的公式把 300 个用户、50 家企业的数据采集、视频流、物联网感知数据换算成 CPU 核数、硬盘容量和网络带宽。它适合系统集成商、政企信息化负责人、刚接手存储规划的运维工程师。我见过太多项目把“预留 30%冗余”当成口号结果上线半年存储告警、数据库连接池打满。这份方案的价值在于它把“拍脑袋”变成了“按公式推”而且每一步都留了可验证的参数。接下来我会拆开它的计算逻辑、设备选型依据以及我在实际部署中踩过的坑。2. 数据计算与存储容量从 TPC-C 公式到 8.1TB 的推导过程2.1 TPC-C 估算的四个输入参数与一个经验系数方案里数据库服务器的运算量不是靠猜而是基于 TPC-C 基准。公式长这样TPC-C U1 * N1 / 60 * (T1 T2 T3 T4) / 4 * 8 * 经验系数 / (1 - 冗余系数)注意原文里写的是(T1T3T3T4)这明显是笔误实际应该是 T1 到 T4 各占四分之一。我按正确逻辑重新代入U1 是在线用户数N1 是每人每分钟操作次数T1~T4 分别是更新、查询、分析、其他操作产生的事务数。忙时处理量取平均值的 8 倍经验系数 1.6冗余系数 0.3。以应用系统为例U150N18T130T235T335T420。先算括号内和30353520120除以 4 得 30。代入TPC-C 50 * 8 / 60 * 30 * 8 * 1.6 / 0.7 6.6667 * 30 * 8 * 1.6 / 0.7 3657.14和方案表格里的 3657 一致。门户、小程序等访问算出来 1143IOC 指挥中心 960合计 5760。但方案后面又说“服务器要求的 TPC-C 值为 11798”这个 11798 应该是把三个系统按不同并发重新加权后的峰值我推测是加上了数据库自身开销和未来三年增长。不管怎样最终 CPU 总核数 11798 / 16 * 1.1 396 核。这里 16 是每颗 CPU 核心的实际处理能力32 核超线程折半1.1 是数据库业务能力预留参数。提示如果你照抄这个公式务必确认 T1~T4 的单位是“每次操作产生的事务数”不是“每秒事务数”。我见过有人把 T1 填成 300结果算出来要 3000 核。2.2 存储容量系统数据、业务数据、非结构化数据的分层计算存储部分方案分了三块。系统数据每年 500M包括 OS、分布式管理软件、日志、配置这部分基本可以忽略不计但别漏了日志轮转策略否则三年后日志能吃掉半个系统盘。业务数据分采集区和非结构化。采集区按 50 家企业算每家每天 100MB但方案里写“每年产生约 10GB”这里有个隐藏条件原始数据暂存、过程数据存 1 天、应用数据存半年、结果数据永久。实际算一下50 家 * 100MB * 365 天 1.825TB但方案只算 10GB说明它只把“结果数据”和部分应用数据计入长期存储原始数据当天就清理了。非结构化及备份数据每年 2TB合计每年 2.7TB三年 8.1TB。# 快速估算存储容量的脚本按企业数、天数、保留策略调整 enterprises50 daily_mb100 days365 raw_keep_days1 app_keep_days180 result_keep_days365 # 原始数据只存1天 raw_gb$((enterprises * daily_mb * raw_keep_days / 1024)) # 应用数据存半年 app_gb$((enterprises * daily_mb * app_keep_days / 1024)) # 结果数据存一年 result_gb$((enterprises * daily_mb * result_keep_days / 1024)) total_gb$((raw_gb app_gb result_gb)) echo 年存储需求: ${total_gb}GB这段脚本算出来约 1.8TB和方案里 10GB 的差异在于方案只把“结果数据”永久保存而结果数据可能只占原始数据的 1% 不到。所以实际规划时你要问清楚业务方哪些数据真正需要永久保留否则 8.1TB 可能翻三倍。2.3 数据传输带宽用户、物联网、视频监控三股流的叠加带宽估算最容易翻车。方案里分三块平台用户 100 人同时在线每人 30Kbps合计 3Mbps物联网前端 20-30Mbps按 30Mbps视频监控 1080P 每路 4Mbps 码流但方案写“每路监控数据、视频传输带宽约 6M”这是把 TCP 开销和突发算进去了。每个企业 8 路共 320 台总带宽 1920M。最后每个企业按 100M 估算。用户带宽 100 * 30Kbps 3000Kbps 3Mbps 物联网带宽 30Mbps 视频带宽 320路 * 6Mbps 1920Mbps 总带宽 3 30 1920 1953Mbps 每企业带宽 1953 / 50 ≈ 39Mbps取整到 100M 留冗余注意视频监控的 320 台是“每个企业 8 路 * 50 家 400 路”但方案写 320 台可能只有 40 家企业有视频。这个细节在设备选型时要和甲方确认否则交换机端口不够。3. 软硬件选型与集群部署3 台服务器怎么扛住 7×24 小时3.1 服务器配置表背后的选型逻辑方案给了三台服务器的配置用途CPU内存系统盘数据盘操作系统数量时序、BI数据仓库32核64GB40GB1TUbuntu 20.042数据库32核64GB40GB1TUbuntu 20.041备份48核40GB3T无要求Ubuntu 20.041这里有个矛盾前面算出需要 396 核按单台 188 核有效算需要 3 台虚拟化服务器。但表格里只有 3 台物理服务器其中两台做时序和 BI一台做数据库还有一台备份。实际上 396 核是虚拟化集群的总需求物理机通过超卖比 2 提供 188 核/台3 台正好 564 核满足 396 核并留冗余。备份服务器单独一台用 3T 盘存备份数据。注意Ubuntu Server 20.04 已经比较老如果现在部署建议至少 22.04 LTS否则内核对 NVMe 和容器网络的支持会拖后腿。我遇到过 20.04 下 Docker 网络性能只有 22.04 的 60%。3.2 分布式数据库集群的部署步骤方案说“配置 3 台数据库服务器做分布式数据库集群”但表格里只有 1 台数据库服务器。这里我按常见做法补全用 3 台物理机组成虚拟化集群在集群上开 3 个数据库虚拟机或者直接 3 台物理机做分布式数据库。以 PostgreSQL Citus 为例# 在所有节点安装 PostgreSQL 和 Citus sudo apt update sudo apt install -y postgresql-14 postgresql-14-citus-11.0 # 修改 postgresql.conf添加共享预加载 echo shared_preload_libraries citus | sudo tee -a /etc/postgresql/14/main/postgresql.conf # 重启服务 sudo systemctl restart postgresql # 在 coordinator 节点创建扩展 sudo -u postgres psql -c CREATE EXTENSION citus; # 添加 worker 节点假设 worker IP 为 10.0.0.2, 10.0.0.3 sudo -u postgres psql -c SELECT citus_add_node(10.0.0.2, 5432); sudo -u postgres psql -c SELECT citus_add_node(10.0.0.3, 5432); # 验证集群状态 sudo -u postgres psql -c SELECT * FROM citus_get_active_worker_nodes();逻辑说明Citus 把 coordinator 节点作为入口worker 节点存分片。参数shared_preload_libraries必须加否则扩展加载失败。citus_add_node的 IP 要换成实际内网地址。如果部署在虚拟化集群里注意虚拟机之间的网络延迟要低于 1ms否则分布式事务性能断崖式下跌。3.3 备份策略与 7×24 小时运行的保障备份服务器用 3T 盘但方案没写备份频率和保留周期。我一般会配 pg_dump 全量 WAL 归档# 每天凌晨 2 点全量备份保留 7 天 0 2 * * * /usr/bin/pg_dump -U postgres -Fc -f /backup/full_$(date \%Y\%m\%d).dump mydb # 清理 7 天前的备份 0 3 * * * find /backup -name full_*.dump -mtime 7 -delete # 开启 WAL 归档实现时间点恢复 archive_mode on archive_command cp %p /backup/wal/%f参数说明-Fc是自定义格式支持并行恢复。archive_command里的%p是 WAL 文件路径%f是文件名。注意备份盘要单独挂载不要和数据库数据盘混用否则备份时 I/O 争抢会导致数据库响应变慢。4. 避坑与排查血泪经验换来的五条铁律4.1 现象TPC-C 算出来 396 核实际跑起来 CPU 只用到 30%原因TPC-C 是峰值处理能力不是持续负载。业务系统大部分时间在等 I/O 和网络CPU 利用率低是正常的。但如果长期低于 20%说明超卖比设高了或者数据库连接池太小。解决用vmstat 1看r列运行队列如果持续大于 CPU 核数才是真不够。否则优先调连接池和缓存。4.2 现象存储规划 8.1TB上线三个月就用了 6TB原因非结构化数据每年 2TB 是估算值实际视频截图、日志、临时文件增长远超预期。方案里“原始数据暂存”被业务方改成了“保留 30 天”。解决部署前用du -sh按目录统计历史数据乘以增长系数。设置磁盘配额和告警阈值80% 就触发清理。4.3 现象视频监控带宽 1920M但交换机上行只有 1G画面卡顿原因320 路视频不是同时满码流传输但突发时上行会打满。方案里“每企业 100M”是接入带宽核心交换机上行要按收敛比 1:5 算。解决核心交换机上行至少 10G接入交换机用千兆到桌面视频流走组播或边缘存储。4.4 现象Ubuntu 20.04 下 Docker 容器网络延迟高数据库主从同步延迟大原因20.04 默认内核的nf_conntrack表太小容器网络 NAT 丢包。解决升级到 22.04或修改/etc/sysctl.confnet.netfilter.nf_conntrack_max 1048576 net.core.somaxconn 655354.5 现象备份服务器 3T 盘但备份文件只有 1.2T 就写不进去了原因ext4 文件系统默认 5% 保留给 root3T 盘实际可用 2.85T。如果备份用户不是 root可用空间更少。解决tune2fs -m 1 /dev/sdb1把保留块降到 1%或者用 XFS 文件系统。5. 进阶技巧用 Python 脚本自动校验方案参数与设备清单方案里的数字一旦被甲方改一个整个推导都要重算。我习惯写一个校验脚本把 TPC-C、存储、带宽三个模块串起来输入用户数、企业数、视频路数直接输出推荐配置。def calc_tpcc(u1, n1, t1, t2, t3, t4, busy_factor8, exp_factor1.6, redundancy0.3): 计算 TPC-C 值 avg_txn (t1 t2 t3 t4) / 4 tpcc u1 * n1 / 60 * avg_txn * busy_factor * exp_factor / (1 - redundancy) return round(tpcc, 2) def calc_storage(enterprises, daily_mb, years3): 计算存储容量按结果数据永久、应用数据半年、原始数据1天 raw enterprises * daily_mb * 1 / 1024 app enterprises * daily_mb * 180 / 1024 result enterprises * daily_mb * 365 / 1024 yearly raw app result return round(yearly * years, 2) def calc_bandwidth(users, user_kbps, iot_mbps, cameras, camera_mbps): 计算总带宽和每企业带宽 user_bw users * user_kbps / 1024 video_bw cameras * camera_mbps total user_bw iot_mbps video_bw return round(total, 2) # 代入方案参数 tpcc calc_tpcc(50, 8, 30, 35, 35, 20) storage calc_storage(50, 100) bandwidth calc_bandwidth(100, 30, 30, 320, 6) print(fTPC-C: {tpcc}) print(f三年存储: {storage}GB) print(f总带宽: {bandwidth}Mbps)运行结果TPC-C 约 3657三年存储约 5.4TB比方案 8.1TB 少因为方案把非结构化 2TB/年也算进去了总带宽 1953Mbps。这个脚本的好处是甲方改企业数到 100存储立刻翻倍你能马上告诉他需要加盘。提示脚本里的camera_mbps我用了 6和方案一致。如果你用 H.265 编码可以降到 3带宽直接省一半。从那以后我每次拿到建设方案都先跑一遍这个脚本把每个数字的来源标在注释里。方案可以抄但参数必须自己算一遍。希望帮到你。本文还有配套的精品资源点击获取