not - number in cassandra

Almacenamiento de rangos de tiempo en cassandra

Question

Estoy buscando una buena manera de almacenar datos asociados con un rango de tiempo, para poder recuperarlos más tarde de manera eficiente.

Cada entrada de datos se puede simplificar como (start time, end time, value) . Necesitaré recuperar más tarde todas las entradas que caen dentro de un rango (x, y) . En SQL, la consulta sería algo así como

SELECT value FROM data WHERE starttime <= x AND endtime >= y

¿Puede sugerir una estructura para los datos en Cassandra que me permita realizar tales consultas de manera eficiente?

Answer 1

Esto es una cosa extrañamente difícil de modelar eficientemente.

Creo que usar los índices secundarios de Cassandra (junto con un valor indexado ficticio que lamentablemente aún se necesita en este momento) es su mejor opción. Tendrá que usar una fila por evento con al menos tres columnas: ''inicio'', ''final'' y ''ficticio''. Crea un índice secundario en cada uno de estos. Los primeros dos pueden ser LongType y el último puede ser BytesType. Consulte esta publicación sobre el uso de índices secundarios para obtener más detalles. Como debe usar una expresión de ecualización en al menos una columna para una consulta de índice secundaria (el desafortunado requisito que mencioné), el ecualizador estará en "ficticio", que siempre puede establecerse en 0. (Esto significa que la expresión de índice de ecualización coincidirá con cada fila y esencialmente será no operativa). Puede almacenar el resto de los datos del evento en la fila junto con el inicio, el final y el maniquí.

En pycassa , un cliente Python Cassandra, su consulta se vería así:

from pycassa.index import *
start_time = 12312312000
end_time = 12312312300
start_exp = create_index_expression(''start'', start_time, GT)
end_exp = create_index_expression(''end'', end_time, LT)
dummy_exp = create_index_expression(''dummy'', 0, EQ)
clause = create_index_clause([start_exp, end_exp, dummy_exp], count=1000)
for result in entries.get_indexed_slices(clause):
# do stuff with result

Debería haber algo similar en otros clientes.

La alternativa que consideré involucró en primer lugar a OrderPreservingPartitioner, que casi siempre es una mala cosa. Para el índice, usaría la hora de inicio como la clave de la fila y la hora de finalización como el nombre de la columna. A continuación, puede realizar un segmento de rango con start_key = start_time y column_finish = finish_time. Esto escaneará cada fila después de la hora de inicio y solo devolverá aquellas con columnas antes de finish_time. No es muy eficiente, y tienes que hacer un gran multigrado, etc. El enfoque del índice secundario incorporado es mejor porque los nodos solo indexarán los datos locales y la mayoría del código de indexación repetitivo se maneja por ti.