cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Anastasyev (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-6446) Faster range tombstones on wide rows
Date Wed, 04 Dec 2013 11:15:35 GMT
Oleg Anastasyev created CASSANDRA-6446:

             Summary: Faster range tombstones on wide rows
                 Key: CASSANDRA-6446
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Oleg Anastasyev

Having wide CQL rows (~1M in single partition) and after deleting some of them, we found inefficiencies
in handling of range tombstones on both write and read paths.

I attached 2 patches here, one for write path (RangeTombstonesWriteOptimization.diff) and
another on read (RangeTombstonesReadOptimization.diff).

On write path, when you have some CQL rows deletions by primary key, each of deletion is represented
by range tombstone. On put of this tombstone to memtable the original code takes all columns
from memtable from partition and checks DeletionInfo.isDeleted by brute for loop to decide,
should this column stay in memtable or it was deleted by new tombstone. Needless to say, more
columns you have on partition the slower deletions you have heating your CPU with brute range
tombstones check. 
The RangeTombstonesWriteOptimization.diff patch for partitions with more than 10000 columns
loops by tombstones instead and checks existance of columns for each of them. Also it copies
of whole memtable range tombstone list only if there are changes to be made there (original
code copies range tombstone list on every write).

On read path, original code scans whole range tombstone list of a partition to match sstable
columns to their range tomstones. The RangeTombstonesReadOptimization.diff patch scans only
necessary range of tombstones, according to filter used for read.

This message was sent by Atlassian JIRA

View raw message