2

Nous avons le tableau ci-dessous avec ttl 24 heures ou 1 jour. Nous avons 4 cassandra 3.0 node cluster et il y aura un traitement spark sur cette table. Une fois traité, il tronquera toutes les données dans les tables et un nouveau lot de données sera inséré. Ce sera un processus continu.problème avec troncs fréquents dans Cassandra et 24 heures ttl créer de grandes pierres tombales

Problème Je vois est, nous obtenons plus tombstones parce que les données sont tronquées fréquemment tous les jours après spark finit le traitement.

Si je définis gc_grace_seconds par défaut, il y aura plus tombstones. Si je réduis gc_grace_seconds à 1 jour ce sera un problème? même si je fais des réparations sur cette table tous les jours cela suffira.

Comment dois-je aborder ce problème, je sais que les suppressions fréquentes sont un anti-modèle dans Cassandra, existe-t-il un autre moyen de résoudre ce problème?

TABLE b.stag (
    xxxid bigint PRIMARY KEY, 
    xxxx smallint, 
    xx smallint, 
    xxr int, 
    xxx text, 
    xxx smallint, 
    exxxxx smallint, 
    xxxxxx tinyint, 
    xxxx text, 
    xxxx int, 
    xxxx text, 
xxxxx text, 
    xxxxx timestamp 
) WITH bloom_filter_fp_chance = 0.01 
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} 
    AND comment = '' 
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCom                      pactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} 
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandr                      a.io.compress.LZ4Compressor'} 
    AND crc_check_chance = 1.0 
    AND dclocal_read_repair_chance = 0.1 
    AND default_time_to_live = 86400 
    AND gc_grace_seconds = 864000 
    AND max_index_interval = 2048 
    AND memtable_flush_period_in_ms = 0 
    AND min_index_interval = 128 
    AND read_repair_chance = 0.0 
    AND speculative_retry = '99PERCENTILE'; 

merci

Répondre

0

Une troncature d'une table ne doit pas invoquer des pierres tombales. Donc quand vous dites "tronquer" je suppose que vous voulez dire supprimer. Vous pouvez, comme vous l'avez déjà mentionné, supprimer la valeur gc_grace_seconds, mais cela signifie que vous avez une fenêtre plus petite pour les réparations à exécuter pour réconcilier les données, assurez-vous que chaque noeud a la pierre tombale droite pour une clé donnée, etc. ou les anciennes données peuvent réapparaître. C'est un compromis. Cependant, pour être honnête si vous débarrassez la table à chaque fois, pourquoi ne pas utiliser la commande TRUNCATE, de cette façon vous viderez la table sans pierres tombales.

+0

L'opération Truncate doit être utilisée avec le niveau de cohérence ALL ou Quorum? Lequel est bon, selon sa documentation ALL ALL ALL échouera si un noeud de réplication est arrêté, mais je veux que mon opération tronquée réussisse de toute façon. être question d'utiliser quorum pour l'opération tronquée. –

+0

Vous n'avez pas besoin d'utiliser un niveau de cohérence avec truncate, il ne suit pas le chemin d'écriture normal comme une opération DDL, donc se propage à tous les nœuds via potins – markc

+0

J'ai utilisé truncate table, fait un nœud avant d'exécuter le tronqué commande à partir du cluster 4 nœuds (un nœud vers le bas) et une erreur indiquant TruncateError: