Cassandra-Tabelle, die Nodetool Repair & Export stoppt langsam

Question

Wir haben eine Tabelle, die Timeouts Lesen/Schreiben des Clusters beim Ausführen von "nodetool repair" und Export (COPY FROM) -Funktionen sind sehr langsam (~ 150 Zeilen/Minute) mit viel GC-Fehler im Protokoll während des Exports.

Scheint, dass dies ein Problem mit dem Schema ist, da sich andere Tabellen mit ähnlichen Datenmengen (~ 1,5 Millionen Zeilen) normal verhalten.

Gibt es ein offensichtliches Problem mit diesem Schema?

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) 

Die beiden UDTs verwendet:

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

und

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

Also, was mache ich falsch?

Der Cluster läuft [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

OK, also nach vielen Tests fand ich, dass das Problem vielleicht zweifach ist:

1) Beim Exportieren eine Tabelle mit einem Textfeld, das JSON enthält Der COPY TO-Job verlangsamt sich erheblich. Ich beweise dies, dass ich die Tabelle mit 50000 Datensätzen mit einem JSON-Feld bevölkerte und dann die gleiche Tabelle mit Datensätzen, in denen der Text nur Zeichen wiederholt wurde, die die gleiche Länge wie der JSON hatten. COPY TO läuft bei ~ 800/s für das erstere und ~ 3000/s für das letztere. Ich denke, das hat etwas damit zu tun, wie die COPY TO der Ausgabe in der CSV entkommen muss - obwohl das Ändern des Trennzeichens nicht zu helfen schien.

2) Scheint die Verschachtelung der Sammlungen (hier unter Verwendung der UDTs aber auch ohne sie geschieht) Probleme mit dem Reparaturauftrag verursacht. Ich habe dies bewiesen, indem ich die Verschachtelung entfernt habe und stattdessen ein Textfeld verwendet habe, das den JSON enthält (die Zuordnung zu den Typen wird dann in der Anwendung gehandhabt). Das Reparieren dieser Tabelle erfolgt jetzt fast unmittelbar nach dem ersten Durchlauf (4 Minuten beim ersten Durchlauf, um 1,5 Millionen Zeilen zu machen und dann 1 Sekunde danach).

In Bezug auf Nesting, versuchte gefrorene >>> schien in Ordnung, versucht, gefrorene >>>>> resultierte in Sub-100/s Export-Zeiten.

So Vermeidungsverschachtelung Sammlung denke ich!