cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ethan W (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6271) Replace SnapTree in AtomicSortedColumns
Date Tue, 10 Jan 2017 19:36:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815952#comment-15815952
] 

Ethan W commented on CASSANDRA-6271:
------------------------------------

Hi [~benedict]
yes I mean in Cassandra.

This is my understanding so far: inside PartitionKey index inside each SSTable, there is a
skip linked list for maintaining the row position. On the node of each linked list node, a
pointer point to the root of this snap tree for look up the each column cell's position. I
assume on the each snap tree node, there holds a physical address value which can directly
find the data cell that corresponding to that column for that row.

Is this correct?

Thanks!

> Replace SnapTree in AtomicSortedColumns
> ---------------------------------------
>
>                 Key: CASSANDRA-6271
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6271
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>              Labels: performance
>             Fix For: 2.1 beta1
>
>         Attachments: 0001-Always-call-ReplaceFunction.txt, oprate.svg, tmp.patch, tmp2.patch,
tmp3.patch
>
>
> 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
(v6.3.4#6332)

Mime
View raw message