[
https://issues.apache.org/jira/browse/CASSANDRA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246789#comment-13246789
]
Jonathan Ellis commented on CASSANDRA-2897:
-------------------------------------------
To summarize, I think an implementation of this would look something like this:
# Get rid of the synchronized oldIndexColumns code in Table.apply; on write,
all we need to do is add an index entry for the newly-written value
# Index read code (ColumnFamilyStore.getIndexedIterator) will need to
double-check the rows returned by the index to make sure the column value still
matches the indexed one; if it does not, delete the index entry so we don't
keep making the same mistake
# (The hard part, as described in the immediately previous comment) Change
AbstractCompactionRow write implementations to delete old index entries as
well; that is, we create index tombstones for each column value that is NOT the
one retained after the compaction merge. Specifically, PrecompactedRow::merge
and LazilyCompactedRow::Reducer.
# Existing index tests (in ColumnFamilyStoreTest::testIndexDeletions and
::testIndexUpdate) are fine for parts 1-2, but we should add a new test for 3
to make sure that index-update-on-compaction works as advertised
> Secondary indexes without read-before-write
> -------------------------------------------
>
> Key: CASSANDRA-2897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2897
> 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 there.
> # 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 though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
