[
https://issues.apache.org/jira/browse/CASSANDRA-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815952#comment-15815952
]
Ethan W edited comment on CASSANDRA-6271 at 1/10/17 7:43 PM:
-------------------------------------------------------------
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 (crc) which can directly find the data cell that
corresponding to that column for that row.
Is this correct?
Thanks!
was (Author: aertoria):
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)
