cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7282) Faster Memtable map
Date Sat, 13 Sep 2014 03:42:34 GMT

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

Benedict commented on CASSANDRA-7282:
-------------------------------------

No. You benchmark to isolate performance improvements. These numbers demonstrate a benefit
_to any portion of a workload that fits these characteristics_. Different use cases will exhibit
different ratios of this effect; some considerable, some not so much. Certainly the read performance
enhancements will be more generally applicable, but being able to fill your memtables faster
and with less garbage is also not a bad thing, even if you end up bottlenecking on disk. Especially
since server characteristics are changing rapidly, so that disk bottlenecks are disappearing.

As optimisation work goes deeper, isolating the specific portion of work that is affected
is pretty essential to clearly delineating the benefit.

> 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
>
>         Attachments: reads.svg, writes.svg
>
>
> 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.3.4#6332)

Mime
View raw message