Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 87CFDD966 for ; Thu, 30 Aug 2012 14:00:17 +0000 (UTC) Received: (qmail 27439 invoked by uid 500); 30 Aug 2012 14:00:17 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 27393 invoked by uid 500); 30 Aug 2012 14:00:17 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 27277 invoked by uid 99); 30 Aug 2012 14:00:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 14:00:17 +0000 Date: Fri, 31 Aug 2012 01:00:17 +1100 (NCT) From: "Jonathan Ellis (JIRA)" To: commits@cassandra.apache.org Message-ID: <1479852907.16562.1346335217076.JavaMail.jiratomcat@arcas> In-Reply-To: <1268533255.10562.1310579221440.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Comment Edited] (CASSANDRA-2897) Secondary indexes without read-before-write MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444965#comment-13444965 ] Jonathan Ellis edited comment on CASSANDRA-2897 at 8/31/12 12:59 AM: --------------------------------------------------------------------- bq. the test was definitely failing until I got dummyColumn figured out FTR, the problem was {{IColumn dummyColumn = new Column(liveColumn.name(), column.value(), column.timestamp());}} Here, {{column}} is the column from the index row, so column.value is always empty. To actually delete the old index entry we need to use the column value that was indexed: {{IColumn dummyColumn = new Column(baseColumnName, indexedValue, column.timestamp());}} There was a corresponding bug for the non-composite case as well. (Edit: liveColumn.name() == baseColumnName, just thought the latter was a bit more clear.) was (Author: jbellis): bq. the test was definitely failing until I got dummyColumn figured out FTR, the problem was {{IColumn dummyColumn = new Column(liveColumn.name(), column.value(), column.timestamp());}} Here, {{column}} is the column from the index row, so column.value is always empty. To actually delete the old index entry we need to use the column value that was indexed: {{IColumn dummyColumn = new Column(baseColumnName, indexedValue, column.timestamp());}} There was a corresponding bug for the non-composite case as well. > 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