I’m planning on creating a live analytics’s page for my website – A bit like Google Analytic but will real live data which will change as new users load a page on my site etc.
The main site is/will be written using Asp.Net/C# as the back end with a MS SQL database and the front end will support things like JavaScript (JQuery), CSS3, HTML5 (If required).
I was wondering what methods can I use to have the live analytic in terms of; How to get the data onto the analytic’s page, what efficient graphing can I use, and storing the data with fast input/output.
The first thing that came to my mind is to use Node.js – Could I use this to achieve a live analytic’s page? Is a good idea? Are there any better alternatives? Any drawbacks with this?
Would I need a C# Application running on a server to use Node.js to send/receive all the data to and from the website?
Would using a MS SQL database be fast enough? Would I need to store all the data live, or could I store it in chunks every x amount of seconds/minutes? (Which would be more efficient?)
This illustrates my initial thoughts on the matter –
Edit:
I’m going to be using this system over multiple sites, I could be getting 10 hits at a time to around 1,000,000 (Highly unlikely, but still possible). I want to be able to scale this system and adapt it to the environment it’s in.
It really depends on how “real time” the realtime data needs to be. For example, I made this recently:
http://www.reed.co.uk/labs/realtime/
Which shows job applications coming into the system. Obviously there is way too much going on during busy periods to actually be querying the main database in realtime – so, what we do is query a sliding “window” and cache it on the server – this is a chunk of the last 5minutes worth of events.
We then play this back to the user as is it’s happening “now”. having a little latency as part of a SLA (wherein the users don’t really care) can make the whole system vastly more scalable.
[EDIT- further explanation]
The data is just retrieved from a basic stored procedure call – naturally, a big system like reed has hundreds of transactions/second – so we cant keep hitting the main cluster, for every user.
All we do, is make sure we have a current window, in this case the last 5min of data cached on the server. When a client comes to the site, we get that last 5min of data, and play it back like it’s happening right now – the end user is none-the-wiser – but what it means is that all clients are reading off the cache. Once the cache is 5min old, we invalidate it, and start again. This means a max of 1 DB hit, every five min – thus making teh system vastly more scalable (not that it really needs to be – as it’s just for fun, really)