cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2897) Secondary indexes without read-before-write
Date Fri, 18 May 2012 18:57:14 GMT


Jonathan Ellis commented on CASSANDRA-2897:

bq. it generates both new, correct index entries, AND tombstones for old, invalid ones (the
column entries in the parent CF that get discarded during compaction

Actually, this doesn't work for us, since (unlike Bigtable) we don't make an effort to preserve
all older versions of a column on disk; we'll happily throw away old values that got overwritten
in the memtable without a trace.

It may be that the best we can do is an alternate index implementation that does the "purge
obsolete entries at read time" but makes no attempt to purge otherwise (which would make it
only suitable for insert-mostly datasets or read-mostly datasets).
> Secondary indexes without read-before-write
> -------------------------------------------
>                 Key: CASSANDRA-2897
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>              Labels: secondary_index
> Currently, secondary index updates require a read-before-write to maintain the index
consistency. Keeping the index consistent at all time is not necessary however. We could let
the (secondary) index get inconsistent on writes and repair those on reads. This would be
easy because on reads, we make sure to request the indexed columns anyway, so we can just
skip the row that are not needed and repair the index at the same time.
> This does trade work on writes for work on reads. However, read-before-write is sufficiently
costly that it will likely be a win overall.
> There is (at least) two small technical difficulties here though:
> # If we repair on read, this will be racy with writes, so we'll probably have to synchronize
> # We probably shouldn't only rely on read to repair and we should also have a task to
repair the index for things that are rarely read. It's unclear how to make that low impact

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message