redis vs traditional sql
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.
On Mar 6, 2017, at 6:11 AM, Peter Lambrechtsen <peter@crypt.nz> wrote:
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.
Yes, the only issue is being notified of when that happens. If you don't care about when the sessions expire, that's fine. If you do, you run up against potentially unreliable notifications, and the expires not occurring instantly but happening in batches.
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.
Yep.
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.
Yes.
This means much of the pain with managing a large dynamic DB goes away as the redis db is self cleaning.
Yes :) That's why I like it too for accounting. One of the future projects will likely be a proto_* module to receive notifications from Redis and do stuff with it.
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.
and it scales horizontally too. In v3.1.x there's native support for Redis cluster. -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Peter Lambrechtsen