cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6812) Iterative Memtable->SSTable Replacement
Date Sun, 05 Feb 2017 16:37:41 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-6812:
-----------------------------------------
    Fix Version/s:     (was: 3.x)
                   4.x

> Iterative Memtable->SSTable Replacement
> ---------------------------------------
>
>                 Key: CASSANDRA-6812
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6812
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>              Labels: performance
>             Fix For: 4.x
>
>
> In an ideal world we wouldn't flush any memtable until we were almost completely out
of room. The problem with this approach (and in fact whenever we currently *do* run out of
room) is that flushing an entire memtable is a slow process, and so write latencies spike
dramatically during this interval.
> The solution to this is, in principle, quite straight forward: As we write chunks of
the new sstable and its index, open them up immediately for reading, and free the memory associated
with the portion of the file that has been written so that it can be reused immediately for
writing. This way whilst latency will increase for the duration of the flush, the max latency
experienced during this time should be no greater than the time taken to flush a few chunks,
which should still be on the order of milliseconds, not seconds.
> This depends on CASSANDRA-6689 and CASSANDRA-6694, so that we can reclaim arbitrary portions
of the allocated memory prior to a complete flush.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message