容量规划
本指南提供了关于 GreptimeDB 的 CPU、内存和存储需求的一般建议。
本页的比例和容量数字来自 Greptime 的测试和交付经验。 请把它们当作容量规划的起点，并用自己的负载验证。
GreptimeDB 具备超轻量级的启动基准， 这使数据库能以最少的服务器资源启动。 然而当为生产环境配置服务器容量时， 以下关键因素需要被考虑：
- 每秒处理的数据点数
- 每秒查询请求
- 数据量
- 数据保留策略
- 硬件成本
要监控 GreptimeDB 的各种指标，请参阅监控。
CPU
一般来说，大量并发查询、处理大量数据或执行其他计算密集型操作的应用需要更多的 CPU 核数。
以下是一些关于 CPU 资源使用的建议， 但实际使用的 CPU 核数取决于你实际的工作负载。
你可以考虑将 30% 的 CPU 资源用于数据写入， 剩余 70% 用于查询和分析。
一般推荐 CPU 到内存的比例为 1:4（例如，8 核 32 GB）， 如果你的主要工作负载是数据写入且查询请求较少， 1:2 的比例（8 核 16 GB）也是可以接受的。
内存
一般来说，内存越大，查询速度越快。 对于基本工作负载，建议至少有 8 GB 的内存，对于更高级的工作负载，建议至少有 32 GB 的内存。
存储空间
GreptimeDB 会对落盘数据做压缩，落盘数据通常约为原始数据的 1/8 到 1/10。 实际压缩率取决于表结构、列类型以及数据本身的重复程度。
数据可以存储在本地文件系统或云存储中，例如 AWS S3。 有关存储选项的更多信息， 请参阅存储配置文档。
由于云存储在存储管理方面的简单性，强烈推荐使用云存储进行数据存储。 使用云存储时，本地磁盘主要用于查询相关的缓存和 Write-Ahead Log (WAL)，一般 200GB 左右就够用。 请按自己的缓存配置和 WAL 保留时间来估算，不要把 200GB 当作固定要求。
无论你选择云存储还是本地存储， 建议设置保留策略以有效管理存储成本。
举例
假设你的数据库每秒处理约 200 个简单查询请求（QPS），每秒处理约 300k 数据点的写入请求，使用云存储存储数据。
在这种写入和查询速率下， 以下是你可能分配资源的示例：
- CPU：8 核
- 内存：32 GB
- 存储空间：200 GB
这套配置是否成立，取决于表结构、平均行宽、索引与 TTL 配置，以及 200 QPS 背后查询的时间范围和并发度。 上线前请用自己的 负载实际跑一遍，观察写入延迟、查询延迟和内存占用。