Cube: time series visualization (MongoDB + Node + D3) | Hacker News Reader

Cube: time series visualization (MongoDB + Node + D3)

square.github.com

192 pointsNelsonMinar23 comments

This kind of rekindles an interest I had in building a web app that was at its core a data vacuum.

You sent it whatever data you like, be that timestamps, integers, floats, arbitrary strings, etc... and it would let you build an intelligent dashboard displaying the data however you like.

I say go for it! It sounds very useful (and has an obvious monetization strategy if you wanted to make a business out of it).

Sounds like GoodData (http://www.gooddata.com/), which is great! Competition drives innovation.

Sounds like Splunk, to me.

We're currently using Graphite ( http://techblog.appnexus.com/2011/metrics/ ) and loving it, but using MongoDB is an interesting spin.

I'd love to see some performance benchmarks and see how many datapoints you can pump in and out of Cube. We've been collecting about 1 million metrics every minute on a speedy dual proc / quad core box backed with SSDs for storage.

This looks fantastic. From the short demo, nice UI for setting up charts, and the visualizations produced are quite nice as well.

The only downside to something like this (and Graphite, etc.) is that you can only visualize data that you store in Cube (if I understand correctly). That's great for things you sample yourself, but what if you want to compare something you sampled yourself with something from New Relic or another data source? Cube looks to go a step further than Graphite in allowing for easier custom visualizations, but data is still a one-size-fits-all thing. You can write an emitter/parser that grabs the data and stores it in Cube, but there's a huge amount of duplication (and essentially polling then).

I think a better architecture is to separate data storage/acquisition from visualization. Establish a set of standards for data interfaces that specify the output they provide, and build your visualization on top of that. Then, your interfaces can be API wrappers, mysql connections, a mongo-db based storage system, a redis-backed storage system, etc.

True, but collecting the data into a single store makes it easier to analyze. If you want to construct visualizations (or perform analysis) with data from different back-ends, you can do that using Cube’s API. I do like your idea of establishing standards for data interfaces, but I wonder how hard it would be to put into practice.

Doesnt that not simply already exist with RRDTool?

We made a tool for annotating time series -- it is intended for keeping remarks with explanations of influencing factors. Not that sophisticated but does what it does - http://explainum.com

Looks promising. I need to put together a dashboard, and this might be how I do it.

As an aside, it's always great to see more usage of PEG.js.

I love this spirit of sharing and collaboration spurred by git/github. One nice side effect of adopting these open source libs (and not re-invent the wheel in house) is that we'll all have transferrable skills between companies in this space. I like this positive trend.

This is very, very cool. I've wanted something like this for a long time.

Running it, I'm having some issues loading pages that I think has something to do with caching static assets. Why not use an existing static file library?

To answer my own question, it's because the author is doing asset bundling.

This is almost exactly like something that I've been wanting to build!

Impressive. Suspect we’ll see folks rolling their own Chartbeats.

It would be great to support something that shows the variation in the data for this stuff (average/median for response times is a notoriously bad idea).

Other than that, love it!

Love It! I'm seeing it in my stack, connected in the cloud where apps send their data to the DB via rabbitMQ, to make monitors...

I wish they would have used ProtoVis with DataMarket's IE Shim

http://blog.datamarket.com/2011/06/22/protovis-support-inter...

Yes Protovis is no longer maintained, but here is a good post defending it: http://blog.datamarket.com/2011/09/12/the-protovis-stays/

And used Socket.IO for comm (they might)

However, it is lovely, I am going try it out :)

The guy who wrote it is the author of d3, which might explain why they used d3. Plus, d3 is awesome.

Mike Bostock (creator of Protovis and D3) now works at Square, which helps explain this release from them. :)

Believe it or not, I am actually developing exactly the same thing. I guess I'll use Cube then !

Did somebody say Time Cube?

Reply on news.ycombinator.com