为什么Cassandra的超级专栏不再受青睐?

时间:2012-08-11 13:51:44

标签: cassandra indexing database-indexes super-columns

我在最新版本中已经读到,由于“性能问题”,超级列不可取,但没有解释的地方。

然后我读了诸如this one之类的文章,这些文章使用超级列提供了精彩的索引模式。

这让我不知道目前什么是在Cassandra中进行索引编制的最佳方式。

  1. 超级列的性能问题是什么?
  2. 我在哪里可以找到当前索引编制的最佳做法?

1 个答案:

答案 0 :(得分:33)

超级列存在许多问题,其中最重要的是Cassandra在查询时需要对超级列的所有子列进行反序列化(即使结果只返回一个小子集)。因此,在性能受损之前,每个超级列的子列数存在实际限制。

理论上,这可以通过适当地索引子列在Cassandra中修复,但是共识是复合列是更好的解决方案,并且它们的工作没有增加的复杂性。

使用复合列的最简单方法是利用CQL 3提供的抽象。请考虑以下架构:

CREATE TABLE messages(
    username text,
    sent_at timestamp,
    message text,
    sender text,
    PRIMARY KEY(username, sent_at)
);

这里的用户名是行键,但是我们使用了PRIMARY KEY定义,它创建了一个行键和sent_at列的分组。这很重要,因为它具有索引该属性的效果。

INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:42:15', 'Hi', 'alice');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('alice', '2012-08-01 11:42:37', 'Hi yourself', 'bob');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:43:00', 'What are you doing later?', 'alice');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:47:14', 'Bob?', 'alice');

在幕后,Cassandra将存储上面插入的数据:

alice: (2012-08-01 11:42:37,message): Hi yourself, (2012-08-01 11:42:37,sender): bob
bob:   (2012-08-01 11:42:15,message): Hi,          (2012-08-01 11:42:15,sender): alice, (2012-08-01 11:43:00,message): What are you doing later?, (2012-08-01 11:43:00,sender): alice (2012-08-01 11:47:14,message): Bob?, (2012-08-01 11:47:14,sender): alice

但是使用CQL 3,我们可以使用sent_at谓词查询“行”,并返回表格结果集。

SELECT * FROM messages WHERE username = 'bob' AND sent_at > '2012-08-01';
 username | sent_at                  | message                   | sender
----------+--------------------------+---------------------------+--------
      bob | 2012-08-01 11:43:00+0000 | What are you doing later? |  alice
      bob | 2012-08-01 11:47:14+0000 |                      Bob? |  alice