NoSQL 性能调优方法论：从慢查询到容量模型

NoSQL 性能问题经常被简化成“加机器”或“加索引”。这两个动作有时有效，但也可能掩盖真正问题。错误分区键导致热点，加机器也无法解决；索引过多导致写入变慢，加索引反而更糟。

性能调优的核心是建立证据链：请求从应用到数据库经历了什么，瓶颈在哪里，优化动作会改变哪个环节。

先定义目标

优化前要明确目标：

• p95 延迟降到多少。
• 写入吞吐提升多少。
• 高峰期错误率降到多少。
• 单节点资源水位控制在多少。
• 成本是否允许增加。

没有目标的优化容易变成无止境调参。

识别瓶颈层

一次数据库请求可能卡在多个层面：

• 应用连接池不足。
• 客户端重试放大。
• 网络延迟。
• 数据库 CPU 高。
• 磁盘 IO 高。
• 锁或并发控制等待。
• 查询扫描过多数据。
• 分区热点。
• 后台压缩、合并或 GC。

不同数据库指标不同，但分析思路相同：先看端到端延迟，再拆分客户端、网络、服务端和存储层。

慢查询分析

慢查询不是只看耗时。还要看扫描量、返回量、索引命中、排序、聚合、分区范围。

MongoDB 看 explain，Elasticsearch 看 profile，Cassandra 看 tracing，Redis 看 slowlog。每个系统工具不同，但都要回答：

• 是否访问了过多数据。
• 是否命中正确索引或分区。
• 是否存在大 key 或大文档。
• 是否有深分页或大聚合。
• 是否可以预计算。

慢查询治理应进入常态化流程，而不是事故后临时处理。

热点问题

分布式数据库最怕热点。集群整体资源很低，但某个 shard、partition、slot 或节点打满，用户仍然会感到慢。

热点来源：

• 单个大客户。
• 单调递增 key。
• 热门商品或活动。
• 全局计数器。
• 时间窗口集中写入。

解决方式包括 key 打散、时间分桶、局部聚合、异步汇总、读副本、本地缓存。不要只看集群平均值，平均值会掩盖热点。

索引权衡

索引能提升读取，也会拖慢写入。每次写入都要维护索引，索引还占用内存和磁盘。高写入系统要严格控制索引数量。

索引设计应基于真实查询频率和业务价值。低频后台查询不一定值得为它增加昂贵索引，可以转移到离线分析或搜索系统。

批量与并发

批量写入通常能提升吞吐，但批太大会造成延迟尖刺和失败重试成本。并发太低吃不满资源，并发太高会触发队列积压、连接耗尽或数据库限流。

建议通过压测找到甜点：

• batch size。
• 并发 worker 数。
• 连接池大小。
• 超时和重试策略。
• 限流阈值。

客户端重试要带退避和抖动。没有退避的重试会在故障时制造流量风暴。

容量模型

生产优化最终要落到容量模型：

• 每秒读写请求数。
• 平均和峰值文档大小。
• 索引放大比例。
• 副本数量。
• 压缩或合并开销。
• 保留周期。
• 增长率。

例如每日写入 500GB 原始数据，索引放大 1.5 倍，副本 1 份，保留 30 天，那么存储需求约为 500GB * 2.5 * 30，再加上 compaction、snapshot 和水位余量。

没有容量模型，扩容只能靠感觉。

压测与回归

NoSQL 性能高度依赖数据分布。压测不能只用少量均匀数据。要模拟真实热点、文档大小、查询条件、写入峰值和后台任务。

每次重大索引、分片、版本或硬件调整后，都应做性能回归。数据库优化不是一次性项目，而是随业务增长持续调整。

总结

NoSQL 性能调优要从访问模式和容量模型出发。慢查询、索引、分区、热点、连接池、批量写入和后台任务都可能是瓶颈。真正有效的优化不是某个参数，而是用数据证明瓶颈、用实验验证改动、用容量模型预测增长。这样才能让数据库在业务增长时保持可控，而不是靠临时扩容续命。