共计 1567 个字符，预计需要花费 4 分钟才能阅读完成。
为什么需要基准测试？
在数据库选型和性能优化中，基准测试就像汽车的「试驾」环节。它能帮我们：
- 验证集群是否达到预期性能指标
- 发现配置参数的不合理设置
- 为容量规划提供数据支持
- 比较不同版本 / 架构的性能差异
Cassandra 自带的 cassandra-stress 工具，是官方推荐的性能测试利器。下面我会手把手带大家从安装到结果分析走完全流程。
环境准备与工具安装
测试前需要准备好：
- 至少 3 节点的 Cassandra 集群（单机模式仅适合功能验证）
- 与被测集群分离的测试机器（避免资源争抢）
- 相同版本的 cassandra-stress 工具（通常位于 Cassandra 安装包的
tools/bin目录）
安装验证命令：
./cassandra-stress help
# 应显示包含 write/read/mixed 等子命令的帮助信息测试配置实战
基础写入测试
创建 write-test.yaml 配置文件：
# 基础表结构定义
keyspace: stress_ks
keyspace_definition: |
CREATE KEYSPACE stress_ks WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1': 3}
table: stress_table
table_definition: |
CREATE TABLE stress_table (
pk bigint PRIMARY KEY,
data text
)
# 测试参数
column:
size: fixed(1024) # 每条记录 1KB
insert:
partitions: fixed(1000000) # 测试 100 万条记录
batchtype: UNLOGGED # 批量写入模式执行测试：
./cassandra-stress write n=1000000 -rate threads=50 -schema file=write-test.yaml关键参数说明：
n：总操作次数rate：控制吞吐量threads：并发客户端数
混合读写测试
# 复用之前的表结构
read:
filters:
slice: # 查询条件
- pk >= 1 and pk <= 1000000
queries:
simple1:
cql: select * from stress_table where pk = ?
fields: samerow # 从写入数据中随机选取 PK执行命令：
./cassandra-stress mixed ratio\(write=1,read=3\) duration=10m -schema file=mixed-test.yaml结果解读技巧
测试完成后会输出类似如下统计信息：
Results:
Op rate : 12,345 ops/s
Partition rate: 11,111 pk/s
Latency mean : 4.5 ms
Latency 95th : 8.2 ms重点关注指标：
- 吞吐量（Op rate）：系统每秒处理的操作数
- 延迟分布（Latency）：特别是 95/99 分位值
- 错误率（Errors）：非零值需要警惕
常见性能瓶颈
Compaction 堆积
现象：写入速度随时间持续下降
解决方法：
- 调整 compaction 策略
- 增加 compaction 线程数
- 监控
nodetool compactionstats
网络延迟
现象：客户端与服务端延迟差异大
解决方法：
- 检查网络设备
- 优先使用万兆网络
- 测试机与集群同机房部署
生产环境注意事项
- 测试数据规模至少是生产数据的 30%
- 压力测试要包含峰值 2 - 3 倍的余量
- 真实场景的访问模式可能更复杂
- 建议定期执行基准测试建立性能基线
延伸学习
- 对比 YCSB 等第三方测试工具
- 学习
nodetool tablestats监控命令 - 研究动态扩容策略（如添加新节点）
通过本文的实践，你应该已经掌握了 Cassandra 性能测试的基本方法。记住，基准测试不是一次性的工作，而应该成为持续优化的常规手段。
正文完
