使用 cassandra-stress 导入时，ScyllaDB 模式会导致问题答案

【问题标题】：ScyllaDB schema causes issues when imported with cassandra-stress使用 cassandra-stress 导入时，ScyllaDB 模式会导致问题
【发布时间】：2020-02-18 13:57:42
【问题描述】：

我目前在我的环境中使用 ScyllaDB，并且由于技术原因，正在研究迁移到 Cassandra。我正在尝试使用可能与 ScyllaDB 中当前使用的模式相同的模式使用数据使 cassandra-stress 加载 Cassandra 集群。遗憾的是，存在一些问题。

环境：

ScyllaDB 3.0.7 (= Cassandra 3.0.8) 在 Ubuntu 18.04 上运行
Cassandra 3.11.4 在 Ubuntu 18.04 上运行
cassandra-stress 3.0.18（cassandra-tools pkg 的一部分）在 Ubuntu 18.04 上运行

流程如下：

从 ScyllaDB (desc keyspace_name) 转储模式
准备 cassandra-stress yaml 文件 - 一个键空间，总共五个表
运行 cassandra-stress (cassandra-stress user profile=schema.yml cl=QUORUM duration=30s 'ops(insert=1)' -node 172.19.11.9 -rate threads=1)

为了确保没有与键空间相关的问题，每次运行 cassandra-stress 都在一个新的键空间上完成（我正在增加名称）。

现在，当架构是 1:1 作为从 Scylla 转储的架构时，定义两个表（并且只有这两个）会导致压力工具失败：com.datastax.driver.core.exceptions.SyntaxError: line 1:35 no viable alternative at input 'WHERE' (UPDATE "activities_bp_action" SET [WHERE]...)。

表定义如下：

table: activities_bp
table_definition: |
  CREATE TABLE activities_bp  (
    business_profile_id int,
    create_date timestamp,
    event_uuid uuid,
    PRIMARY KEY (business_profile_id, create_date, event_uuid)
  ) WITH CLUSTERING ORDER BY (create_date DESC, event_uuid ASC)
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.DeflateCompressor'}

table: activities_bp_action
table_definition: |
  CREATE TABLE activities_bp_action  (
    business_profile_id int,
    action text,
    create_date timestamp,
    event_uuid uuid,
    PRIMARY KEY ((business_profile_id, action), create_date, event_uuid)
  ) WITH CLUSTERING ORDER BY (create_date DESC, event_uuid ASC)
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.DeflateCompressor'}

如果将包含 PRIMARY KEY 和 CLUSTERING ORDER 的两行替换为以下内容，则 cassandra-stress 运行良好且没有错误，并开始用数据填充集群。但是，现在的定义与 ScyllaDB 的定义有所不同：

    PRIMARY KEY (event_uuid, create_date)
  ) WITH CLUSTERING ORDER BY (create_date DESC)

现在，在使用修改后的定义运行 cassandra-stress 之后，我可以回滚到未修改的定义（曾经失败的那个）。如果在已经存在的键空间上运行，yaml 现在可以正常工作并用数据填充集群。这表明问题是在创建表时出现的？

在调试模式下运行 cassandra-stress 和 Cassandra 时，我无法找到 cassandra-stress 在其堆栈跟踪中显示的完整查询，并且该查询让我有点困惑。

任何想法为什么会出现问题？谢谢！

编辑：

附加schema.yml:https://gist.github.com/schybbkoh/76cdbf19a2bb933419063526ff5ac44f

编辑：

事实证明，“运行良好，没有错误，并开始用数据填充集群”模式创建并仅填充模式中定义的最后一个表。这里出了点问题。

【问题讨论】：

您的插入查询是什么样的？您可以在要点中分享整个配置吗？也可能想考虑 LZ4Compressor 压缩器（尽管我怀疑它在压力下会很明显）。
完整的schema.yml 也不会受到伤害
完整的schema.yml 已附加到原始帖子。 entire config 是什么意思，Cassandra 的？
是什么问题促使您回到 C*？
一般来说，所有与非正常工作操作相关的事情。 IE。当一个节点解除分配（当您在云上时发生）时，集群修复实际上需要数周时间。就我的问题联系了 Scylla 的人，但我听到的主要是“我们知道这一点，将来会解决这个问题”。无论如何，我认为在这个线程中，我们应该专注于让 cassandra-stress 发挥作用。

标签： cassandra scylla cassandra-stress

【解决方案1】：

好的，问题解决了。有两个问题：

cassandra-stress 3.0.18 与 Cassandra 3.11.4 使用不同的 CQL 规范（发生冲突）
cassandra-stress 3.x 不支持在一个 YML 中定义多个表（参见 https://issues.apache.org/jira/browse/CASSANDRA-8780）

【讨论】：