我正在为我的硕士论文对 Cassandra 进行一些负载测试。为实际测试确定好的值的测试之一是测试每行应该存储多少测量值（我称之为时间宽度）。
长话短说，结果绝对不是我所期望的。我运行两组测试，一组存储 100,000 个值/行，另一组存储 10,000 个值/行。对于这两个时间宽度中的每一个，我都发出了具有不同范围的范围查询。范围是指每个查询请求多少个值。范围是：3600 和 10000。
我所期待的是，对于请求许多值（50,000 和 100,000）的查询，100,000 时间宽度的性能会更好，而对于 10,000 的时间宽度，10,000 时间宽度会更好。然而，在所有情况下，100,000 时间宽度的表现都更好，如下表所示。这些指标记录在 OpsCenter 上。
时宽 100,000
平均操作数/秒：18167.56（范围 3600）| 5097.61（范围 10000）
平均延迟/秒（毫秒）：1.24（范围 3600）| 2.16（范围 10000）
时间宽度 10,000
平均操作数/秒：4186.35（范围 3600）| 587.78（范围 10000）
平均延迟/秒（毫秒）：4.85（范围 3600）| 48.63（范围 10000）
熟悉 Cassandra 的人可以帮我解释这些结果吗？顺便说一下，我再次运行这些测试的集群是一个 6 节点集群，具有非常强大的机器。可以提供规格，但我认为它们并不相关。我对为什么这两个测试有这么大的性能差异感兴趣。对于测试，我正在使用使用 Hector 的自定义程序。我总共运行了 60 个客户端实例，它们尽可能快地查询 Cassandra（它不受某种限制）。我们使用的是 Cassandra 1.2 datastax 版本。
编辑：确实应该提到我所使用的数据模式。这是信息。首先，我们正在存储传感器数据（几乎是时间戳-值对）。在每一行上，行键是该行的标识符（例如实际测量、模拟1、预测1 等），以及该行的起始时间戳。所以行键看起来像 . 在该行中的每个键值对上，我们将时间戳存储为行键，并将实际测量值存储为值部分。
除此之外，我们还在同一列族中保留了一个手动索引行。在该索引行上，我们存储 identfier_meta（例如 Simulation1_meta），在该行的每个键值对上，我们将起始时间戳存储为列键，将包含相应测量值的行键存储为值。
因此，对于每次读取，我们首先确定涉及哪些行（通过查询索引），然后获取我们想要的实际数据。至于二级索引，目前我们没有使用它们。再次，如果您需要任何进一步的信息，请随时询问。