cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-799) memtable sort is the bottleneck for range query performance
Date Wed, 17 Feb 2010 18:30:27 GMT


Stu Hood commented on CASSANDRA-799:

It seems weird to me that a Memtable removes itself from the list of memtables in the CFS,
which is a symptom of some very tight coupling.

Shouldn't a CFS own a Memtable, give it a handle to an open SSTableWriter to flush itself,
close the writer when it is done, and remove the Memtable? The easiest way to accomplish this
would be to move flushAndSignal to CFS, and change writeSortedContents to a void on Flushable
that takes an open SSTableWriter. Then you could probably remove the Memtable reference to
the CFS entirely.

> memtable sort is the bottleneck for range query performance
> -----------------------------------------------------------
>                 Key: CASSANDRA-799
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.6
>         Attachments: 0001-refactor-IFlushable-contract-to-push-differences-b-t-M.txt,
0002-use-a-sorted-map-for-memtable-contents-to-make-range-q.txt, 0003-refactor-to-make-memtablesPendingFlush-a-member-variab.txt,
799-unbounded-flushwriter.txt, 799.txt
> The obvious remedy is to use a sorted map.  Unfortunately, keeping the map sorted constantly
w/ TreeMap was about 30% slower than HashMap + sort back when we were doing manual locking.
 Let's see what the overhead is for ConcurrentSkiplistMap vs NBHM.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message