cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4176) Support for sharding wide rows in CQL 3.0
Date Fri, 20 Apr 2012 05:17:36 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Nick Bailey updated CASSANDRA-4176:
-----------------------------------

    Description: 
CQL 3.0 currently has support for defining wide rows by declaring a composite primary key.
For example:

{noformat}
CREATE TABLE timeline (
    user_id varchar,
    tweet_id uuid,
    author varchar,
    body varchar,
    PRIMARY KEY (user_id, tweet_id)
);
{noformat}

It would also be useful to manage sharding a wide row through the cql schema. This would require
being able to split up the actual row key in the schema definition. In the above example you
might want to make the row key a combination of user_id and day_of_tweet, in order to shard
timelines by day. This might look something like:

{noformat}
CREATE TABLE timeline (
    user_id varchar,
    day_of_tweet date,
    tweet_id uuid,
    author varchar,
    body varchar,
    PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}

Thats probably a terrible attempt at how to structure that in CQL. But I think I've gotten
the point across. I tagged this for cql 3.0, but I'm honestly not sure how much work it might
be. As far as I know built in support for composite keys is limited.

  was:
CQL 3.0 currently has support for defining wide rows by declaring a composite primary key.
For example:

{noformat}
CREATE TABLE timeline (
    user_id varchar,
    tweet_id uuid,
    author varchar,
    body varchar,
    PRIMARY KEY (user_id, tweet_id)
);
{noformat}

It would also be useful to manage sharding a wide row through the cql schema. This would require
being able to split up the actual row key in the schema definition. In the above example you
might want to make the row key a combination of user_id and day_of_tweet, on order to shard
timelines by day. This might look something like:

{noformat}
CREATE TABLE timeline (
    user_id varchar,
    day_of_tweet date,
    tweet_id uuid,
    author varchar,
    body varchar,
    PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}

Thats probably a terrible attempt at how to structure that in CQL. But I think I've gotten
the point across. I tagged this for cql 3.0, but I'm honestly not sure how much work it might
be. As far as I know built in support for composite keys is limited.

    
> Support for sharding wide rows in CQL 3.0
> -----------------------------------------
>
>                 Key: CASSANDRA-4176
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4176
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>            Reporter: Nick Bailey
>             Fix For: 1.1.1
>
>
> CQL 3.0 currently has support for defining wide rows by declaring a composite primary
key. For example:
> {noformat}
> CREATE TABLE timeline (
>     user_id varchar,
>     tweet_id uuid,
>     author varchar,
>     body varchar,
>     PRIMARY KEY (user_id, tweet_id)
> );
> {noformat}
> It would also be useful to manage sharding a wide row through the cql schema. This would
require being able to split up the actual row key in the schema definition. In the above example
you might want to make the row key a combination of user_id and day_of_tweet, in order to
shard timelines by day. This might look something like:
> {noformat}
> CREATE TABLE timeline (
>     user_id varchar,
>     day_of_tweet date,
>     tweet_id uuid,
>     author varchar,
>     body varchar,
>     PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
> );
> {noformat}
> Thats probably a terrible attempt at how to structure that in CQL. But I think I've gotten
the point across. I tagged this for cql 3.0, but I'm honestly not sure how much work it might
be. As far as I know built in support for composite keys is limited.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message