Cassandra 压力测试结果评估

Question

我已经使用 cassandra-stress 工具来评估我的 cassandra 集群已经有一段时间了。

我的问题是我无法理解为我的特定用例生成的结果。

我的架构如下所示：

CREATE TABLE Table_test(
      ID uuid,
      Time timestamp,
      Value double,
      Date timestamp,
      PRIMARY KEY ((ID,Date), Time)
) WITH COMPACT STORAGE;

我已经在自定义 yaml 文件中解析了这些信息，并使用了参数n=10000、threads=100，其余的都是默认选项（cl=one、mode=native cql3 等）。 Cassandra 集群是一个 3 节点 CentOS VM 设置。

自定义yaml文件的一些细节如下：

insert:
    partitions: fixed(100)
    select: fixed(1)/2
    batchtype: UNLOGGED

columnspecs:
    -name: Time
     size: fixed(1000)
    -name: ID
     size: uniform(1..100)
    -name: Date
     size: uniform(1..10)
    -name: Value
     size: uniform(-100..100)

我目前的观察如下：

1. 使用n=10000 和时间：fixed(1000)，插入的行数为1000 万。 (10000*1000=10000000)
2. row-keys/partitions 的数量为10000(i.e n)，其中一次取 100 个分区（即 100 *1000 = 100000 个键值对），其中一次处理 50000 个键值对时间。 （这是因为select: fixed(1)/2 ~ 50%）

输出消息也证实了这一点：

生成具有 [100..100] 个分区和 [50000..50000] 行的批次（分区中的总行数为 [100000..100000] 个）

使用与上述相同的配置连续运行，我得到的结果如下：

Run Total_ops   Op_rate Partition_rate  Row_Rate   Time 
1     56           19     1885           943246     3.0
2     46           46     4648          2325498     1.0
3     27           30     2982          1489870     0.9
4     59           19     1932           966034     3.1
5     100          17     1730           865182     5.8

现在我需要了解的内容如下：

1. 这些指标中的哪一个是吞吐量，即每秒插入的记录数？是 Row_rate、Op_rate 还是 Partition_rate？如果是 Row_rate，我可以在这里安全地得出结论，我能够每秒插入近 100 万条记录吗？对这种情况下 Op_rate 和 Partition_rate 的含义有何想法？
2. 为什么每次运行时 Total_ops 变化如此之大？线程的数量与这种变化有关吗？关于我的 Cassandra 设置的稳定性，我可以在这里得出什么结论？
3. 如何在此处确定每个线程的批处理大小？在我的示例中，批量大小是 50000 吗？

提前致谢。

Answer 1

行率 是您已插入数据库的 CQL 行数。对于您的表，CQL 行是一个元组，例如 (ID uuid, Time timestamp, Value double, Date timestamp)。

分区率是 C* 必须构建的分区数。分区是在 Cassandra 中保存和排序数据的数据结构，具有相同分区键的数据最终位于同一节点上。此分区率等于在时间窗口中插入的分区键中唯一值的数量。对于您的表，这将是 (ID,Date)

的唯一值

Op Rate 是必须完成的实际 CQL 操作的数量。根据您的设置，它正在运行未记录的批次以插入数据。每个插入包含大约 100 个分区（ID 和日期的唯一组合），这就是为什么 OP Rate * 100 ~= Partition Rate

总 OP 应该包括所有操作，读取和写入。因此，如果您有任何读取操作，也会包括在内。

我建议更改批处理大小以匹配您的工作负载，或者根据您的实际数据库使用情况将其保持为 1。这应该提供一个更现实的场景。此外，运行时间要长得多，而不是仅仅运行 100 次总操作才能真正了解系统的功能，这一点也很重要。当数据集的大小超过机器中的 RAM 量时，一些最大的困难就出现了。