Cassandra 不是按主键排序
Cassandra sort not by primary key
我正在尝试在 Cassandra 中建模 table,我是新手,偶然发现了一个问题。我有以下内容:
CREATE TABLE content_registry (
service text,
file text,
type_id tinyint,
container text,
status_id tinyint,
source_location text,
expiry_date timestamp,
modify_date timestamp,
create_date timestamp,
to_overwrite boolean,
PRIMARY KEY ((service), file, type_id)
);
据我了解:
service
是我的分区键,基于此值将生成哈希值并将值拆分为集群
file
是集群键
type_id
是集群键
- 这三个主体组合成一个复合(复合)主键
我发现每当我插入新数据时,Cassandra 都会更新插入(如果具有该复合主键的值存在,则插入或更新)
现在我正在努力的是,我希望我的数据返回时按 create_date
降序排序,但是 create_date
不是主键的一部分。
如果我将 create_date
添加到我的主键,我将无法插入数据,因为 create_date
表示插入记录时的时间戳,所以如果我将它添加到主键有插入的时候,我会得到多条记录。
还有哪些选择?在应用程序中订购?这似乎不是很有效。
If I add create_date to my primary key, I won't be able to upsert data.
为什么不呢?假设您的密钥是 PRIMAY KEY (service, create_date, file, type_id)
?这将使您可以按 create_date
对每个服务 但不是全局排序。
如果您想在全球范围内执行此操作(也就是说,您希望所有服务和所有文件按创建日期排序),那么如果您仍然希望能够对数据进行分片,事情可能会更加复杂。一种选择是制作主键 PRIMARY KEY (create_date, service, file, type_id)
并使用 order preserving partitioners.
之一
此外,这里还有更多信息:http://www.datastax.com/dev/blog/we-shall-have-order
What I've figured out is that whenever I'll insert new data, Cassandra
will upsert (either insert or update if the value with that compound
primary key exists)
完全正确。
Now what I'm struggling is, that I want my data to come back sorted by
create_date in descending order, however create_date is not part of
primary key.
If I add create_date to my primary key, I won't be able to upsert
data, because create_date means timestamp when record was inserted, so
if I add it to primary key every time there's an insert, I'll end up
with multiple records.
你这句话其实是自相矛盾的。
如果 create_date
不是您的密钥的一部分,而是 属性 并且数据被更新,这意味着记录始终相同。因此,当按键查询并获取 create_date
时,您总是拥有最新的。如果你真的想要记录 created 的日期,你应该在第一次插入该记录后不再覆盖数据。
如果您想要表示一系列数据,您确实需要避免更新插入,这可以通过使用 create_date
作为附加分区键来完成。我宁愿使用 time_uuid
,它具有非常方便的功能。
最后但同样重要的是,最有趣的问题是,您真正想要反映的用例是什么。在 cassandra 中建模数据时,您总是应该提前 运行 知道您需要的查询。
Cassandra 中的关键概念是您必须决定什么是您的 PRIMARY KEY
,即您的行中的内容可以是 唯一 和 已知 在查询时。这是一个非常基本的要求,因为未能认识到这一点将导致错误的模型。
据我所知,您将 service
标识为您的分区键,因此我认为此字段就是 "rules" 您的数据。这是你 必须 真正知道的东西,即使是执行单个查询(忽略低效的 table 扫描 SELECT * FROM content_registry;
)。在每个 service
中,您当前的行按 file
排序,然后按 type_id
排序。我不知道后一个字段的确切含义,但您目前可以有两行由 ('service1', 'a.jpg', 1)
和 ('service1', 'a.jpg', 2)
标识。因此,如果 type_id
与 file
有某种关联,则该模型有点不正确。
现在,假设您要以另一个顺序为每个 service
获取相同的记录,您真正需要做的是创建另一个 table,其中将包含 create_date
作为第一个聚类列,例如 (service, create_date, file, type_id)
。这将允许您获取按创建日期排序的记录,当两个记录在同一日期创建时,它们将进一步按 file
排序,然后按 type_id
排序。
第二种方法是将二级索引附加到原始 table 的 create_date
字段。这将允许按创建日期查询。
第三种方法(可能比第二种方法更好)是使用实体化视图。它将为您隐藏很多负担,并且可能比二级索引具有更好的扩展性。
请注意,二级索引或物化视图通常无法很好地扩展。检查这些方法是否足以满足您的用例。
我正在尝试在 Cassandra 中建模 table,我是新手,偶然发现了一个问题。我有以下内容:
CREATE TABLE content_registry (
service text,
file text,
type_id tinyint,
container text,
status_id tinyint,
source_location text,
expiry_date timestamp,
modify_date timestamp,
create_date timestamp,
to_overwrite boolean,
PRIMARY KEY ((service), file, type_id)
);
据我了解:
service
是我的分区键,基于此值将生成哈希值并将值拆分为集群file
是集群键type_id
是集群键- 这三个主体组合成一个复合(复合)主键
我发现每当我插入新数据时,Cassandra 都会更新插入(如果具有该复合主键的值存在,则插入或更新)
现在我正在努力的是,我希望我的数据返回时按 create_date
降序排序,但是 create_date
不是主键的一部分。
如果我将 create_date
添加到我的主键,我将无法插入数据,因为 create_date
表示插入记录时的时间戳,所以如果我将它添加到主键有插入的时候,我会得到多条记录。
还有哪些选择?在应用程序中订购?这似乎不是很有效。
If I add create_date to my primary key, I won't be able to upsert data.
为什么不呢?假设您的密钥是 PRIMAY KEY (service, create_date, file, type_id)
?这将使您可以按 create_date
对每个服务 但不是全局排序。
如果您想在全球范围内执行此操作(也就是说,您希望所有服务和所有文件按创建日期排序),那么如果您仍然希望能够对数据进行分片,事情可能会更加复杂。一种选择是制作主键 PRIMARY KEY (create_date, service, file, type_id)
并使用 order preserving partitioners.
此外,这里还有更多信息:http://www.datastax.com/dev/blog/we-shall-have-order
What I've figured out is that whenever I'll insert new data, Cassandra will upsert (either insert or update if the value with that compound primary key exists)
完全正确。
Now what I'm struggling is, that I want my data to come back sorted by create_date in descending order, however create_date is not part of primary key. If I add create_date to my primary key, I won't be able to upsert data, because create_date means timestamp when record was inserted, so if I add it to primary key every time there's an insert, I'll end up with multiple records.
你这句话其实是自相矛盾的。
如果 create_date
不是您的密钥的一部分,而是 属性 并且数据被更新,这意味着记录始终相同。因此,当按键查询并获取 create_date
时,您总是拥有最新的。如果你真的想要记录 created 的日期,你应该在第一次插入该记录后不再覆盖数据。
如果您想要表示一系列数据,您确实需要避免更新插入,这可以通过使用 create_date
作为附加分区键来完成。我宁愿使用 time_uuid
,它具有非常方便的功能。
最后但同样重要的是,最有趣的问题是,您真正想要反映的用例是什么。在 cassandra 中建模数据时,您总是应该提前 运行 知道您需要的查询。
Cassandra 中的关键概念是您必须决定什么是您的 PRIMARY KEY
,即您的行中的内容可以是 唯一 和 已知 在查询时。这是一个非常基本的要求,因为未能认识到这一点将导致错误的模型。
据我所知,您将 service
标识为您的分区键,因此我认为此字段就是 "rules" 您的数据。这是你 必须 真正知道的东西,即使是执行单个查询(忽略低效的 table 扫描 SELECT * FROM content_registry;
)。在每个 service
中,您当前的行按 file
排序,然后按 type_id
排序。我不知道后一个字段的确切含义,但您目前可以有两行由 ('service1', 'a.jpg', 1)
和 ('service1', 'a.jpg', 2)
标识。因此,如果 type_id
与 file
有某种关联,则该模型有点不正确。
现在,假设您要以另一个顺序为每个 service
获取相同的记录,您真正需要做的是创建另一个 table,其中将包含 create_date
作为第一个聚类列,例如 (service, create_date, file, type_id)
。这将允许您获取按创建日期排序的记录,当两个记录在同一日期创建时,它们将进一步按 file
排序,然后按 type_id
排序。
第二种方法是将二级索引附加到原始 table 的 create_date
字段。这将允许按创建日期查询。
第三种方法(可能比第二种方法更好)是使用实体化视图。它将为您隐藏很多负担,并且可能比二级索引具有更好的扩展性。
请注意,二级索引或物化视图通常无法很好地扩展。检查这些方法是否足以满足您的用例。