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-6561) Static columns in CQL3
Date Fri, 14 Feb 2014 11:00:24 GMT

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

Sylvain Lebresne commented on CASSANDRA-6561:
---------------------------------------------

Pushed an additional commit at https://github.com/pcmanus/cassandra/commits/6561-4 (it's a
new branch because I rebased out of habit, but only the last commit is new) that address most
the remarks.

bq. "DELETE static_col FROM table WHERE partition_key = X and clustering_col = Y" should?
probably throw an error, and not delete the static_col? (not sure about this one)

Not sure either :). But it's definitively dodgy and we can always refuse it now and change
our mind later (while the contrary is harder) so rejecting it now.  It also rejects "UPDATE
table SET static_col=X WHERE partition_key=Y and clustering_col=Z" because that's really kind
of the same thing.

bq. I'd prefer BEGIN CAS BATCH, b/c currently you can use either BEGIN UNLOGGED BATCH or BEGIN
LOGGED BATCH with conditions, and it confuses things.

I have a small reluctance to that because that makes things slightly more annoying for clients
(you might have to special case code just to indicate the batch contains conditions where
really this is not necessary, you already know if you've put conditions or not, users are
adults). And I'm not really worried about UNLOGGED versus LOGGED being equivalent since that's
already the case for "normal" operations on the same partition anyway. Another detail is that
for batch in the native protocol, it would add a new type, and while arguably it doesn't require
a protocol bump per-se, but would still require client drivers to update and would provide
a bit more confusion for users as to which pair of client/server version support those batch
or not at the protocol level.

None of this is major and I don't feel extremely strongly either way, but I don't think forcing
users to explicitly label the batch really buys anything outside of some annoyance so I'd
rather not do it.

Note that I realise the same could be said for COUNTER batches but 1) I do think in hindsight
that requiring that label adds a minor annoyance without really buying us much and we could
have avoided it (don't get me wrong, it's absolutely minor and I'm not suggesting changing
it now) and 2) it's probably somewhat more justified for counters because those are really
segregated to their own tables.


> Static columns in CQL3
> ----------------------
>
>                 Key: CASSANDRA-6561
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6561
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0.6
>
>
> I'd like to suggest the following idea for adding "static" columns to CQL3.  I'll note
that the basic idea has been suggested by jhalliday on irc but the rest of the details are
mine and I should be blamed for anything stupid in what follows.
> Let me start with a rational: there is 2 main family of CF that have been historically
used in Thrift: static ones and dynamic ones. CQL3 handles both family through the presence
or not of clustering columns. There is however some cases where mixing both behavior has its
use. I like to think of those use cases as 3 broad category:
> # to denormalize small amounts of not-entirely-static data in otherwise static entities.
It's say "tags" for a product or "custom properties" in a user profile. This is why we've
added CQL3 collections. Importantly, this is the *only* use case for which collections are
meant (which doesn't diminishes their usefulness imo, and I wouldn't disagree that we've maybe
not communicated this too well).
> # to optimize fetching both a static entity and related dynamic ones. Say you have blog
posts, and each post has associated comments (chronologically ordered). *And* say that a very
common query is "fetch a post and its 50 last comments". In that case, it *might* be beneficial
to store a blog post (static entity) in the same underlying CF than it's comments for performance
reason.  So that "fetch a post and it's 50 last comments" is just one slice internally.
> # you want to CAS rows of a dynamic partition based on some partition condition. This
is the same use case than why CASSANDRA-5633 exists for.
> As said above, 1) is already covered by collections, but 2) and 3) are not (and
> I strongly believe collections are not the right fit, API wise, for those).
> Also, note that I don't want to underestimate the usefulness of 2). In most cases, using
a separate table for the blog posts and the comments is The Right Solution, and trying to
do 2) is premature optimisation. Yet, when used properly, that kind of optimisation can make
a difference, so I think having a relatively native solution for it in CQL3 could make sense.
> Regarding 3), though CASSANDRA-5633 would provide one solution for it, I have the feeling
that static columns actually are a more natural approach (in term of API). That's arguably
more of a personal opinion/feeling though.
> So long story short, CQL3 lacks a way to mix both some "static" and "dynamic" rows in
the same partition of the same CQL3 table, and I think such a tool could have it's use.
> The proposal is thus to allow "static" columns. Static columns would only make sense
in table with clustering columns (the "dynamic" ones). A static column value would be static
to the partition (all rows of the partition would share the value for such column). The syntax
would just be:
> {noformat}
> CREATE TABLE t (
>   k text,
>   s text static,
>   i int,
>   v text,
>   PRIMARY KEY (k, i)
> )
> {noformat}
> then you'd get:
> {noformat}
> INSERT INTO t(k, s, i, v) VALUES ("k0", "I'm shared",       0, "foo");
> INSERT INTO t(k, s, i, v) VALUES ("k0", "I'm still shared", 1, "bar");
> SELECT * FROM t;
>  k |                  s | i |    v
> ------------------------------------
> k0 | "I'm still shared" | 0 | "bar"
> k0 | "I'm still shared" | 1 | "foo"
> {noformat}
> There would be a few semantic details to decide on regarding deletions, ttl, etc. but
let's see if we agree it's a good idea first before ironing those out.
> One last point is the implementation. Though I do think this idea has merits, it's definitively
not useful enough to justify rewriting the storage engine for it. But I think we can support
this relatively easily (emphasis on "relatively" :)), which is probably the main reason why
I like the approach.
> Namely, internally, we can store static columns as cells whose clustering column values
are empty. So in terms of cells, the partition of my example would look like:
> {noformat}
> "k0" : [
>   (:"s" -> "I'm still shared"), // the static column
>   (0:"" -> "")                  // row marker
>   (0:"v" -> "bar")
>   (1:"" -> "")                  // row marker
>   (1:"v" -> "foo")
> ]
> {noformat}
> Of course, using empty values for the clustering columns doesn't quite work because it
could conflict with the user using empty clustering columns. But in the CompositeType encoding
we have the end-of-component byte that we could reuse by using a specific value (say 0xFF,
currently we never set that byte to anything else than -1, 0 and 1) to indicate it's a static
column.
> With that, we'd need to update the CQL3 statements to support the new syntax and rules,
but that's probably not horribly hard.
> So anyway, this may or may not be a good idea, but I think it has enough meat to warrant
some consideration.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message