cassandra - español - mongodb

La columna de clave primaria de Cassandra no puede ser restringida

Question

Estoy usando Cassandra por primera vez en una aplicación web y tengo un problema de consulta. Aquí está mi pestaña:

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

En cada solicitud, indico mi clave de partición, doodle_id. Por ejemplo puedo hacer sin ningún problema:

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

Pero en la última petición que hice:

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

Tuve el siguiente 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)

Soy nuevo con Cassandra, pero corríjame si me equivoco, en una clave primaria compuesta, la primera parte es la CLAVE DE PARTICIÓN, que es obligatoria para permitir a Cassandra saber dónde buscar datos. Luego, las otras partes son CLUSTERING KEY para ordenar los datos.

¿Pero todavía no entiendo por qué mi primera solicitud está funcionando y no la segunda?

Si alguien pudiera ayudar sería un gran placer.

Answer 1

En Cassandra, debe diseñar su modelo de datos para satisfacer sus consultas. Por lo tanto, la forma adecuada de admitir su segunda consulta (consultas por doodle_id y schedule_id , pero no necesariamente con user_id ), es crear una nueva tabla para manejar esa consulta específica. Esta tabla será bastante parecida, excepto que la CLAVE PRIMARIA será ligeramente diferente:

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

Ahora esta consulta funcionará:

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

Esto te lleva a tener que especificar ALLOW FILTERING . Confiar en ALLOW FILTERING nunca es una buena idea, y ciertamente no es algo que deba hacer en un clúster de producción.

Answer 2

La clave de agrupamiento también se usa para encontrar las columnas dentro de una partición dada. Con tu modelo, podrás consultar por:

• doodle_id
• doodle_id / user_id
• doodle_id / user_id / schedule_id
• user_id utilizando ALLOW FILTERING
• user_id / schedule_id usando ALLOW FILTERING

Puede ver su clave principal como una ruta de archivo doodle_id # 123 / user_id # 456 / schedule_id # 789 donde todos los datos se almacenan en la carpeta más profunda (es decir, schedule_id # 789). Cuando realiza una consulta, debe indicar la subcarpeta / subárbol desde donde comienza la búsqueda.

Su segunda consulta no funciona debido a cómo se organizan las columnas dentro de la partición. Cassandra no puede obtener una porción continua de columnas en la partición porque están intercaladas.

Debe invertir el orden de la clave principal (doodle_id, schedule_id, user_id) para poder ejecutar su consulta.