我在Cassandra中有一个模式，用于存储交易信息。当前模式有未绑定分区，这可能是主要的反模式，所以现在我正在使用bucket开发一个新模式，该模式将单个分区大小限制为交易一小时，所以bucket看起来像：2021-06-21-12(2021-06-21 12:00至13:00发生的交易(除了bucketing，我对新模式做了一些额外的更改：
- 设置TTL
- 更改了TimeWindowCompactionStrategy的配置-窗口大小为10天，对于旧模式为1天。根据文件，我们的目标应该是拥有20-30张sstable，所以因为我要存储一年的交易，我认为新的设置更好
- 将bloom_filter_fp_chance从0.1更改为0.01-当我有0.1-43%时，我注意到一开始有很多假阳性，然后当更改为0.01时，假阳性几乎不存在
- 在旧模式中，我们禁用了密钥缓存，启用了row-cache(100(，这对我来说没有意义，所以在新模式中，启用了密钥缓存，禁用了行缓存
在迁移了8天的数据后，我运行了几个查询来验证数据是否正确迁移。
即使我有一个更好的模式(至少我相信是这样(，在新的Cassandra中有更多的资源(更多的RAM，SSD而不是标准磁盘(，我的性能也更差
我正在执行以下新旧模式的查询：
select sum(size) from old_trades where .... and ts > '2021-06-12 12:00:00' and ts < '2021-06-12 13:00:00'
select sum(size) from new_trades where .... and bucket='2021-06-12-12';
在cqlsh上，默认情况下分页设置为100，请求旧模式需要5秒，请求新模式需要8秒
我想知道这怎么可能。在生产环境中，像select sum(size)这样的查询不会被执行，如果数据被正确迁移，我会用它来验证，但新的闪亮模式会随着旧模式而丢失，这仍然有点可怕和违反直觉。
最后，我们找到了罪魁祸首：在新的Cassandra配置中，我们错误地将Xmn设置为5MB，在旧的Cassandra中，我们将Xmn设为512MB。修复后，我们对新模式的查询速度是对旧模式的两倍。