Gran cantidad de lápidas con columnas TTL en Cassandra

cql cql3

Question

Tengo una familia de columnas de cassandra o una tabla CQL con el siguiente esquema:

CREATE TABLE user_actions (
company_id varchar,
employee_id varchar,
inserted_at timeuuid,
action_type varchar,
PRIMARY KEY ((company_id, employee_id), inserted_at)
) WITH CLUSTERING ORDER BY (inserted_at DESC);

Básicamente, una clave de partición compuesta compuesta por una ID de empresa y una ID de empleado, y una columna de agrupamiento, que representa el tiempo de inserción, que se utiliza para ordenar las columnas en orden cronológico inverso (las acciones más recientes están al principio de la fila) .

Aquí se muestra el aspecto de una inserción:

INSERT INTO user_actions (company_id, employee_id, inserted_at, action_type)
VALUES (''acme'', ''xyz'', now(), ''started_project'')
USING TTL 1209600; // two weeks

Aquí no hay nada especial, excepto el TTL que expira en dos semanas.

La ruta de lectura también es bastante simple: siempre queremos las últimas 100 acciones, por lo que se ve así:

SELECT action_type FROM user_actions
WHERE company_id = ''acme'' and employee_id = ''xyz''
LIMIT 100;

El problema: esperaría que, dado que ordenamos en orden cronológico inverso, y el TTL siempre tiene la misma cantidad de segundos en la inserción, que dicha consulta no debe escanearse a través de ninguna lápida sepulcral, todas las columnas "muertas" están en la cola del fila, no la cabeza. Pero en la práctica vemos muchas advertencias en el registro en el siguiente formato:

WARN [ReadStage:60452] 2014-09-08 09:48:51,259 SliceQueryFilter.java (line 225) Read 40 live and 1164 tombstoned cells in profiles.user_actions (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=1410169639669000, localDeletion=1410169639}

y en raras ocasiones el número de lápida es lo suficientemente grande como para abortar la consulta por completo. Como veo que este tipo de diseño de esquema se defiende con frecuencia, me pregunto si estoy haciendo algo mal aquí.

Answer 1

Quizás los datos vuelven a aparecer porque un nodo falla y gc_grace_seconds ya caducaron, el nodo regresa al clúster y Cassandra no puede volver a reproducir / reparar actualizaciones porque la lápida desapareció después de gc_grace_seconds: http://www.datastax.com/documentation/cassandra /2.1/cassandra/dml/dml_about_deletes_c.html

La reparación incremental 2.1 parece que podría ser adecuada para usted: http://www.datastax.com/documentation/cassandra/2.1/cassandra/operations/ops_repair_nodes_c.html

Answer 2

Su instrucción SELECT no está dando un orden de clasificación explícito y está por lo tanto predeterminado a ASC (aunque su orden de agrupamiento es DESC).

Entonces, si cambia su consulta a:

SELECT action_type FROM user_actions
WHERE company_id = ''acme'' and employee_id = ''xyz''
ORDER BY inserted_at DESC
LIMIT 100;

deberías estar bien