cassandra主键列不能被限制 [英] cassandra primary key column cannot be restricted

查看:1565
本文介绍了cassandra主键列不能被限制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在网络应用程序中第一次使用Cassandra,我遇到了一个查询问题。
这是我的标签:

  CREATE TABLE vote(
doodle_id uuid,
user_id uuid ,
schedule_id uuid,
vote int,
PRIMARY KEY((doodle_id),user_id,schedule_id)
);

在每个请求中,我指示我的分区键,
例如我可以没有任何问题:

  select * from vote where doodle_id = c4778a27-f2ca-4c96- 8669-15dcbd5d34a7和user_id = 97a7378a-e1bb-4586-ada1-177016405142; 

但在最后一次请求时:

  select * from vote where doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 and schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633; 

我收到以下错误:

 错误的请求:PRIMARY KEY列schedule_id不能被限制(前面的列user_id不受限制或非EQ关系)

我是Cassandra的新用户,但是如果我错了,在复合主键中纠正我,第一部分是PARTITION KEY以允许Cassandra知道在哪里查找数据。
然后其他部分是CLUSTERING KEY来排序数据。



但是我还是不知道为什么我的第一个请求是工作,而不是第二个?

解决方案

如果任何人都能帮助您,在Cassandra中,您应该设计数据模型以适合您的查询。因此,正确的方式支持您的第二个查询( doodle_id schedule_id 的查询, c> user_id ),是创建一个新表来处理该特定查询。除了PRIMARY KEY会略有不同之外,这个表将大体相同:

  CREATE TABLE votebydoodleandschedule doodle_id uuid,
user_id uuid,
schedule_id uuid,
vote int,
PRIMARY KEY((doodle_id),schedule_id,user_id)
);

现在,此查询将起作用:

  SELECT * FROM votebydoodleandschedule 
WHERE doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7
AND schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633;

这样就可以指定 ALLOW FILTERING 。依靠 ALLOW FILTERING 从来不是一个好主意,并且肯定不是你应该在生产集群中做的事情。


I am using Cassandra for the first time in a web app and I got a query problem. Here is my tab :

CREATE TABLE vote (
    doodle_id uuid,
    user_id uuid,
    schedule_id uuid,
    vote int,
    PRIMARY KEY ((doodle_id), user_id, schedule_id)
);

On every request, I indicate my partition key, doodle_id. For example I can make without any problems :

select * from vote where doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 and user_id = 97a7378a-e1bb-4586-ada1-177016405142;

But on the last request I made :

select * from vote where doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 and schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633;

I got the following error :

Bad Request: PRIMARY KEY column "schedule_id" cannot be restricted (preceding column "user_id" is either not restricted or by a non-EQ relation)

I'm new with Cassandra, but correct me if I'm wrong, in a composite primary key, the first part is the PARTITION KEY which is mandatory to allow Cassandra to know where to look for data. Then the others parts are CLUSTERING KEY to sort data.

But I still don't get why my first request is working and not the second one ?

If anyone could help it will be a great pleasure.

解决方案

In Cassandra, you should design your data model to suit your queries. Therefore the proper way to support your second query (queries by doodle_id and schedule_id, but not necessarilly with user_id), is to create a new table to handle that specific query. This table will be pretty much the same, except the PRIMARY KEY will be slightly different:

CREATE TABLE votebydoodleandschedule (
    doodle_id uuid,
    user_id uuid,
    schedule_id uuid,
    vote int,
    PRIMARY KEY ((doodle_id), schedule_id, user_id)
);

Now this query will work:

SELECT * FROM votebydoodleandschedule 
WHERE doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 
AND schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633;

This gets you around having to specify ALLOW FILTERING. Relying on ALLOW FILTERING is never a good idea, and is certainly not something that you should do in a production cluster.

这篇关于cassandra主键列不能被限制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆