
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We're in the process of reviewing the way we do this, because under sufficient load the actual writing of these statistics is creating too much overhead.<div><br></div><div>I'm thinking something like Graphite (<a href="https://github.com/tmm1/graphite">https://github.com/tmm1/graphite</a>) but over UDP.</div><div><br><div><div>On 23 Sep 2011, at 11:37, Neil Middleton wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I'm building an app that needs to store a fair amount of events that the users carry out. (Think LOTS as in millions per month).<br><br>I need to report on the these events (total of type x in the last month, etc) and need something resilient and fast.<br><br>I've toyed with Redis etc to store aggregates of the data, but this could just mean that I'm building up a massive store of single figure aggregates that aren't rebuildable.<br><br>Whilst this isn't a bad solution, I'm looking at storing the raw event data in tables that I can then query on a needs basis, and potentially generate aggregate counters on a periodic basis. This would thus give me the ability to add counters over time, and also carry out ad-hoc inspections on what is going on, something which aggregates don't allow.<br><br>Question is, how is best to do this? I obviously don't want to have to create a model for each table (which is what Rails would prefer), so do I just create the tables and interact with raw SQL on a needs basis, or is there some other choice for dealing with this sort of data?<br><br>It would be interesting to know what thoughts you guys have.<br><br>Cheers<br><br>Neil<br><br>_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></div></blockquote></div><br></div></body></html>