cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2897) Secondary indexes without read-before-write
Date Tue, 28 Aug 2012 22:27:08 GMT


Jonathan Ellis updated CASSANDRA-2897:

    Attachment: 2897-apply-cleanup.txt

bq. I prefer Philip's method of pushing down the resolution of indexed values from Table.apply

Hmm, I disagree.  The problem is that Phil's method does a lot of extra allocation, even when
no indexed columns are updated.  (And even when we just need the size delta, we move from
a no-allocation long to a Pair.)

So I think we need to push the index management down into ACC.

Somewhat orthogonally, attached is a patch to clean out unnecessary code from the apply path;
we don't need obsolete indexed columns anymore, and deleting an indexed range doesn't need
special casing either.
> 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
>             Fix For: 1.2.0 beta 1
>         Attachments: 0001-CASSANDRA-2897-Secondary-indexes-without-read-before-w.txt,
0002-CASSANDRA-2897-Secondary-indexes-without-read-before-w.txt, 2897-apply-cleanup.txt, 41ec9fc-2897.txt
> 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
For more information on JIRA, see:

View raw message