[
https://issues.apache.org/jira/browse/CASSANDRA-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288413#comment-13288413
]
Christoph Tavan commented on CASSANDRA-4176:
--------------------------------------------
I think the suggestion to discuss sharding and composite row keys/values in a
different issue is good.
If we wanna have event more specific/dedicated support for sharding, a
different syntax idea for (borrowed from
[MySQL|http://dev.mysql.com/doc/refman/5.1/en/create-table.html]) might be:
{code}
CREATE TABLE timeline (
user_id varchar,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id, tweet_id)
) PARTITION BY HASH(user_id, DAY(tweet_id)) PARTITIONS 10;
{code}
It would read very straightforward IMO, but maybe that's already too
high-level?
> 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.2
>
>
> 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
