停止 nodetool 修复和导出的 Cassandra 表很慢答案

【问题标题】：Cassandra table that stops nodetool repair & export is slow停止 nodetool 修复和导出的 Cassandra 表很慢
【发布时间】：2017-07-20 19:05:26
【问题描述】：

我们有一个表导致在运行“nodetool repair”时读取/写入集群超时，并且导出 (COPY FROM) 功能非常慢（~150 行/分钟），在导出期间日志中有很多 GC 错误。

似乎这可能是架构的问题，因为具有相似数据量（约 150 万行）的其他表表现正常。

这个架构有什么明显的问题吗？

CREATE TABLE reportingtest.events (
    year int,
    month int,
    day int,
    hour int,
    action text,
    id uuid,
    attributes frozen<list<frozen<attribute>>>,
    domain text,
    organisation text,
    status text,
    PRIMARY KEY ((year, month), day, hour, action, id)
) WITH CLUSTERING ORDER BY (day ASC, hour ASC, action ASC, id ASC)

使用的两个 UDT 是：

CREATE TYPE reportingtest.attribute (
    namespace text,
    name text,
    displayname text,
    values frozen<list<frozen<attributevalue>>>
);

和

CREATE TYPE reportingtest.attributevalue (
    aggregationvalue text,
    extra frozen<map<text, text>>
);

那我做错了什么？

集群正在运行[cqlsh 5.0.1 | Cassandra 3.0.9 | CQL spec 3.4.0 | Native protocol v4].

Percentile   Partition Size   Cell Count
50%          25109160         61214
75%          30130992         61214
95%          89970660         182785
98%          129557750        379022
99%          268650950        654949
Min          373              18
Max          464228842        113175

【问题讨论】：

使用tracing on 运行一些查询并检查生成了多少墓碑
感谢您的建议。此表上没有删除，也没有任何更新，所以我不确定墓碑是问题所在。尝试几个查询我每次都得到Read 1000 live and 0 tombstone cells。
docs.datastax.com/en/cassandra/3.0/cassandra/tools/… - 您还应该检查您的分区是否“太大”
谢谢。嗯。我在想一个 200mb 的分区和最大 500mb 的分区可能“太大”了吗？（我在某处读到 100mb 是最佳的）。看来我需要更改分区键？
Percentile Partition Size Cell Count 50% 25109160 61214 75% 30130992 61214 95% 89970660 182785 98% 129557750 379022 99% 268650950 654949 Min 373 18 Max 464228842 113175 抱歉 - 不知道如何在评论中格式化。

标签： cassandra cassandra-3.0

【解决方案1】：

好的，经过大量测试后，我发现问题可能有两个方面：

1) 导出带有包含 JSON 的文本字段的表时，COPY TO 作业会显着减慢。我证明了这一点，我用 50000 条记录和 JSON 字段填充了表，然后在同一个表中填充了文本只是重复字符的记录，其长度与 JSON 相同。 COPY TO 前者以 ~800/s 运行，后者以 ~3000/s 运行。我认为这与 COPY TO 必须转义 CSV 中的输出的方式有关 - 尽管更改分隔符似乎没有帮助。

2) 似乎集合的嵌套（这里使用 UDT，但没有它们也会发生）导致修复工作出现问题。我通过删除嵌套并使用包含 JSON 的文本字段来证明这一点（然后在应用程序中处理类型的映射）。现在修复此表几乎在第一次运行后立即进行（第一次运行 4 分钟以执行 150 万行，然后在此之后 1 秒）。

关于嵌套，尝试冻结>>> 似乎没问题，尝试冻结>>>>> 导致导出时间低于 100/s。

所以我想避免嵌套集合！

【讨论】：