在我们的生产服务器中，我们看到更高的 p99。修复后运行了 3 周，仍然只有 85% 修复。这是多种原因造成的。其中之一是 - Cassandra LIMIT 1 未优化。
但今天我想讨论访问模式。过去 12 小时内
| HTTP 响应状态 | 不。请求数 |
|---|---|
| 200 | 61041189 |
| 404 | 7971055 |
大约 12% 的读取是针对尚不存在的分区的，奇怪的遗留逻辑很难立即更改。
压缩策略：大小
bloom_filter_fp_chance=0.01
nodetool cfstats将布隆过滤器更改为
.001您的误报率看起来不错，或者至少与配置相当 - 配置为在 1.00% 的时间内出现误报，而实际比率为 0.84%
您在 cfstats 中看到的总共
204 164 614误报可能看起来很大，但代表了大约 25 500 000 000 布隆过滤器检查中误报的数量，并且只应进行分析与总数相关，而不是其本身。
您仍然可以减少误报机会，但这可能不值得。 如果表的 sstable 足够小（最多 >10GB），即使读取通过了布隆过滤器检查，误报读取的开销也应该可以忽略不计。如果您的 sstable 数量级为 100 GB 或 TB，那么开销可能证明重新调整 BF 误报机会是合理的。
如果您确实降低了误报几率，则会付出双重代价：
简短的答案是，如果您能负担得起存储和内存成本，则可以减少误报的机会。
尽管如此，如果目标是提高读取性能，通常布隆过滤器并不是罪魁祸首 - 我还会研究其他因素，例如：
nodetool cfstats