versiones que commands cassandra cql

que - Cassandra obtener todos los registros en el rango de tiempo



install cassandra (3)

El tiempo de espera se debe a que Cassandra está demorando más que el tiempo de espera (el valor predeterminado es 10 segundos) para devolver los datos. Para su consulta, Cassandra intentará obtener todo el conjunto de datos antes de regresar. Para más de unos pocos registros, esto puede llevar fácilmente más tiempo que el tiempo de espera.

Para las consultas que están produciendo gran cantidad de datos, necesita una página, por ejemplo:

SELECT * FROM userlog WHERE ts >= ''2013-01-01 00:00:00+0200'' AND ts <= ''2013-08-13 23:59:00+0200'' AND token(user_id) > previous_token LIMIT 100 ALLOW FILTERING;

donde user_id es el user_id anterior devuelto. También deberá hacer una página en ts para garantizar que obtenga todos los registros del último ID de usuario devuelto.

Alternativamente, en Cassandra 2.0.0 (recién lanzado), la paginación se realiza de manera transparente, por lo que su consulta original debería funcionar sin tiempo de espera ni paginación manual.

El ALLOW FILTERING significa que Cassandra está leyendo todos sus datos, pero solo está devolviendo datos dentro del rango especificado. Esto solo es eficiente si el rango es la mayoría de los datos. Si quisiera encontrar registros dentro de, por ejemplo, una ventana de tiempo de 5 minutos, esto sería muy ineficiente.

Tengo que trabajar con una familia de columnas que tiene (user_id, timestamp) como clave. En mi consulta, me gustaría recuperar todos los registros en un rango de tiempo determinado independiente del ID de usuario. Este es el esquema de tabla exacto:

CREATE TABLE userlog ( user_id text, ts timestamp, action text, app_type text, channel_name text, channel_session_id text, pid text, region_id text, PRIMARY KEY (user_id, ts) )

Traté de correr

SELECT * FROM userlog WHERE ts >= ''2013-01-01 00:00:00+0200'' AND ts <= ''2013-08-13 23:59:00+0200'' ALLOW FILTERING;

que funciona bien en mi instalación local de cassandra que contiene un pequeño conjunto de datos pero falla con

Request did not complete within rpc_timeout.

En el sistema productivo que contiene todos los datos.

¿Hay alguna consulta, preferiblemente cql, que funcione correctamente con la familia de columnas dada o que tengamos que cambiar el diseño?


En general, esto puede ser una indicación de que no ha modelado su esquema para que se adapte a su consulta de datos, que es la forma en que Cassandra hace las cosas ( https://docs.datastax.com/en/cql/3.3/cql/ddl/dataModelingApproach.html ) ...

Entonces, idealmente, modelarías tu esquema para que se ajustara a la consulta. Hay algunos recursos en torno a cómo hacer el modelado de series de tiempo para Cassandra, aunque, por ejemplo, esta presentación de diapositivas parece ser similar a lo que tienes, pero no es un soporte publicitario para el tipo de consulta que quieres hacer. No creo que haya encontrado ejemplos de esquemas de Cassandra que admitan las consultas "obtener todos los datos para un determinado intervalo de tiempo".

En cualquier caso, para el resto de esta respuesta asumiré que está atascado con el esquema que tiene para esta iteración.

Puede hacer esto como dos consultas:

SELECT DISTINCT user_id FROM userlog;

Y luego, para cada usuario,

SELECT * FROM userlog WHERE user_id=''<user>'' AND ts >= ''2013-01-01 00:00:00+0200'' AND ts <= ''2013-08-13 23:59:00+0200'';

Si el conjunto de ID de usuario es de tamaño pequeño a mediano, es posible que pueda utilizar una consulta IN :

SELECT * FROM userlog WHERE user_id IN (''sampleuser'', ''sampleadmin'', ...) AND ts >= ''2013-01-01 00:00:00+0200'' AND ts <= ''2013-08-13 23:59:00+0200'';

Tenga en cuenta que esto funciona sin ALLOW FILTERING .


Parece que la hotness para poder consultar por tiempo (o cualquier rango) es especificar alguna "otra columna" como su clave de Partición, y luego especificar la marca de tiempo como una "columna de agrupamiento"

CREATE TABLE postsbyuser ( userid bigint, posttime timestamp, postid uuid, postcontent text, PRIMARY KEY ((userid), posttime) ) WITH CLUSTERING ORDER BY (posttime DESC);

insertar datos falsos

insert into postsbyuser (userid, posttime) values (77, ''2013-04-03 07:04:00'');

y consulta (la parte importante es que es una consulta "rápida" y NO ALLOW FILTERING , que es como debería ser):

SELECT * FROM postsbyuser where userid=77 and posttime > ''2013-04-03 07:03:00'' and posttime < ''2013-04-03 08:04:00'';

También puede utilizar trucos para agrupar por día (y así poder consultar por día) o qué no.

Si usa el truco de estilo "grupo por día", entonces un índice secundario también sería una opción (aunque los índices secundarios parecen funcionar solo con "EQ" = operador?).