最近在Cassandra的使用過程中, 發(fā)現(xiàn)Cassandra的查詢操作異常緩慢(花費了700~900ms), 經(jīng)過排查后發(fā)現(xiàn)是使用了Secondary Index的原因.本文整理了primary key 和 Secondary Index在Cassandra中的存儲方式, 也解釋了為什么使用Secondary Index查詢會非常緩慢.

Primary Key

Cassandra的Primary Key由Partition Key和Clustering Key兩部分組成. 先看只有Partition Key的情況.
例如, 如下建表語句:

CREATE TABLE sample (
  id text,
  name text,
  PRIMARY KEY (id)
);

該表的primary key就是其partition key. 在Cassandra中, 每一個partition key對應(yīng)著一行, 所有的column都存儲在該行中.如下圖所示:

        +-------------+----------+-----------+------------+
        |  partition  |  column  |  column   |   column   |
        |    key 1    |    1     |     2     |      3     |
        +-------------+----------+-----------+------------+
        |  partition  |  column  |  column   |   column   |
        |    key 2    |    1     |     2     |      3     |
        +-------------+----------+-----------+------------+

例如, 在sample中插入若干記錄, 查詢該表:

SELECT * FROM sample;

得到如下結(jié)果:

 id  | name
-----+-------
 id3 | name3
 id1 | name1
 id2 | name2

然后, 再用Cassandra-Cli去查詢, 得到如下結(jié)果:

    RowKey: id3
    => (name=, value=, timestamp=1442491586006000)
    => (name=name, value=6e616d6533, timestamp=1442491586006000)
    -------------------
    RowKey: id1
    => (name=, value=, timestamp=1442491594600000)
    => (name=name, value=6e616d6531, timestamp=1442491594600000)
    -------------------
    RowKey: id2
    => (name=, value=, timestamp=1442491578108000)
    => (name=name, value=6e616d6532, timestamp=1442491578108000)

    3 Rows Returned.
    

可以看到, 每一個partition key對應(yīng)著一個RowKey, 所有的column都存放在這一行上.

Clustering Key

Cassandra中所有的數(shù)據(jù)都只能根據(jù)Primary Key中的字段來排序, 因此, 如果想根據(jù)某個column來排序, 必須將改column加到Primary key中, 如 primary key (id, c1, c2 ,c3), 其中id時partition key, c1, c2 ,c3是Clustering Key.(如果想用id和c1作為partition key, 只需添加括號: primary key ((id, c1), c2 ,c3)).

創(chuàng)建表:

CREATE TABLE sample3 (
  id text,
  gmt_create bigint,
  name text,
  score text,
  PRIMARY KEY ((id), gmt_create)
);

在該表中插入若干紀(jì)錄后, 使用select *查詢該表, 得到如下紀(jì)錄:

id  | gmt_create | name  | score
-----+------------+-------+--------
 id3 |       1925 | name3 | score3
 id3 |       1926 | name4 | score4
 id1 |       1923 | name1 | score1
 id2 |       1924 | name2 | score2

可以看到cql表中有四條記錄, 其中id=id3有兩條記錄, 那么是否意味著cassandra中有四行來保存這些記錄呢?用Cssandra-Cli來查詢:

    RowKey: id3
    => (name=1925:, value=, timestamp=1442494070376000)
    => (name=1925:name, value=6e616d6533, timestamp=1442494070376000)
    => (name=1925:score, value=73636f726533, timestamp=1442494070376000)
    => (name=1926:, value=, timestamp=1442494335821000)
    => (name=1926:name, value=6e616d6534, timestamp=1442494335821000)
    => (name=1926:score, value=73636f726534, timestamp=1442494335821000)
    -------------------
    RowKey: id1
    => (name=1923:, value=, timestamp=1442494039343000)
    => (name=1923:name, value=6e616d6531, timestamp=1442494039343000)
    => (name=1923:score, value=73636f726531, timestamp=1442494039343000)
    -------------------
    RowKey: id2
    => (name=1924:, value=, timestamp=1442494054817000)
    => (name=1924:name, value=6e616d6532, timestamp=1442494054817000)
    => (name=1924:score, value=73636f726532, timestamp=1442494054817000)

    3 Rows Returned.
    

可以看到, cassandra中只用3行來保存數(shù)據(jù), 其中id=id3到兩條記錄被保存在同一行上. 事實上, 當(dāng)存在clustering key時, 當(dāng)partition key相同而clustering key不同時, 其紀(jì)錄是保存在同一行上的, 而每一個column的name責(zé)由clustering的值 + ":" + 原來的column name構(gòu)成(如sample3中, column score的name = 1923:score), sample3在cassandra中的存儲結(jié)構(gòu)如下圖所示:

        +-------------+----------------+-------------------+----------------------+
        |             |  name = 1925:  |  name=1925:name   |    name=1925:score   |
        |             |  value =       |  value=6e616d6533 |  value=73636f726533  |
        |             |  timestamp     |     timestamp     |       timestamp      |
        |    id 3     +----------------+-------------------+----------------------+
        |             |  name = 1926:  |  name=1926:name   |    name=1926:score   |
        |             |  value=        |  value=6e616d6534 |  value=73636f726534  |
        |             |  timestamp     |     timestamp     |       timestamp      |
        +-------------+----------------+-------------------+----------------------+
        |             |  name = 1923:  |  name=1923:name   |    name=1923:score   |
        |    id 1     |  value =       |  value=6e616d6531 |  value=73636f726531  |
        |             |  timestamp     |     timestamp     |       timestamp      |
        +-------------+----------------+-------------------+----------------------+
        |             |  name = 1924:  |  name=1924:name   |    name=1924:score   |
        |    id 2     |  value =       |  value=6e616d6532 |  value=73636f726532  |
        |             |  timestamp     |     timestamp     |       timestamp      |
        +-------------+----------------+-------------------+----------------------+

Secondary Index

從cassandra 0.7開始支持Secondary Index. 例如, 在sample3上創(chuàng)建Secondary Index:

create index idx_score on sample3(score);

而Secondary Index的原理類似于創(chuàng)建一張新的表, 該表的primary key就是索引的列.因此, 若原sample表中有數(shù)據(jù):

{
    "id1": {
        "name" : "jim"
        "score": "60"
    },
    "id2": {
        "name" : "kate"
        "score": "60"
    }
}

索引表的內(nèi)部結(jié)構(gòu)類似于如下：

{
    "60": {
        "id1": data
        "id2": data
    }
}

與原表的不同之處在于: 原表的數(shù)據(jù)按照partition key分發(fā)到不同的節(jié)點進(jìn)行存儲, 當(dāng)cassandra進(jìn)行讀取時, 任意一個節(jié)點返回數(shù)據(jù)即可(取決于讀取時的一致性要求), 而secondary index 表則會存儲自己節(jié)點上的數(shù)據(jù), 因此, 按照secondary index進(jìn)行讀取時, 需要等待每一個節(jié)點讀取完畢, 這個過程相比于primary key讀取的過程會比較緩慢.(當(dāng)并發(fā)非常高時, 就會造成大量的random I/O, 導(dǎo)致查詢非常緩慢.)

因此, 當(dāng)secondary index的column是類似于'國家'這樣有許多重復(fù)紀(jì)錄的字段時, 讀取時相當(dāng)高效的(因為n個節(jié)點都進(jìn)行一個磁盤搜素, 時間復(fù)雜度O(n), 然而查詢到的紀(jì)錄數(shù)有可能是x條, 大多數(shù)情況下x>n, 平均下來時非常高效的), 但是當(dāng)secondary index的column是類似于email這樣幾乎每個人唯一的字段時, 是非常低效的, 因為按照email進(jìn)行查詢是, 每一次查詢幾乎只能命中一條紀(jì)錄, 而secondary index搜索的時間復(fù)雜度則是O(n)。