# 存储与容量规划
> ServerBee 常用部署场景的数据库容量计算公式和 30 天存储估算。
URL: https://docs.serverbee.app/zh/docs/storage-sizing
本页介绍 ServerBee 的 SQLite 数据库如何随时间增长，并为常见的 20 服务器部署场景提供 30 天存储估算。
这些数值于 2026 年 4 月通过临时 SQLite 数据库测量得出，采用当时的仓库数据库结构和默认保留策略。请将本页作为注明日期的容量规划基准，而不是对后续数据库结构或工作负载的保证。结果描述的是全新部署运行 30 天后的主数据库文件大小。在生产环境中，请额外预留 10% 到 20% 的空间作为 SQLite WAL（预写日志）和临时增长的缓冲。
## 假设条件 [#假设条件]
本页所有估算使用以下基线条件：
* **20 台服务器**
* 从全新部署开始运行 **30 天**
* Agent 持续连接
* Agent 上报间隔为 **3 秒**
* 服务器原始指标写入器每 **60 秒** 为每台服务器写入一条记录
* 默认保留策略：
* 原始指标：**7 天**
* 小时聚合数据：**90 天**
* GPU 记录：**7 天**
* Ping 记录：**7 天**
* 网络探针原始记录：**7 天**
* 网络探针小时记录：**90 天**
* 服务监控记录：**30 天**
* 磁盘 I/O 和温度监控已启用
* 除非明确说明，否则不包含审计日志突发增长、大型任务输出或异常的 Docker 事件波动带来的额外增长
## 哪些功能会影响数据库大小 [#哪些功能会影响数据库大小]
并非每个功能都会产生持续的数据库增长。
| 功能 | 默认频率 | 保留时间 | 主表 | 说明 |
| --------------- | ----------------------- | -------------- | ----------------------------------------------------- | --------------- |
| 基础监控 | Agent 每 3 秒上报，每 60 秒持久化 | 原始 7 天，小时 90 天 | `records`、`records_hourly`、`traffic_*`、`uptime_daily` | 连接的服务器始终存在 |
| Ping 任务 | 每任务 60 秒 | 7 天 | `ping_records` | 随任务数 × 服务器数扩展 |
| 网络探针 | 每目标 60 秒 | 原始 7 天，小时 90 天 | `network_probe_record`、`network_probe_record_hourly` | 随服务器-目标分配数扩展 |
| 服务监控 | 每监控 300 秒 | 30 天 | `service_monitor_record` | 随监控数扩展 |
| GPU 监控 | 每 GPU 设备 3 秒 | 7 天 | `gpu_records` | 这是最大的乘数之一 |
| Docker 事件 | 事件驱动 | 7 天 | `docker_event` | 除非容器频繁变更，否则占用很小 |
| 终端 / 执行 / 文件管理器 | 用户驱动 | 混合 | `audit_logs`、`task_results` | 通常比时序数据小得多 |
开启终端、执行、文件管理器或 Docker 管理等功能不会自动创建大型时序表。持续增长来自那些主动写入采样结果的功能。
## 30 天容量估算公式 [#30-天容量估算公式]
基于上述假设，30 天数据库大小可通过以下公式估算：
```text
S_30d =
70,541,312
+ 48,974,507 × P
+ 2,373,018 × T
+ 1,593,958 × M
+ 41,525,248 × G
+ 285 × E
```
其中：
* `P` = 应用于全部 20 台服务器的 **60 秒 Ping 任务** 数量
* `T` = 总的 **服务器-目标网络探针分配数**
* 如果每台服务器目标数相同，则 `T = 20 × 每台服务器目标数`
* `M` = 总的 **300 秒服务监控数**
* `G` = 总的 **GPU 设备数**
* `E` = 30 天窗口期内写入的 **Docker 事件总数**
## 功能乘数 [#功能乘数]
这些系数来自实际测量的 SQLite 文件，而非粗略估算：
| 组件 | 精确大小贡献 | 约等大小 |
| ----------------------- | -------------- | ----------- |
| 20 台服务器的基础监控 | `70,541,312 B` | `67.27 MiB` |
| 1 个跨全部 20 台服务器的 Ping 任务 | `48,974,507 B` | `46.71 MiB` |
| 1 个网络探针分配 | `2,373,018 B` | `2.26 MiB` |
| 1 个服务监控 | `1,593,958 B` | `1.52 MiB` |
| 1 个 GPU 设备 | `41,525,248 B` | `39.60 MiB` |
| 1 个 Docker 事件 | `285 B` | `0.28 KiB` |
## 基础监控细目 [#基础监控细目]
在没有额外 Ping 任务、网络探针、服务监控或 GPU 的情况下，30 天占用空间主要来自原始指标表及其索引：
| 对象 | 精确大小 | 约等大小 |
| -------------------------------- | -------------- | ----------- |
| `records` | `48,701,440 B` | `46.45 MiB` |
| `idx_records_server_id_time` | `16,482,304 B` | `15.72 MiB` |
| `records_hourly` | `3,485,696 B` | `3.32 MiB` |
| `idx_records_hourly_server_time` | `1,163,264 B` | `1.11 MiB` |
| `traffic_hourly` + 索引 | `512,000 B` | `0.49 MiB` |
| `traffic_daily` + 索引 | `90,112 B` | `0.09 MiB` |
| `uptime_daily` + 索引 | `86,016 B` | `0.08 MiB` |
## 场景目录 [#场景目录]
下表列出 20 台服务器部署的常见 30 天场景：
| 场景 | 假设条件 | 精确大小 | 约等大小 |
| ---------------- | ----------------------------------------------- | ----------------- | ------------ |
| 仅基础监控 | 无 Ping 任务、无网络探针、无服务监控、无 GPU | `70,541,312 B` | `67.27 MiB` |
| 基础 + 1 个 Ping 任务 | 1 个跨全部 20 台服务器的 60 秒 Ping 任务 | `119,515,819 B` | `113.98 MiB` |
| 基础 + 3 个 Ping 任务 | 全部 20 台服务器的 ICMP + TCP + HTTP | `217,464,833 B` | `207.39 MiB` |
| 基础 + 每台 1 个目标 | 共 20 个网络探针分配 | `118,001,672 B` | `112.54 MiB` |
| 基础 + 每台 5 个目标 | 共 100 个网络探针分配 | `307,843,112 B` | `293.58 MiB` |
| 基础 + 每台 20 个目标 | 共 400 个网络探针分配（当前上限） | `1,019,748,512 B` | `972.51 MiB` |
| 基础 + 每台 1 个监控 | 共 20 个 300 秒间隔的服务监控 | `102,420,472 B` | `97.68 MiB` |
| 基础 + 每台 5 个监控 | 共 100 个 300 秒间隔的服务监控 | `229,937,112 B` | `219.29 MiB` |
| 基础 + 每台 1 个 GPU | 共 20 个 GPU 设备 | `901,046,272 B` | `859.30 MiB` |
| 小型生产环境 | 3 个 Ping 任务 + 每台 1 个目标 + 每台 1 个监控 | `296,804,353 B` | `283.05 MiB` |
| 中型生产环境 | 3 个 Ping 任务 + 每台 5 个目标 + 每台 2 个监控 | `518,524,953 B` | `494.50 MiB` |
| 重型环境（无 GPU） | 3 个 Ping 任务 + 每台 20 个目标 + 每台 1 个监控 | `1,198,551,193 B` | `1.12 GiB` |
| 重型环境（含 GPU） | 重型环境（无 GPU）+ 每台 1 个 GPU | `2,029,056,153 B` | `1.89 GiB` |
| 最大实用环境 | 3 个 Ping 任务 + 每台 20 个目标 + 每台 5 个监控 + 每台 1 个 GPU | `2,156,572,793 B` | `2.01 GiB` |
## 磁盘预算建议 [#磁盘预算建议]
如果正在为实际部署进行容量规划，请预留比数据库文件本身更多的空间：
* 以上表作为**基础数据库大小**
* 增加 **10% 到 20%** 作为 WAL 增长和突发写入的缓冲
* 如果预期有以下情况，请额外增加空间：
* 大量 Docker 事件
* `task_results` 中保留的大型任务输出
* 具有大型 `detail_json` 负载的异常频繁的服务监控
示例：
* 一个 `494.50 MiB` 的中型环境应预留约 **550 MiB 到 600 MiB**
* 一个 `1.89 GiB` 的含 GPU 重型环境应预留约 **2.1 GiB 到 2.3 GiB**
* 一个 `2.01 GiB` 的最大实用环境应预留约 **2.2 GiB 到 2.5 GiB**
## 注意事项和说明 [#注意事项和说明]
* 这些估算针对全新部署的**前 30 天**。某些小时表保留长达 90 天，因此长期运行的部署会继续增长，超过此处显示的 30 天数值。
* 基础监控估算已包含 `traffic_hourly`、`traffic_daily` 和 `uptime_daily`。
* GPU 增长是按**设备**计算的，不是按服务器。一台有 4 个 GPU 的服务器会使 GPU 部分乘以 4。
* 网络探针增长是按**分配**计算的，不是按目标定义。一个被 20 台服务器共享的目标算作 20 个分配。
* Docker 增长是事件驱动的。静态的容器集群几乎不增加空间；容器繁忙的主机可能增加可观的量。
## 相关文档 [#相关文档]