[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055528#comment-14055528 ] Jonathan Ellis edited comment on CASSANDRA-7056 at 7/9/14 4:40 AM: --- bq. TL;DR - logged batches are playing a different role than RAMP transactions are supposed to, so one can't replace another. But RAMP transactions (with logged commit so we don't need to rely purely on read repair for coordinator failure mid-commit) give you a superset of logged batches. So I don't see a need to introduce new syntax for the former. was (Author: jbellis): bq. TL;DR - logged batches are playing a different role than RAMP transactions are supposed to, so one can't replace another. But RAMP transactions give you a superset of logged batches. So I don't see a need to introduce new syntax for the former. Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043367#comment-14043367 ] Tupshin Harper edited comment on CASSANDRA-7056 at 6/25/14 12:05 PM: - Cross table consistent reads are of fundamental importance. Once you allow that they are useful for consistent index reads, then you have admitted that they are useful for for direction consumption by users, since we are constantly advising them to build their own index solutions since 2i are horrendously weak. That pressure will be only slightly reduced with global indexes. Even separate from custom (client-side) 2i implementations, having all or nothing read visibility of writes spanning tables captures fundamental business logic that is either painfully worked around today, or else is glossed over as statistically unlikely (depending on the r/w patterns) and the race conditions duly ignored. It would be a tragic mistake to ignore the benefits of the gains in correctness that can be achieved. was (Author: tupshin): Cross table consistent reads are of fundamental importance. Once you allow that they are useful for consistent index reads, then you have admitted that they are useful for for direction consumption by users, since we are constantly advising them to build their own index solutions since 2i are horrendously weak. That pressure will be only slightly reduced with global indexes. Even separate from custom (client-side) 2i implementations, having all or nothing read visibility of writes spanning partitions/tables captures fundamental business logic that is either painfully worked around today, or else is glossed over as statistically unlikely (depending on the r/w patterns) and the race conditions duly ignored. It would be a tragic mistake to ignore the benefits of the gains in correctness that can be achieved. Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043367#comment-14043367 ] Tupshin Harper edited comment on CASSANDRA-7056 at 6/25/14 12:25 PM: - Cross table consistent reads are of fundamental importance. Once you allow that they are useful for consistent index reads, then you have admitted that they are useful for for direct consumption by users, since we are constantly advising them to build their own index solutions since 2i are horrendously weak. That pressure will be only slightly reduced with global indexes. Even separate from custom (client-side) 2i implementations, having all or nothing read visibility of writes spanning tables captures fundamental business logic that is either painfully worked around today, or else is glossed over as statistically unlikely (depending on the r/w patterns) and the race conditions duly ignored. It would be a tragic mistake to ignore the benefits of the gains in correctness that can be achieved. was (Author: tupshin): Cross table consistent reads are of fundamental importance. Once you allow that they are useful for consistent index reads, then you have admitted that they are useful for for direction consumption by users, since we are constantly advising them to build their own index solutions since 2i are horrendously weak. That pressure will be only slightly reduced with global indexes. Even separate from custom (client-side) 2i implementations, having all or nothing read visibility of writes spanning tables captures fundamental business logic that is either painfully worked around today, or else is glossed over as statistically unlikely (depending on the r/w patterns) and the race conditions duly ignored. It would be a tragic mistake to ignore the benefits of the gains in correctness that can be achieved. Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043771#comment-14043771 ] Peter Bailis edited comment on CASSANDRA-7056 at 6/25/14 5:16 PM: -- RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed--as you point out--never match, but simply returning matching timestamps is *not* not the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) was (Author: pbailis): RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed---as you point out---never match, but simply returning matching timestamps is *not* not the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043771#comment-14043771 ] Peter Bailis edited comment on CASSANDRA-7056 at 6/25/14 5:18 PM: -- RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) not match, but simply returning matching timestamps is *not* the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) was (Author: pbailis): RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) never match, but simply returning matching timestamps is *not* the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043771#comment-14043771 ] Peter Bailis edited comment on CASSANDRA-7056 at 6/25/14 5:16 PM: -- RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) never match, but simply returning matching timestamps is *not* the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) was (Author: pbailis): RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) never match, but simply returning matching timestamps is *not* not the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043771#comment-14043771 ] Peter Bailis edited comment on CASSANDRA-7056 at 6/25/14 5:16 PM: -- RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) never match, but simply returning matching timestamps is *not* not the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) was (Author: pbailis): RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed--as you point out--never match, but simply returning matching timestamps is *not* not the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7056) Add RAMP transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043771#comment-14043771 ] Peter Bailis edited comment on CASSANDRA-7056 at 6/25/14 5:19 PM: -- RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) not match, but simply returning matching timestamps is *not* the goal: the goal is that if you read any write in a given batch, you will be able to read the rest of the writes in the batch (i.e., if you also attempt to read any other items that were written in the batch, you will see the corresponding writes). was (Author: pbailis): RAMP has a requirement that anything being read/written that way is always written in the same groupings. If you update B,C and then update A,B. You can't read B,C anymore successfully, as the times on B and C will never match. This isn't entirely correct. Let's say I do an atomic batch B1 that writes B = 1 and C = 1 with timestamp 1, then you do an atomic batch B2 that writes A = 2 and B = 2 at timestamp 2. Under RAMP, subsequent batch reads from B and C will return B = 2, C = 1. The timestamps on B and C will indeed (as you point out) not match, but simply returning matching timestamps is *not* the goal: the goal is that if you read any write in a given batch, you will read the rest of the writes in the batch (to the items you requested in the batch read) Add RAMP transactions - Key: CASSANDRA-7056 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056 Project: Cassandra Issue Type: Wish Components: Core Reporter: Tupshin Harper Priority: Minor We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/] transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like) operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
