redis vs traditional sql
a.cudbardb at freeradius.org
Mon Mar 6 15:00:37 CET 2017
> On Mar 6, 2017, at 6:11 AM, Peter Lambrechtsen <peter at 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.
> 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.
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
> 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.
FreeRADIUS Core Developer
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Users