[ https://issues.apache.org/jira/browse/CASSANDRA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067244#comment-13067244 ]
T Jake Luciani commented on CASSANDRA-2897: ------------------------------------------- Sylvain, this seems problematic since clients often use indexes to identify rows to read, like: select * from cf1 where state='TX' If the index isn't upto date and index clauses are the primary way of pulling rows then this data will never be repaired. > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira