database - timescale postgres

Modelo de datos de Cassandra para series de tiempo

Question

Estoy trabajando en un modelo de datos de Cassandra para almacenar series de tiempo (soy un novato de Cassandra). Tengo dos aplicaciones: datos de existencias intradía y datos de sensores.

Los datos de stock se guardarán con una resolución de tiempo de un minuto. Siete campos de datos crean un marco de tiempo: Símbolo, Fecha y hora, Abierto, Alto, Bajo, Cerrar, Volumen

Voy a consultar los datos principalmente por Symbol y Date. por ejemplo, dame todos los datos de AAPL entre 2013-01-01 y 2013-01-31 ordenados por Fecha y hora. La recomendación para las consultas de cassandra es consultar columnas enteras. De modo que podría crear cinco filas con las teclas Abrir, Alto, Bajo, Cerrar, Volumen. Y para cada Símbolo y Minuto una columna propia. Por ejemplo, "AAPL: 2013-01-04T130400Z". Esto daría como resultado una tabla de cinco filas y n * columnas NT donde n = número de símbolos, nT = número de minutos. La mayoría de las veces consultaré los rangos de fechas. Es decir, todos los minutos del día. Así que pude reorganizar los datos para tener columnas llamadas "AAPL: 2013-01-04" y filas: OpenT130400Z, HighT130400Z, LowT130400Z, CloseT130400Z, VolumeT130400Z. Esto daría como resultado una tabla con n * nD columnas (n: número de símbolos, nD: número de días) y 5 * nM filas (nM: número de minutos / entradas por día).

En resumen: tengo columnas, que contienen la información de todo un día para un símbolo.

He encontrado una descripción de cómo tratar los datos de series de tiempo en cassandra aquí http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra Pero realmente no entiendo, si usan el hora (1332960000) como un nombre de columna o como una clave de fila !? Entendí que usan la hora como clave de fila y tienen los pequeños pasos de tiempo como columnas. Entonces tendrían un número de columna fijo. Pero eso tendría desventajas en la lectura porque tendría que hacer una consulta de rango en las teclas. ¿Estoy en lo cierto?

Segunda pregunta: si tengo datos de sensores, que son mucho más precisos que los datos de stock de 1 minuto (digamos que tengo que guardar los pasos del tiempo con una resolución de microsegundos) ¿cómo podría lidiar con esto? Si uso columnas para guardar un compuesto de canales y horas de sensores, y filas de microsegundos desde la última hora, esto resultaría en 3,600,000,000 filas y n * nH columnas (n: número de sensores, nH: número de horas). No pude usar los microsegundos desde la última hora para las columnas porque tengo 3,6 mil millones de puntos, que es más alto que el número permitido de 2 mil millones de columnas.

¿Lo conseguí? ¿Qué piensas sobre este problema? ¿Cómo resolverlo?

¡Gracias!

Mejor, Malte

Answer 1

Así que tengo una sugerencia para su primera pregunta sobre los datos de stock. Una implementación ingenua podría verse así:

RowKey:

Formato de columna:

Nombre: la fecha actual granular a un minuto

Valor: una columna compuesta de Abierto, Alto, Bajo, Cerrar, Volumen

Entonces tendrías algo como

AAPL = [2013-05-02-15:38:00 | 441.78:448.59:440.63:15066146:445.52] ... [2013-05-02-15:39:00 | 441.78:448.59:440.63:15066146:445.52] ... [2013-05-02-15:40:00 | 441.78:448.59:440.63:15066146:445.52]

Eso le daría aproximadamente medio millón de columnas en un año, por lo que podría estar bien por unos 4 años. No iría e intentaré alcanzar el límite de 2 mil millones. Lo que podría hacer es definir un factor de división en la clave de fila. Todo depende de su patrón de uso, pero uno simple podría estar en el año, por lo que la entrada de la familia de columnas podría verse así con una clave de fila compuesta y eso garantizaría que siempre tenga menos de un millón de columnas por fila.

AAPL:2013 = [05-02-15:38:00 | 441.78:448.59:440.63:15066146:445.52] ... [05-02-15:39:00 | 441.78:448.59:440.63:15066146:445.52] ... [05-02-15:40:00 | 441.78:448.59:440.63:15066146:445.52]