[
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104307#comment-14104307
]
Ryan McGuire commented on CASSANDRA-7282:
-----------------------------------------
Here's a trial that incorporates some of the above suggestions:
http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.7282.default_mct.json
* 48M 32 byte rows.
* commitlog_total_space_in_mb: 16384
* memtable_allocation_type: offheap_objects
I'm not familiar with the settings that "heap memtable capacity to 4Gb, your
offheap to 2Gb" refers to.
I tried adding a memtable_cleanup_threshold of 0.99 but the write failed on
both runs when it started GC, so I'll try scaling that back some more (the
above results are just using the default instead.)
> Faster Memtable map
> -------------------
>
> Key: CASSANDRA-7282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Labels: performance
> Fix For: 3.0
>
>
> Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in
> our memtables. Maintaining this is an O(lg(n)) operation; since the vast
> majority of users use a hash partitioner, it occurs to me we could maintain a
> hybrid ordered list / hash map. The list would impose the normal order on the
> collection, but a hash index would live alongside as part of the same data
> structure, simply mapping into the list and permitting O(1) lookups and
> inserts.
> I've chosen to implement this initial version as a linked-list node per item,
> but we can optimise this in future by storing fatter nodes that permit a
> cache-line's worth of hashes to be checked at once, further reducing the
> constant factor costs for lookups.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
