cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Drew Kutcharian (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-7850) Composite Aware Partitioner
Date Fri, 29 Aug 2014 23:51:52 GMT
Drew Kutcharian created CASSANDRA-7850:
------------------------------------------

             Summary: Composite Aware Partitioner
                 Key: CASSANDRA-7850
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Drew Kutcharian


Since C* supports composites for partition keys, I think it'd be useful to have the ability
to only use first (or first few) components of the key to calculate the token hash.

A naive use case would be multi-tenancy:

Say we have accounts and accounts have users. So we would have the following tables:

{code}
CREATE TABLE account (
  id                     timeuuid PRIMARY KEY,
  company         text
);
{code}

{code}
CREATE TABLE user (
  id              timeuuid PRIMARY KEY, 
  accountId timeuuid,
  email        text,
  password text
);
{code}

{code}
// Get users by account
CREATE TABLE user_account_index (
  accountId  timeuuid,
  userId        timeuuid,
  PRIMARY KEY(acid, id)
);
{code}

Say we want to get all the users that belong to an account. We would first have to get the
results from user_account_index and then use a multi-get (WHERE IN) to get the records from
user table. Now this multi-get part could potentially query a lot of different nodes in the
cluster. It’d be great if there was a way to limit storage of users of an account to a single
node so that way multi-get would only need to query a single node.

With this improvement we would be able to define the user table like so:
{code}
CREATE TABLE user (
  id              timeuuid, 
  accountId timeuuid,
  email        text,
  password text,
  PRIMARY KEY(((accountId),id))  //extra parentheses
);
{code}

I'm not too sure about the notation, it could be something like PRIMARY KEY(((accountId),id))
where the "(accountId)" means use this part to calculate the hash and ((accountId),id) is
the actual partition key.

The main complication I see with this is that we would have to use the table definition when
calculating hashes so we know what components of the partition keys need to be used for hash
calculation.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message