cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8649) CAS per (partition key + clustering key) and not only per (partition key)
Date Wed, 21 Jan 2015 11:41:35 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285530#comment-14285530
] 

Sylvain Lebresne commented on CASSANDRA-8649:
---------------------------------------------

I agree with the general sentiment but let me argument a bit. This is theoretically possible
but the issues I have with it in practice are that:
# this would add some complexity internally to a code that is already hairy.
# it's unclear to me how to expose such feature in a way that is intuitive and not error prone
for users. Typically, this kind of would need to be a table option but doing so would make
it super easy for users to think that they have serializability at the partition level when
they don't. I don't think this is a minor issue btw.
# This doesn't play terribly well with serializable reads. That is, the only serializable
reads we'd be able to allow with this would be those that exactly select one row: we'd have
to refuse any type of slice query (with CL.SERIAL). It's of course possible, but the resulting
API would be a bit weird/unintuitive imo.
# while the current CAS implementation is pretty inefficient in presence of contention, we're
already investigating improving it (CASSANDRA-6246). If this pan out, it could very well be
that it'll be performant enough to support the use case described here (my memory is probably
rusty but I believe EPaxos has a notion of conflicting updates that could take individual
rows into account, so that 2 updates on the same partition but not the same rows would not
contend).
# as noted, this is work-aroundable, for instance by using a separate table to store what
should be CAS'ed. Yes it's not as simple but it's not too hard either.

Overall, I'm in favor of at least resolving as 'Later' and wait on CASSANDRA-6246. Chances
are, it will be performant enough without requiring a new user visible (and somewhat specific)
concept.


> CAS per (partition key + clustering key) and not only per (partition key)
> -------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8649
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8649
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Dobrin
>             Fix For: 3.0
>
>
> Reading the description at http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0
:
> ...
> * The columns updated do NOT have to be the same as the columns in the IF clause.
> * Lightweight transactions are restricted to a single partition; this is the granularity
at which we keep the internal Paxos state. As a corollary, transactions in different partitions
will never interrupt each other.
> ...
> So my understanding of the above is that if multiple writers for example perform CAS
inserts (INSERT...IF NOT EXISTS) using the same partition key and different clustering keys
will interrupt/interfere with each other?
> Is this understanding correct? (my tests seems to confirm it)
> For example if I want to model users from different country/city/area and I want to be
able to list all the users from a given country ordered by (city,area) and also I know that
a single cassandra node will be able to store all the users from a given country but I need
to partition users from different countries because a single cassandra node will not be enough:
> CREATE COLUMNFAMILY user (
> 	country text,
> 	city text,
> 	area text,
> 	id text,
> 	json text,
> 	version bigint,
> 	PRIMARY KEY ((country), city, area, id)
> );
> Where id is the user id and json is a JSON serialized user object (an aggregate) containing
more information about the user. 
> I want to be able to CAS insert many users into the same country concurrently using
> 	INSERT INTO user(country, city, area, id, json, version) VALUES ('x',...) IF NOT EXISTS;
> 	
> and be able to CAS update users from the same country concurrently:
> 	UPDATE user SET json='{...}',version=18 WHERE country='x' AND city='y' AND area='z'
AND id='123' IF version=17;
> 	
> As I understand this will not be efficient because all the above concurrent statements
will have to be "ordered" by the same paxos instance/state per country 'x'? (and trying it
results in a lot of WriteTimeoutException-s)
> If yes - can we made paxos to support IF statements per column/cell?
> By cell/column I mean all the underlying persistent state that is behind the compound
primary key (partition key + clustering key) - in the above example
> 	the state is json and version
> 	the partition key is the country
> 	and the clustering key is (city, area, id)
> (	
> I'm stating it explicitly as I'm not completely sure whether this is a single cell or
double cells underneath at the storage engine, references used:
> http://www.datastax.com/dev/blog/cql3-for-cassandra-experts
> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
> )
> In other words is it possible to make CAS per (partition key + clustering key) and not
only per (partition key)?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message