cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua McKenzie (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8546) RangeTombstoneList becoming bottleneck on tombstone heavy tasks
Date Thu, 08 Jan 2015 20:30:35 GMT


Joshua McKenzie commented on CASSANDRA-8546:

Regarding GapList - as recently as 10-28-2014, [there was a bug fix involving invalid data|!topic/brownies-collections/su1zrxYGbMc];
I wouldn't consider this implementation production-ready on the scale we have to work with
on Cassandra.  While the concept behind the collection looks reasonably simple / elegant,
given the relative obscurity of the brownies-collection it's a part of I'd expect the number
of code-bases it's running in to be far fewer than any of the other collections we're using
in our code-base.  I agree with Sylvain - the concept behind it is sound and it looks like
it's coming along well, I'm just not convinced it's appropriate for inclusion in our code-base
at its current level of maturity, much less in a stable 2.1 release.

> RangeTombstoneList becoming bottleneck on tombstone heavy tasks
> ---------------------------------------------------------------
>                 Key: CASSANDRA-8546
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: 2.0.11 / 2.1
>            Reporter: Dominic Letz
>            Assignee: Joshua McKenzie
>             Fix For: 2.1.3
>         Attachments: cassandra-2.0.11-8546.txt, cassandra-2.1-8546.txt, rangetombstonelist_compaction.png,
rangetombstonelist_mutation.png, rangetombstonelist_read.png, tombstone_test.tgz
> I would like to propose a change of the data structure used in the RangeTombstoneList
to store and insert tombstone ranges to something with at least O(log N) insert in the middle
and at near O(1) and start AND end. Here is why:
> When having tombstone heavy work-loads the current implementation of RangeTombstoneList
becomes a bottleneck with slice queries.
> Scanning the number of tombstones up to the default maximum (100k) can take up to 3 minutes
of how addInternal() scales on insertion of middle and start elements.
> The attached test shows that with 50k deletes from both sides of a range.
> INSERT 1...110000
> flush()
> DELETE 1...50000
> DELETE 110000...60000
> While one direction performs ok (~400ms on my notebook):
> {code}
> SELECT * FROM timeseries WHERE name = 'a' ORDER BY timestamp DESC LIMIT 1
> {code}
> The other direction underperforms (~7seconds on my notebook)
> {code}
> SELECT * FROM timeseries WHERE name = 'a' ORDER BY timestamp ASC LIMIT 1
> {code}

This message was sent by Atlassian JIRA

View raw message