Les données de Cassandra dans un nœud se développent rapidement

Question

J'ai migré des enregistrements de l'ancienne famille de colonnes vers une nouvelle famille de colonnes. dans testKeyspace.

CREATE KEYSPACE testkeyspace WITH replication = { 
    'class': 'NetworkTopologyStrategy', 
    'DC1': '2', 
    'DC2': '2' 
}; 

Ancienne structure de famille de colonnes.

CREATE TABLE old_Columnfamily (
    scopeid bigint, 
    formid bigint, 
    time timestamp, 
    ipaddress text, 
    record_link_id bigint, 
    user_ifuid bigint, 
    value text, 
    PRIMARY KEY ((scopeid, formid), time) 
) WITH CLUSTERING ORDER BY (time DESC); 
CREATE INDEX update_audit_id_idx ON old_Columnfamily (record_link_id); 

CREATE INDEX update_audit_user_ifuid_idx ON old_Columnfamily (user_ifuid); 

Nouvelle Columnfamily Structure

CREATE TABLE new_Columnfamily (
    scopeid bigint, 
    formid bigint, 
    time timeuuid, 
    ipaddress inet, 
    operation int, 
    record_id bigint, 
    value text, 
    ifuid bigint, 
PRIMARY KEY ((scopeid), formid, time) 
) WITH CLUSTERING ORDER BY (formid ASC, time DESC) 

CREATE INDEX audit_operation_idx ON new_Columnfamily (operation); 
CREATE INDEX audit_recordid_idx ON new_Columnfamily (record_id); 
CREATE INDEX audit_zuid_idx ON new_Columnfamily (ifuid); 

Le résultat d'état de nodetool est

Datacenter: DC1 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address    Load  Tokens Owns Host ID        Rack 
UN 172.xxx.xxx.x80 5.58 GB 256  15.5% fda5181f-baf6-4c2d-9bf9-ecc4abc50c39 RAC1 
UN 172.xxx.xxx.x29 6.63 GB 256  16.4% 12574f5e-538a-4386-8c34-c8603a7456be RAC1 
UN 172.xxx.xxx.x22 40.64 GB 256  17.2% db390d80-161f-44fb-a9d8-536ea924533d RAC1 
Datacenter: DC2 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address    Load  Tokens Owns Host ID        Rack 
UN 172.xxx.xxx.x20 4.65 GB 256  17.9% fda5181f-baf6-4c2d-9bf9-ecc4abc50c39 RAC1 
UN 172.xxx.xxx.x67 6.37 GB 256  16.7% 12574f5e-538a-4386-8c34-c8603a7456be RAC1 
UN 172.xxx.xxx.x23 6.93 GB 256  16.2% db390d80-161f-44fb-a9d8-536ea924533d RAC1 

Edit: nodetool -h 172.xxx.xxx.x23 tpstats

s = -ea -javaagent:./../lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms8G -Xmx8G -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss256k 
Pool Name     Active Pending  Completed Blocked All time blocked 
ReadStage       0   0  24426641   0     0 
RequestResponseStage    0   0  48496365   0     0 
MutationStage      0   0  15623599   0     0 
ReadRepairStage     0   0  2562071   0     0 
ReplicateOnWriteStage    0   0    0   0     0 
GossipStage      0   0  3268659   0     0 
AntiEntropyStage     0   0    0   0     0 
MigrationStage     0   0    32   0     0 
MemoryMeter      0   0   371   0     0 
MemtablePostFlusher    0   0   32263   0     0 
FlushWriter      0   0   18447   0    1080 
MiscStage       0   0    0   0     0 
PendingRangeCalculator   0   0    8   0     0 
commitlog_archiver    0   0    0   0     0 
InternalResponseStage    0   0    12   0     0 
HintedHandoff      2   2   1194   0     0 

Message type   Dropped 
RANGE_SLICE     0 
READ_REPAIR     0 
PAGED_RANGE     0 
BINARY      0 
READ       0 
MUTATION      0 
_TRACE      0 
REQUEST_RESPONSE    0 

Pr oblem Is: lors de la migration des données de l'ancien vers le nouveau noeud de la colonne 172.xxx.xxx.x23 a chuté. J'ai arrêté la migration et redémarré le noeud, puis j'ai commencé la migration. J'ai remarqué des données dans le noeud 172.xxx.xxx.x23 en croissance rapide.

pourquoi cela est-il arrivé? s'il vous plaît expliquer la raison. Merci d'avance.

Answer 1

Je remarque qu'il y a une différence dans la clé de partition entre old ((scopeid, formid), time) et new schema ((scopeid), formid, time). Puisque vous réduisez l'unicité de la clé de partition à une colonne, la clé de partition calculée peut avoir un impact sur le stockage des données sur les nœuds. Si vous avez le même scopeid à partir de milliers d'enregistrements, tous iront sur le même nœud, car la clé de partition pour tous ces enregistrements sera la même.