4 ms·
Cube: time series visualization (MongoDB + Node + D3)
- hermanjunge 15y agoLove 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...
- scottostler 15y agoLooks 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.
- friggeri 15y agoBelieve it or not, I am actually developing exactly the same thing. I guess I'll use Cube then !
- croddin 15y agoThis is almost exactly like something that I've been wanting to build!
- bryanh 15y agoThis 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.
- xnxn 15y agoI say go for it! It sounds very useful (and has an obvious monetization strategy if you wanted to make a business out of it).
- xyzzyb 15y agoSounds like GoodData (http://www.gooddata.com/ http://www.gooddata.com/), which is great! Competition drives innovation.
- deleted 15y ago[deleted]
- khafra 15y agoSounds like Splunk, to me.
- pedoh 15y agoWe're currently using Graphite ( http://techblog.appnexus.com/2011/metrics/ 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.
- ojilles 15y agoIt 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!
- mnutt 15y agoThis 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?
- mnutt 15y agoTo answer my own question, it's because the author is doing asset bundling.
- gourneau 15y agoI wish they would have used ProtoVis with DataMarket's IE Shim http://blog.datamarket.com/2011/06/22/protovis-support-internet-explorer-8/ 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/ 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 :)
- noahnoahnoah 15y agoThis 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.
- mbostock 15y agoTrue, 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.
- ojilles 15y agoDoesnt that not simply already exist with RRDTool?
- deleted 15y ago[deleted]
- mwsherman 15y agoImpressive. Suspect we’ll see folks rolling their own Chartbeats.
- deleted 15y ago[deleted]
- moe 15y agoYes, you missed that this has nothing in common with RRDTool other than that both happen to deal with timeseries data.
- wuster 15y agoI 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.
- mildweed 15y agoDid somebody say Time Cube?
- dgudkov 15y agoWe 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 http://explainum.com