引言
图数据库的容量规划有个反直觉的特点：它主要不是磁盘问题，而是内存问题。关系库可以靠磁盘 + 缓存撑住远大于内存的数据量，而图库的遍历性能高度依赖「邻接表命中缓存」——一旦 page cache 装不下热数据，遍历就会退化成随机 IO，性能断崖式下跌。这意味着容量规划的核心是「把图装进内存」，而内存是最贵的资源，于是「容量规划」与「成本优化」天然是一对矛盾：给少了性能崩，给多了预算烧。更麻烦的是图数据的内存占用很难凭直觉估——一条关系可能占 30~50 字节，也可能因为属性膨胀占几百字节；超节点（一个有几百万条边的节点）会让局部内存需求远超平均值。本文系统讲容量规划与成本优化：先讲方法论（从业务指标反推资源），再讲内存估算公式、堆内存与 page cache 的分配、存储估算与增长预测、分片与读写分离、云实例选型、成本构成与优化、容量压测与验证、监控与弹性伸缩，最后是决策清单与常见坑。目标：你能算出一套「有依据、能验证、可持续」的容量与成本方案。
目录
- 1. 容量规划的方法论
- 2. 内存估算公式
- 3. 堆内存与 page cache 分配
- 4. 存储估算与增长预测
- 5. 分片与读写分离
- 6. 云实例选型
- 7. 成本构成与优化
- 8. 容量压测与验证
- 9. 监控与弹性伸缩
- 10. 决策清单与常见坑
- 速查表
- 延伸阅读
1. 容量规划的方法论
从业务指标反推资源：
业务侧输入：
- 数据规模：节点数、关系数、平均属性数
- 增长速率：每天新增多少节点/关系
- 查询负载：QPS、查询类型（点查/多跳/全图算法）
- 延迟目标：P50 / P95 / P99
- 可用性目标：几个 9（决定副本数）
→ 资源 = f(数据规模, 增长, 负载, 延迟, 可用性)
容量规划的四步法：
1. 估内存：图数据常驻内存需要多少（第 2 节）
2. 估存储：磁盘需要多少（含副本与日志，第 4 节）
3. 估计算：CPU 需要多少（按查询负载与算法任务）
4. 加余量：预留 30%~50% 应对增长与突发
→ 四步各自算，最后取「木桶的最短板」
图库容量的三个特殊性：
1. 内存是硬约束：图装不进内存 → 遍历退化（不是「慢一点」）
2. 超节点拉高方差：平均度数不代表峰值，超节点局部需求极高
3. 算法任务吃资源：全图算法（PageRank/社区）需要额外内存与 CPU
→ 按「峰值 + 算法任务」规划，而非按平均
规划的时间尺度与「装得下」与「跑得快」的区别：
时间尺度：初始按「上线规模 × 2」配置 → 季度复核实际 vs 预测 → 年度结合业务曲线
装得下：图数据总量 ≤ 内存（能启动、能查）
跑得快：热数据 + 邻接表 + 索引 ≤ page cache（遍历不落盘）
→ 规划目标是「跑得快」而非「装得下」，且是持续过程而非一次性计算
心智：容量规划从业务指标（数据规模、增长速率、查询负载、延迟目标、可用性目标）反推资源，四步法是「估内存、估存储、估计算、加余量（30%~50%）」，最后取木桶最短板；图库容量的三个特殊性是「内存是硬约束（装不下就退化不是慢一点）」「超节点拉高方差（按峰值不按平均）」「算法任务吃额外资源」；规划目标是「跑得快」（热数据 + 邻接表 + 索引进 page cache）而非「装得下」，且是持续过程而非一次性计算。
2. 内存估算公式
图数据的内存构成：
总内存 = 图存储（节点 + 关系 + 属性）
+ 索引（唯一约束、属性索引、全文/向量索引）
+ 运行时开销（事务、查询中间结果、缓存）
→ 前两项是「静态」的，第三项是「动态」的（易被忽略）
节点的内存估算：
单节点开销 ≈ 记录头 + 标签指针 + 属性块指针 + 属性存储
粗略估算：
- 无属性节点：约 15~25 字节
- 带 N 个短属性：约 25 + N × 20 字节
- 长字符串属性：按实际长度 + 开销（可能单独存储）
→ 「节点本身不贵，属性才贵」
关系的内存估算（图库的大头）：
单关系开销 ≈ 关系记录（双向指针）+ 类型 + 属性
粗略估算：
- 无属性关系：约 30~50 字节
- 带属性的关系：每属性 +20 字节左右
关系通常是节点数的 2~10 倍（社交图可达几十倍）
→ 关系才是内存消耗的主体，估算时要重点看
估算公式示例：
场景：1 亿节点、5 亿关系
节点：1e8 × 25 B = 2.5 GB
关系：5e8 × 40 B = 20 GB
属性（平均每实体 3 个短属性）：
(1e8 + 5e8) × 3 × 20 B = 36 GB
索引（若干属性索引 + 唯一约束）：约 5~15 GB
运行时与缓存：预留 20%
→ 合计约 75~85 GB → 选 128 GB 内存实例（留余量）
超节点对估算的冲击：
平均度数 5 的图里可能存在度数 500 万的超节点，其邻接表是「热点中的热点」
→ 估算时要单独看「Top 1% 节点」的度数分布，而非只看平均
度数分布的量测：
// 统计度数分布（识别超节点）
MATCH (n)
WITH n, size([(n)--() | 1]) AS degree
RETURN max(degree) AS 最大度数, percentileCont(degree, 0.5) AS 中位数,
percentileCont(degree, 0.99) AS P99
索引的内存成本：
- 唯一约束：每个约「实体数 × 键大小」
- 属性索引：按索引的基数（不同值个数）估算
- 全文索引：通常比原数据还大（倒排表）
- 向量索引：HNSW 等结构内存开销可观（图 + 向量）
→ 索引常被低估，规划时要显式列出「要建哪些索引」
运行时内存的三个来源：
1. 查询中间结果：多跳遍历的中间行（可指数增长）
2. 事务与锁：并发写事务的状态
3. 缓存：查询缓存、计划缓存、对象缓存
→ 建议预留总内存的 15%~25% 给运行时
心智：图内存估算的三大块是「节点（约 15
25 B 起）、关系（约 3050 B，通常是节点数 2~10 倍甚至几十倍，是内存主体）、索引（常被低估，全文/向量索引可能比原数据还大）」，再预留 15%~25% 给运行时（查询中间结果、事务、缓存）；估算时必须看「度数分布」而非平均度数——Top 1% 的超节点邻接表是热点中的热点，会显著拉高局部需求；把「要建哪些索引」显式列出来再逐个估算，是避免低估的关键。
3. 堆内存与 page cache 分配
两类内存的分工：
堆内存（JVM Heap，若是 Java 系）：
- 事务状态、查询执行、对象缓存、GC 管理
- 太大 → GC 停顿长；太小 → OOM
page cache（操作系统页缓存）：
- 图存储文件、索引文件的缓存
- 越大越好（这是图遍历性能的关键）
→ 两者抢同一块物理内存，分配比例是关键决策
分配比例的经验值：
图数据 < 内存：page cache 尽量大；≈ 内存：堆适中 + cache 尽量大 + SSD
图数据 > 内存：必须分片或接受性能下降
经验比例：非 JVM 系 page cache 60%~75%；JVM 系堆 25%~30%、cache 50%~65%
→ 图库与关系库不同：page cache 优先级高于堆
Neo4j 的内存配置示例：
# 堆内存（根据并发查询与事务量调整）
server.memory.heap.initial_size=16g
server.memory.heap.max_size=16g
# 页缓存（图遍历性能的关键，尽量大）
server.memory.pagecache.size=48g
# 事务与查询内存
db.memory.transaction.total.max=8g
db.memory.transaction.max=2g
堆内存的调优信号：
Full GC 频繁 → 堆太小或查询中间结果大；GC 停顿影响 P99 → 堆太大或换低延迟 GC
频繁 OOM → 中间结果爆炸（加 LIMIT、限深度）→ 根因常在「查询写法」而非配置
page cache 的监控：
- 命中率：db.pageCache.hitRatio，目标 > 0.95
- 未命中数：db.pageCache.hits / faults 的差值
- 驱逐数：db.pageCache.evictions（持续驱逐 = 缓存不够）
→ 「命中率下降 + 驱逐上升」= 该加内存或分片了
关闭 swap（重要）：
- 图库的随机访问模式遇上 swap = 灾难性延迟
- 配置：vm.swappiness=1（尽量不用 swap）
- 或直接禁用 swap（前提是内存充足）
→ swap 是图库性能的隐形杀手
心智：图库有两类内存——堆（事务、查询执行、对象缓存，太大 GC 停顿长、太小 OOM）与 page cache（图存储与索引的缓存，越大越好，是遍历性能关键），两者抢同一块物理内存；经验比例是 page cache 占 60%~75%（图库与关系库不同，page cache 优先级高于堆），JVM 系堆 25%~30%；监控看 page cache 命中率（目标 > 0.95）与驱逐数，命中率下降加驱逐上升就是「该加内存或分片」的信号；必须关闭或极大降低 swap（vm.swappiness=1），swap 是图库性能的隐形杀手；大页与 NUMA 是优化项而非必做项。
4. 存储估算与增长预测
磁盘存什么：
- 图存储文件（节点/关系/属性）
- 事务日志（恢复必需，与写入量成正比）
- 索引文件（可重建但重建慢）
- 备份文件（通常最大）
→ 磁盘估算 = 图存储 + 日志 + 索引 + 备份 + 余量
备份空间的估算：
备份空间 = 单份备份大小 × 保留份数 × 压缩系数
单份备份 ≈ 图存储大小（未压缩）
压缩系数 ≈ 0.3~0.6（图数据压缩率不错）
例：图存储 100 GB、保留 7 日备 + 4 周备 + 12 月备（共 23 份）
未压缩 = 100 × 23 = 2.3 TB
压缩后 ≈ 0.8~1.4 TB
→ 备份空间常是「主数据的十倍量级」，要提前规划
增长预测的方法：
- 历史法：过去 6~12 个月的增长曲线外推
- 业务法：业务增长目标 × 单用户数据量
- 场景法：新业务上线带来的数据增量（常被漏掉）
→ 三种方法取「最悲观」作为规划输入
增长的非线性：
关系数增长常快于节点数（社交/交易图的边数增长可能超线性，网络效应）
属性也会膨胀（新功能不断加字段）→ 按「关系数」而非「节点数」预测增长
归档与冷热分层：
- 历史数据（如 3 年前的交易）查询频率极低
- 归档到低成本存储（对象存储 + 按需加载）
- 或保留在「冷图」（独立实例，按需查询）
- 效果：热数据规模可控 → 内存需求可控
→ 归档是「降低容量需求」最有效的手段之一
存储的 IO 要求：
必须 SSD（NVMe 更好）：图遍历是随机访问模式，IOPS 比容量更重要
→ 图库选盘：IOPS 优先于容量
心智：磁盘估算 = 图存储 + 事务日志 + 索引 + 备份 + 余量，其中重点是「备份 + 日志」而非主数据——备份空间常是主数据的十倍量级（保留 23 份 × 压缩系数 0.3~0.6），高写入场景的事务日志也可能超过图存储；增长预测用历史法、业务法、场景法三种取最悲观，且要按「关系数」而非「节点数」预测（边数增长常超线性）；归档与冷热分层是降低容量需求最有效的手段之一；选盘要 IOPS 优先于容量（图遍历是随机访问，必须 SSD/NVMe）。
5. 分片与读写分离
什么时候需要分片：
- 图数据总量超过单机内存上限
- 单机 CPU 无法支撑查询 QPS
- 写入量超过单机写入能力
→ 分片是「单机到极限」后的选择，不是首选
分片的两种方式：
方式 A：按实体分片（把不同实体放不同实例）
- 优点：每个分片是完整子图，查询简单
- 缺点：跨分片遍历要应用层拼接
方式 B：按关系类型分片（把不同关系放不同实例）
- 优点：按业务域隔离
- 缺点：跨域查询要拼接
→ 图分片的本质矛盾：图要连通，分片要割裂
图分片的代价：
跨分片遍历 → 多次单跳 + 网络往返；跨分片事务 → 分布式事务
全局算法 → 要「分片内计算 + 全局聚合」
→ 图分片显著增加复杂度，优先考虑「垂直拆分」而非「水平分片」
垂直拆分（优先考虑）：
- 按业务域拆成多个图：用户图 / 商品图 / 交易图
- 每个图独立部署、独立扩缩容
- 跨域关联用「引用 ID」而非真实边（应用层 join）
→ 垂直拆分不破坏「图内连通性」，代价小得多
读扩展：只读副本：
- 写走主库，读走副本（一主多从）
- 副本可专门服务「重查询」（分析、算法）
- 注意：副本有复制延迟（读到的可能不是最新）
→ 读多写少的图场景，只读副本是性价比最高的扩展
读写分离的实现要点：
- 路由层决定「这条查询走主还是走副本」
- 一致性要求高的查询走主（如写后立即读）
- 算法/报表类走副本（延迟可接受）
- 副本数量按「读 QPS / 单副本能力」估算
→ 路由策略要明确，避免「该走主的走了副本」
分片键的选择：
目标：让跨分片查询最少 → 按「业务主体」分（租户、地区），避免随机哈希
→ 分片键 = 「查询最常锚定的那个维度」
心智：分片是「单机到极限」后的选择而非首选——图分片的本质矛盾是「图要连通、分片要割裂」，代价是跨分片遍历变成多次网络往返、跨分片事务要用分布式事务、全局算法要「分片内计算 + 全局聚合」；因此优先考虑「垂直拆分」（按业务域拆成多个图，跨域用引用 ID 而非真实边，不破坏图内连通性）而非水平分片；读扩展首选只读副本（写走主、读走副本、重查询走副本，注意复制延迟），路由策略要明确「一致性要求高的走主」；水平分片键要选「查询最常锚定的维度」（如租户、地区），避免随机哈希。
6. 云实例选型
实例类型的选择逻辑：
内存型（如 r 系列）：
- 图库的首选（内存是硬约束）
- 适合：图数据大、page cache 需求高
通用型（如 m 系列）：
- 适合：中等规模图、负载均衡
计算型（如 c 系列）：
- 适合：算法任务重（全图计算）、查询 CPU 密集
存储型（如 i / d 系列）：
- 适合：本地 NVMe 需求（IOPS 极高）
→ 图库默认选「内存型」，算法任务多的选「计算型」
实例选型的对照表：
| 场景 | 实例类型 | 关键指标 |
|---|---|---|
| 大图 + 高并发点查 | 内存型 | 内存容量、内存带宽 |
| 全图算法为主 | 计算型 | vCPU 数、主频 |
| 高写入（CDC 入图） | 通用型 + 高 IOPS 盘 | 写入 IOPS、网络带宽 |
| 超低延迟要求 | 存储型（本地 NVMe） | 本地盘 IOPS、延迟 |
| 成本敏感 + 可容忍延迟 | 通用型 + 网络盘 | 单位内存价格 |
托管服务 vs 自建：
托管：免运维、自动备份、弹性；但单位成本高、定制受限、导出有成本
自建：成本可控、完全定制；但备份/升级/监控都要自己做
→ 小团队托管、大团队自建，常混合（核心自建 + 边缘托管）
存储类型、网络带宽与预留策略：
存储：主数据用「云盘（选高 IOPS 档）或本地 NVMe」，备份用对象存储
带宽：集群复制、大结果集、跨区域容灾都吃带宽且按流量计费（易忽略）
预留：稳定负载用预留（省 40%~60%），基线预留 + 峰值按需
心智：云实例选型默认选「内存型」（图库内存是硬约束），算法任务重的选「计算型」，高写入选「通用型 + 高 IOPS 盘」，超低延迟选「存储型（本地 NVMe）」；托管服务免运维但单位成本高、自建成本可控但运维负担重，常「核心自建 + 边缘托管」混合；主数据用云盘或本地 NVMe、备份用对象存储；网络带宽是容易忽略的成本项（集群复制、跨区域容灾都吃带宽且按流量计费）；预留实例是成本优化最大的一刀（稳定负载可省 40%~60%），基线用预留、峰值用按需。
7. 成本构成与优化
图库成本的构成：
1. 计算（实例）：通常占 50%~70%（内存型最贵）
2. 存储（云盘 + 对象存储）：占 10%~25%
3. 备份与归档存储：占 5%~15%（随保留期增长）
4. 网络（跨 AZ / 跨区域流量）：占 5%~15%
5. 运维人力：自建场景的隐性大项
→ 计算是主成本，但备份与网络的「长尾」常被低估
成本优化的六个方向：
1. 内存利用率：page cache 命中率高 = 没白花钱
2. 归档冷数据：把历史数据移出热图（降内存需求）
3. 预留实例：稳定负载用预留（省 40%~60%）
4. 副本数优化：非关键场景减少副本
5. 备份分层：近期高性能存储、远期归档存储
6. 查询治理：消灭全表扫描与无 LIMIT 查询（省 CPU）
→ 前三个是「大钱」，后三个是「小钱但容易做」
「省钱省出事故」的三种典型：
1. 内存减半 → page cache 装不下 → 遍历退化为随机 IO → P99 暴涨
2. 副本减一 → 单副本故障 → 服务中断（可用性目标没达成）
3. 备份保留缩短 → 数据错误发现晚 → 无备份可恢复
→ 成本优化不能碰「内存、副本、备份保留」这三条底线
单位成本指标与 TCO 视角：
单位成本：每百万节点 / 每万 QPS / 每 GB 图数据 的每月成本
→ 横向对比「加内存 vs 分片 vs 归档」哪个更划算
TCO = 实例 + 存储 + 备份 + 网络 + 人力 + 许可
自建常忽略人力与机会成本；托管常忽略导出成本与锁定风险
成本的可观测性：
按「图 / 租户 / 应用」分摊成本，监控「每查询成本」，定期输出成本报告
→ 没有成本可观测性，优化就无从下手
心智：图库成本构成是「计算 50%~70%、存储 10%~25%、备份 5%~15%、网络 5%~15%、人力（自建隐性大项）」，计算是主成本但备份与网络的长尾常被低估；优化六方向里「内存利用率、归档冷数据、预留实例」是省大钱的，后三个（副本数、备份分层、查询治理）是小钱但容易做；三条底线不能碰——内存（装不下就退化）、副本（减了可用性目标就达不到）、备份保留（缩短了可能无备份可恢复），「省钱省出事故」的典型就是这三种；用「每百万节点/每万 QPS/每 GB 每月」的单位成本横向对比方案，并把人力与导出成本等隐性项显式纳入 TCO。
8. 容量压测与验证
为什么必须压测：
- 公式估算有误差（属性膨胀、超节点、查询形态）
- 「估算够用」和「实测够用」是两件事
- 压测能暴露：内存不足、索引缺失、查询计划退化
→ 压测是容量方案的「验收测试」
压测的四个维度：
1. 数据量：真实规模的数据（或按比例缩放）
2. 查询负载：真实查询的分布（不是均匀随机）
3. 并发度：目标 QPS 及其峰值
4. 持续时间：至少 1 小时（看内存是否持续增长）
→ 四个维度缺一不可，「只压 QPS 不压数据量」没有意义
压测数据要「真实」：
- 用真实数据的脱敏副本，或按真实分布生成
- 关键：度数分布要真实（含超节点）
- 属性分布要真实（长字符串、空值、大数组）
→ 用均匀随机图压测 = 自欺欺人（没有超节点）
压测的关注指标：
- 延迟：P50 / P95 / P99（P99 最重要）
- 吞吐：QPS 峰值与稳定值
- 内存：page cache 命中率、堆使用、GC 停顿
- 错误率：超时、OOM、连接耗尽
→ 延迟看 P99，内存看命中率与 GC
压测的阶梯设计：
单查询基准 → 逐步加并发找拐点（延迟开始非线性上升的点）
→ 峰值保持（看内存与 GC）→ 长时间运行 1~24 小时（看泄漏）
→ 「找拐点」比「报峰值」更有价值
压测工具与结果解读：
# 用 cypher-shell 做简单并发压测（生产建议用 JMeter / k6 + Bolt 驱动）
for i in $(seq 1 50); do
( for j in $(seq 1 200); do
cypher-shell -a bolt://localhost:7687 \
"MATCH (p:Person {id: $((RANDOM % 100000))}) RETURN p.name" >/dev/null 2>&1
done ) &
done
wait
记录「每查询耗时分布」而非平均值 → 压测要能复现「生产查询的分布」
- 拐点出现得早 → 内存不足或索引缺失
- P99 远高于 P50 → 存在超节点或缓存未命中
- 内存持续增长 → 查询中间结果未释放 / 泄漏
- 吞吐上不去但 CPU 不满 → IO 瓶颈（page cache 不够）
→ 每个现象都指向一个具体的容量问题
心智：压测是容量方案的验收测试，四维度缺一不可（真实数据量、真实查询分布、目标并发与峰值、至少 1 小时持续时间）；压测数据必须真实——关键是「度数分布要含超节点」与「属性分布要真实」，用均匀随机图压测等于自欺欺人；关注指标是「延迟看 P99、内存看 page cache 命中率与 GC 停顿、错误率看超时与 OOM」；阶梯设计（单查询基准 → 逐步加并发找拐点 → 峰值保持 → 长时间运行看泄漏）比直接报峰值更有价值；结果解读有明确对应——拐点早=内存/索引不足、P99 远高于 P50=超节点或缓存未命中、内存持续增长=中间结果未释放、吞吐上不去但 CPU 不满=IO 瓶颈。
9. 监控与弹性伸缩
容量相关的监控指标：
内存类：
- page cache 命中率与驱逐数
- 堆使用率与 GC 停顿
- 系统可用内存与 swap 使用
存储类：
- 磁盘使用率与增长速率
- IOPS 与 IO 延迟
负载类：
- QPS、查询延迟分位、慢查询数
- 写入 QPS 与复制延迟
→ 监控要能「提前预警」，而不是「事后告警」
预警阈值的设定：
- page cache 命中率 < 0.95 → 预警（容量不足的信号）
- 磁盘使用率 > 70% → 预警（备份可能写不下）
- 慢查询数周环比 +50% → 预警（负载或数据增长）
- 堆使用率持续 > 80% → 预警（GC 风险）
→ 阈值要「早于故障」，给人留出扩容时间
容量趋势的预测：
用监控数据做趋势外推（如内存使用 30 天斜率）→ 预测「多久后触及上限」
→ 「还有多少天到上限」比「当前使用率」更有决策价值
弹性伸缩的可行性：
无状态服务容易弹性；图数据库难弹性（数据要重新分布）
加只读副本可弹性（读扩展）；加分片不可弹性（重新分片成本高）
→ 图库的「弹性」主要是「读侧弹性」与「垂直扩容」
垂直扩容窗口、自动化边界与成本联动：
扩容：换更大实例需重启（有停机窗口），常用「主备切换式扩容」并要演练
自动化边界：读副本与存储可自动伸缩，主实例人工把关（重启风险高）
成本联动：用「预留基线 + 按需峰值」，定期复核实际用量 vs 预留量
→ 弹性不是「随时加机器」，是「按需且有预算约束」
心智：容量监控要分三类（内存类：page cache 命中率与驱逐、堆使用与 GC、swap；存储类：磁盘使用率与增长速率、IOPS 与延迟；负载类：QPS 与延迟分位、慢查询数、写入与复制延迟），阈值要「早于故障」给人留扩容时间；趋势预测里「还有多少天触及上限」比「当前使用率」更有决策价值；图库的弹性主要是「读侧弹性（加只读副本）+ 垂直扩容」，水平分片不可弹性（重新分片成本高）；垂直扩容需要停机窗口并要演练（常用主备切换式扩容）；自动化边界是「读与存储自动、主实例人工把关」，弹性要配预算约束（预留基线 + 按需峰值）。
10. 决策清单与常见坑
容量规划的决策顺序：
1. 先定「内存需求」（图数据 + 索引 + 运行时 + 余量）
2. 再定「存储需求」（图存储 + 日志 + 索引 + 备份 + 余量）
3. 然后选「实例类型与规格」（内存型优先）
4. 再算「副本数」（按可用性目标）
5. 最后算「成本」并做优化（预留、归档、分层）
→ 顺序不能反：先选实例再算需求 = 拍脑袋
规划检查清单：
[ ] 数据规模：节点数、关系数、属性数（含分布，不只平均）
[ ] 度数分布：P50 / P99 / 最大值（识别超节点）
[ ] 索引清单：要建哪些索引，各自的内存开销
[ ] 内存估算：图 + 索引 + 运行时（15%~25%）+ 余量（30%~50%）
[ ] page cache 目标：命中率 > 0.95 所需内存
[ ] 存储估算：图存储 + 日志 + 备份（含保留份数）
[ ] 增长预测：按关系数外推（最悲观的算法）
[ ] 副本数：按可用性目标（几个 9）
[ ] 压测验证：真实数据分布 + 阶梯并发 + 长时间运行
[ ] 成本方案：预留基线 + 按需峰值 + 归档分层
[ ] 监控预警：命中率、磁盘、慢查询、堆使用
[ ] 扩容演练：垂直扩容的停机窗口与切换流程
常见坑清单：
坑 1：按「节点数」估内存，忽略「关系数」才是大头
坑 2：按平均度数规划，忽略超节点拉高的方差
坑 3：忘记算索引内存（全文/向量索引可能比原数据还大）
坑 4：不预留运行时内存 → 查询中间结果导致 OOM
坑 5：page cache 给太少 → 遍历退化，P99 断崖
坑 6：忘记算备份空间（常是主数据十倍量级）
坑 7：用均匀随机图压测 → 没有超节点，结果虚高
坑 8：swap 未关 → 随机访问遇上 swap，延迟灾难
坑 9：只压 QPS 不压数据量 → 小数据上的高性能无意义
坑 10：为省钱减内存/减副本/缩备份 → 省出事故
坑 11：水平分片过早 → 复杂度暴涨，收益有限
坑 12：没有成本可观测性 → 花在哪、省在哪都不知道
心智：容量规划的决策顺序不能反——先定内存需求、再定存储需求、然后选实例类型、再算副本数、最后算成本并优化；十二个坑集中在四处——估算口径错（按节点数不按关系数、按平均不按峰值、忘算索引与运行时、忘算备份）、配置失当（page cache 太少、swap 未关）、验证不真实（均匀随机图压测、只压 QPS 不压数据量）、决策失误（为省钱碰三条底线、过早水平分片、无成本可观测性）；扩容按「垂直 → 读扩展 → 垂直拆分 → 水平分片」的顺序考虑，别一上来就分片。
速查表
内存估算速记：
| 对象 | 粗略开销 | 备注 |
|---|---|---|
| 节点 | 15~25 B 起 | 属性另算 |
| 关系 | 30~50 B 起 | 通常是节点数 2~10 倍 |
| 短属性 | 约 20 B | 「属性才贵」 |
| 索引 | 按基数 | 全文/向量可能超原数据 |
| 运行时 | 总内存 15%~25% | 查询中间结果 |
分配与阈值速记：
page cache 60%~75%（图库优先级最高）/ 堆 25%~30% / 其余留 OS
命中率目标 > 0.95；vm.swappiness=1；必须 SSD/NVMe
磁盘预警 70%；慢查询周环比 +50% 预警
扩容顺序速记：
垂直扩容 → 加只读副本 → 垂直拆分业务域 → 水平分片（最后手段）
三条底线不碰：内存、副本数、备份保留期
一句话记忆：图数据库容量规划的核心不是磁盘而是内存——图遍历依赖邻接表命中 page cache，装不下就退化成随机 IO 而不是「慢一点」，所以规划目标是「跑得快」（热数据 + 邻接表 + 索引进缓存，命中率 > 0.95）而非「装得下」；估算按「节点（1525 B）+ 关系（3050 B，通常是节点数 2~10 倍，是内存主体）+ 索引（常被低估，全文/向量可能超原数据）+ 运行时（15%~25%）+ 余量（30%~50%）」，且必须看「度数分布」而非平均度数（Top 1% 超节点会显著拉高局部需求）；内存分配上图库与关系库不同——page cache 优先级高于堆，经验比例 page cache 60%~75%、堆 25%~30%，且必须关闭或极大降低 swap；磁盘估算重点是「备份 + 日志」而非主数据（备份常是主数据十倍量级），增长按「关系数」外推并取最悲观；扩展按「垂直扩容 → 加只读副本 → 垂直拆分业务域 → 水平分片」的顺序，别一上来就分片（图分片的本质矛盾是「图要连通、分片要割裂」）；成本上计算占 50%~70% 是主项，优化的大钱在「内存利用率、归档冷数据、预留实例」，但三条底线不能碰——内存、副本数、备份保留期，因为「省钱省出事故」的典型就是这三种；最后一定要压测验证（真实度数分布含超节点、阶梯并发找拐点、至少 1 小时看内存），并建「早于故障」的预警监控与趋势预测（「还有多少天触及上限」比「当前使用率」更有决策价值）。
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。