Home Index

1. Cassandra

2. Time Series Data

Cassandra / Time Series Data /

Weather - Time Series Data

Weather is classified as time-series data because of every weather event points into the specific date and time.

The Risk of using Redis for Weather Time Series Data

With constantly inserting, updating and deletting weather data, plus editors editing weather data alerts, which created a new specific weather data alerts for their particular channels, the data will grow in Redis memory based database.

As data grows Weather Time Series Data will most likely run into congestion and stall using because of extensive scanning, swapping large amount of memory frequently. Therefore this solution become not scalable as more data being added into Redis slower will be to retrieve the data using scanning all the rows in the Redis and scan queries become slower, scanning a larger and larger key/value data sizes.

Industry solutions for Weather Time Series Data

There are many solutions for time-series data as PostgreSQL uses Adaptive Space-Time Chunking, similar to MySQL, Cassandra using partitioning, and clustering keys and others.

Understanding Time Series Retrieval:

To minimize seeks through Times Series Data a system needs two indexes.
  1. An index that holds the key
  2. An Index that eliminates the majority of data where the data for selected time is not present.

Redis shortcoming when dealing with Time Series Data:

Redis holds one key/value pair thus creating an issue for Time Series data. For Time Series data a second index necessary to eliminate majority records where the data for a specific time is not present. Thus Redis must always scan all the records for each request generating many seek through the memory.

Time Complexity = O(n)

Example: Scanning for Zone in Minneapolis requires to scan the entire Redis keys/value pair, generating comparison 0(n) - very slow, not scalable solution as data grows.

$ redis-cli -h localhost --scan --pattern '*MNZ*' WeatherHeader:MNZ034:6f1e4605-603c-3529-ba20-052da1978f20 WeatherHeader:MNZ074:fbdaed6a-a15f-3c2a-bf91-10c45f75ae70 WeatherHeader:MNZ054:1fdb238b-f5c3-3002-89f3-27b4d6c9aec1 WeatherHeader:MNZ039:16dc3e14-2242-3515-9539-1f8c9b115daf WeatherHeader:MNZ061:d5666cde-2ad3-3f46-8b35-47d66aceca3e WeatherHeader:MNZ065:14a0ef83-fa9d-3c7b-a8dc-ff5b8dba135f ...

Time Series Data Modeling using Cassandra Distributed Database:

In the industry, there are many solutions how to implement Time Series data. Below, I am illustrating a solution using distributed NoSQL database Apache Cassandra.

Time Series Pattern - Reverse Order Timeseries with Expiring Columns (7 days):

The the following id an example to create a tables on Distributed Database that identify composite index that includes:
  1. Partition Index: event_alert - ( identifies where on which server and parition the data will reside )
    Time complexity O(1)
  2. Clustering Index: event_time - ( is a storage engine process that sorts data within each partition based on the definition of the clustering columns, column is sorted in ascending or descending order using Merge Sort )
    Time complexity O(n log n) - Merge Sort

CREATE TABLE weather_header ( event_alert text, event_time timestamp, json text, PRIMARY KEY (event_alert, event_time), ) WITH CLUSTERING ORDER BY (event_time DESC);

INSERT INTO weather_header(event_alert,event_time,temperature) VALUES (’NH:ZONE:014’, ’2018-07-12 07:03:00′, ’{"key":"3eb00062-761d-3e46-910c-49350d8f0b87"...}’ ) USING TTL 604800;

SELECT event_alert, event_time, json FROM weather_header WHERE event_alert = "NH:ZONE:014" AND event_time > ’2018-07-11 07:03:00′ AND event_time < ’2018-07-12 07:03:00′;