cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6271) Replace SnapTree in AtomicSortedColumns
Date Wed, 30 Oct 2013 15:57:25 GMT


Benedict commented on CASSANDRA-6271:

bq.  Doesn't this fail miserably for large partitions?

For more than a few thousand columns we could fall back to the current implementation for
now, or use an in-memory b-tree (or simply a perfectly allocated cache-friendly N-ary tree,
since we're doing CoW). In the long run using an n-ary tree that has N large enough to rarely
need larger than a depth of 1 seems a suitable solution, but I would prefer to see if there
is any performance improvement first.

The only downside would be updates to few columns that contain large payloads, but are in
a row with a very large number of columns. In this case it will be slower than the current
approach, but not noticeably wrt the total cost of the operation.

> Replace SnapTree in AtomicSortedColumns
> ---------------------------------------
>                 Key: CASSANDRA-6271
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>              Labels: performance
> On the write path a huge percentage of time is spent in GC (>50% in my tests, if accounting
for slow down due to parallel marking). SnapTrees are both GC unfriendly due to their structure
and also very expensive to keep around - each column name in AtomicSortedColumns uses >
100 bytes on average (excluding the actual ByteBuffer).
> I suggest using a sorted array; changes are supplied at-once, as opposed to one at a
time, and if < 10% of the keys in the array change (and data equal to < 10% of the size
of the key array) we simply overlay a new array of changes only over the top. Otherwise we
rewrite the array. This method should ensure much less GC overhead, and also save approximately
80% of the current memory overhead.
> TreeMap is similarly difficult object for the GC, and a related task might be to remove
it where not strictly necessary, even though we don't keep them hanging around for long. TreeMapBackedSortedColumns,
for instance, seems to be used in a lot of places where we could simply sort the columns.

This message was sent by Atlassian JIRA

View raw message