Cassandra: choosing a Partition Key

前端 未结 3 508
离开以前
离开以前 2020-12-08 00:42

I\'m undecided whether it\'s better, performance-wise, to use a very commonly shared column value (like Country) as partition key for a compound primary key or

3条回答
  •  囚心锁ツ
    2020-12-08 01:33

    if you use cql3, given a column family:

    CREATE TABLE table1 (
      a1 text,
      a2 text,
      b1 text,
      b2 text,
      c1 text,
      c2 text,
      PRIMARY KEY ( (a1, a2), b1, b2) )
    );
    

    by defining a primary key ( (a1, a2, ...), b1, b2, ... )

    This implies that:

    a1, a2, ... are fields used to craft a row key in order to:

    • determine how the data is partitioned
    • determine what is phisically stored in a single row
    • referred as row key or partition key

    b1, b2, ... are column family fields used to cluster a row key in order to:

    • create logical sets inside a single row
    • allow more flexible search schemes such as range range
    • referred as column key or cluster key

    All the remaining fields are effectively multiplexed / duplicated for every possible combination of column keys. Here below an example about composite keys with partition keys and clustering keys work.

    If you want to use range queries, you can use secondary indexes or (starting from cql3) you can declare those fields as clustering keys. In terms of speed having them as clustering key will create a single wide row. This has impact on speed since you will fetch multiple clustering key values such as:

    select * from accounts where Country>'Italy' and Country<'Spain'

提交回复
热议问题