[thibaut_barrere]

First, thanks for sharing! Then a comment on this:

"I've done implementations of the above using SQL databases (MySQL) and it wasn't fun at all. The storage mechanism is awkward - put all your values in a single table and have them keyed according to stats name and period. That makes querying for the data weird too. That is not a showstopper though - I could do it. The real problem is hitting your main DB a couple of times in a web request, and that is definitely a no-no."

This is not a SQL vs NOSQL issue: decoupling the reporting system from your main (production/transaction) system is a widely advised practice in "business intelligence".

Use a different instance, with a schema designed for reporting.

You can use Redis for that (and I use it actually!) but you can also use MySQL or any other RDBMS.

It's fairly easy to implement: one line for each fact, then foreign keys to a date dimension and hour dimension (see [1]), then you can sum on date ranges, hour ranges, drill down etc, on many different metrics.

[1] https://github.com/activewarehouse/activewarehouse-etl-sampl...

[hdeshev]

Sound advice. I didn't mean to go to the SQL vs. NoSQL war zone and I have nothing against SQL DB's. All I wanted to say is that I find the current Redis solution easier to implement than the [clumsy] one I did in the past.

[thibaut_barrere]

Yeah no worries! I didn't imply you meant that :) Like I said I use redis timeseries exactly like you.

The pros are that it's very easy to setup etc (no schema definition, very practical API, easy to query), the cons are that you are limited by the memory space (but like you wrote, not an issue in your cases) and that it's harder to make more elaborated reports.

But I use both techniques depending on the needs.

Thanks for taking the time to write this!