commands - create table cassandra

"Solicitud incorrecta: PRIMARY KEY parte to_id no se puede restringir" al intentar seleccionar el uso de la condición where

Question

Aquí está mi tabla cassandra para el tipo de aplicación de chat:

CREATE TABLE tax_keyspace_dev.chat_messages (
  message text,
  when timestamp,
  from_id text,
  to_id text,
  read boolean,
  participants text,
  PRIMARY KEY(participants, when, to_id)
);

Este trabajo de consulta:

select * from tax_keyspace_dev.chat_messages where participants=''[email protected][email protected]'' order by when;

pero las siguientes consultas no funcionan:

select * from tax_keyspace_dev.chat_messages where to_id=''[email protected]'' order by when; 

El error es " Solicitud incorrecta: la parte PRIMARIO DE LA LLAVE to_id no se puede restringir (la parte anterior cuando no está restringida o por una relación que no es EQ) "

update tax_keyspace_dev.chat_messages set read=true where participants = ''[email protected][email protected]'' and when = ''2014-04-10 17:44:22+0530''; 

El error es " Solicitud incorrecta: falta la parte PRIMARY KEY obligatoria to_id "

Si elimino "to_id" de la clave compuesta y creo un índice separado como este:

CREATE TABLE tax_keyspace_dev.chat_messages (
 message text,
 when timestamp,
 from_id text,
 to_id text,
 read boolean,
 participants text,
 PRIMARY KEY(participants, when)
);
CREATE INDEX idx_chat_messages_to ON tax_keyspace_dev.chat_messages (to_id);

luego otras consultas funcionan pero esta falla:

select * from tax_keyspace_dev.chat_messages where to_id=''[email protected]'' order by when;

con error " Solicitud incorrecta: ORDER BY con índices secundarios no es compatible " .

¿Cómo diseño mi mesa para que todos estos casos de uso puedan funcionar?

select * from tax_keyspace_dev.chat_messages where participants=''[email protected][email protected]'' order by when;
update tax_keyspace_dev.chat_messages set read=true where participants = ''[email protected][email protected]'' and when = ''2014-04-10 17:44:22+0530'';
select * from tax_keyspace_dev.chat_messages where to_id=''[email protected]'' order by when;

Answer 1

Cuando usa cassandra, la primera parte de la clave principal se convierte en la clave de la partición. Por lo tanto, para ir a una partición particular para recuperar la fila, necesita especificar la clave primaria con la restricción equals siempre.

select * from tax_keyspace_dev.chat_messages where participants=''[email protected][email protected]'' order by when;

La siguiente consulta sugiere que llegue a la partición de la fila denominada "participantes" y luego realice el pedido cuando utilice la ordenación predeterminada de ASC. Esta orden puede no ser necesaria también, ya que sus columnas se ordenan por defecto en orden ascendente.

select * from tax_keyspace_dev.chat_messages where to_id=''[email protected]'' order by when; 

select * from tax_keyspace_dev.chat_messages where to_id=''[email protected]'' order by when;

La siguiente consulta no funciona ya que no proporciona la partición de fila para ubicar el valor. De manera predeterminada, las claves de partición de fila se utilizan para identificar los archivos SSTables que contienen los datos. Entonces, por defecto, cassandra no soporta esta operación costosa.

Lo que sucede es simple. Si omite esta clave de partición de la fila, cassandra tiene que escanear todas las estadísticas y obtener los datos de ella. Eso se puede hacer usando PERMITIR EL FILTRADO, pero su consulta se vuelve costosa ya que no usará el filtro de floración.

update tax_keyspace_dev.chat_messages set read=true where participants = ''[email protected][email protected]'' and when = ''2014-04-10 17:44:22+0530''; 

En caso de actualizaciones en cassandra, no es diferente de las inserciones. Solo considere un caso de operar con mapas. Está intentando modificar un valor pero no tiene la clave completa para el mapa. Internamente, cassandra almacena los valores son "participants_when_to_id": value.