我在最新版本中读到,由于“性能问题”,超级列是不可取的,但没有在哪里解释。
然后我阅读了这篇文章,这些文章使用超级列提供了出色的索引模式。
这让我不知道目前在 Cassandra 中进行索引的最佳方法是什么。
- 超级列的性能问题是什么?
- 在哪里可以找到当前的索引最佳实践?
我在最新版本中读到,由于“性能问题”,超级列是不可取的,但没有在哪里解释。
然后我阅读了这篇文章,这些文章使用超级列提供了出色的索引模式。
这让我不知道目前在 Cassandra 中进行索引的最佳方法是什么。
超级列存在许多问题,其中最重要的是 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