Question

我们有一个表在运行“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

Answer 1

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

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

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

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

所以我猜想避免嵌套收集！

停止nodetool修复的Cassandra表＆amp;出口很慢

1 个答案: