redis vs traditional sql

[Peter Lambrechtsen]

I'm looking to store delta usage information on a temporary basis so it can
be exported out as a CSV style and fed off to an upstream billing system.

Using redis seem to meed my needs of high performance and light, I
especially like the expire feature so I don't need to worry about cleaning
up stale sessions as they will just fall off at the end of the day.

The main use case is just allowing FR to calculate the delta from the last
time period, using the Acct-Session-Id as the primary key. Store the
current timestamp, bytes up, bytes down against the Session ID.

Then when the interim turns up calculate the difference and spit that out
to a linelog then update the record in redis with the new timestamp + new
byte counts and reset the expiry.

Then send DMs to the subscribers if I get a timestamp that's wildly outside
the expected period, with a tollerace since then if there was a FR outage /
patching for a period of time the accounting events turning up wouldn't
cause a mass-DM of the end-users.

This means much of the pain with managing a large dynamic DB goes away as
the redis db is self cleaning.

Or is it just easier to stick with the traditional mysql/postgre model and
not get too clever log everything and then run cron jobs afterwards to do
the typical cleanup:

DELETE FROM events WHERE timestamp < (NOW() - INTERVAL 1 HOUR)

I also love the raw transactional throughput of redis which means I don't
need to have as sigificant db running this log.