[
https://issues.apache.org/jira/browse/CASSANDRA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444951#comment-13444951
]
Sam Tunnicliffe commented on CASSANDRA-2897:
--------------------------------------------
LGTM so far, except I have a failing test in SSTableReaderTest.
testPersistantStatisticsWithSecondaryIndex errors with the message:
{code}
12/08/30 14:18:00 ERROR sstable.SSTableReader: Cannot open
build/test/cassandra/data/Keyspace1/Indexed1/Keyspace1-Indexed1.626972746864617465-ia-2
because partitioner does not match org.apache.cassandra.dht.LocalPartitioner
!= org.apache.cassandra.dht.ByteOrderedPartitioner
{code}
Although it looks like that's failing in the same way against trunk (I'll
investigate)
bq. I note, for the record, that composite indexes make my head hurt
(CASSANDRA-4586).
Good, me too.
bq. I further note that finding the wrong column value being used to create
dummyColumn in the index-stale block was a bitch. Not sure how your new tests
passed with that. Two bugs cancelling out, I guess.
Hmm, odd cos that had me stumped for quite a while too, and the test was
definitely failing until I got dummyColumn figured out (or thought I had)
One insignificant nit - the Javadoc comment for PerRowSecondaryIndex.index has
a typo.
> 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
> Assignee: Sam Tunnicliffe
> 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,
> 0003-CASSANDRA-2897.txt, 2897-apply-cleanup.txt, 2897-v4.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 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
