停止节点工具修复和导出的Cassandra表很慢



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

好的,所以经过大量测试,我发现问题可能是双重的:

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

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

关于嵌套,尝试冷冻似乎还可以>>>尝试冷冻>>>>>导致导出时间低于 100/s。

所以我想避免嵌套收集!

最新更新