Results for tag "mongodb"

3 Articles

MongoDB’s Aggregation Pipeline: make your life easier… or at least less difficult

The following is from Avinash Kaza’s article: Business Intelligence Platform: Tutorial Using MongoDB Aggregation Pipeline

Found here:


Using data to answer interesting questions is what researchers are busy doing in today’s data driven world. Given huge volumes of data, the challenge of processing and analyzing it is a big one; particularly for statisticians or data analysts who do not have the time to invest in learning business intelligence platforms or technologies provided by Hadoop eco-system, Spark, or NoSQL databases that would help them to analyze terabytes of data in minutes.

The norm today is for researchers or statisticians to build their models on subsets of data in analytics packages like R, MATLAB, or Octave, and then give the formulas and data processing steps to IT teams who then build production analytics solutions.

One problem with this approach is that if the researcher realizes something new after running his model on all of the data in production, the process has to be repeated all over again.

What if the researcher could work with a MongoDB developer and run his analysis on all of the production data and use it as his exploratory dataset, without having to learn any new technology or complex programming languages, or even SQL?

If we use MongoDB’s Aggregation Pipeline and MEAN effectively we can achieve this in a reasonably short time. Through this article and the code that is available here in this GitHub repository, we would like to show how easy it is to achieve this.


For more, check out the entirety of Avinash’s tutorial.






SQL vs NoSQL. Part Three.

In previous posts I talked about SQL and NoSQL, and I want to go into a little more detail (while keeping it simple) what makes them different.

Scalability>>> Think making big things small. In SQL data is stored vertically (so typically all on one server- expensive!).  NoSQL stores it horizontally (many servers==ok).

Schema>>> Technically schema means a representation of some model. In programming land, it is used to refer to a structure of a database.  So think because you can’t see a database (at least I hope you can’t) you have to think how that structure is represented.   In SQL, the schema is fixed, columns must be decided ahead of time, and you have to put data in every column.  Remember that wine shelf? You can’t really be adding a new column to your shelf after you’ve built it…it will probably look like all the images when you google “shelf fail.”

Shelf Fail

I don’t know why, but this shelf is kind of cute.

Also, you have to put a bottle in every slot. Someone’s going to be a happy wine collector.

NoSQL deals with schema in a very different way. It just says “Nope.” and walks away. You can add (or leave out) anything you want, anytime you want. Now that’s flexibility.

Data>>> Finally let’s get to the data. In SQL all rows contain one specific entry. For example, in a row containing information about a bottle of wine you might have “Year”,”Location”,”Winery” etc. You can’t have two years for a bottle of wine, or two locations. In NoSQL, that’s A-OK. You can have two wineries (maybe it was a collaboration?) or no wineries. If that’s what you want.

More reading.

Next post I’ll be going into more detail about NoSQL and specifically MongoDB.




Delving into the world of MongoDB

Today I played with Mongo DB a bit,  and am planning on building some things in the next week.

It was a busy day so I didn’t accomplish much so far.

I’m using Udacity’s Data Wrangling with MongoDB. It’s the first course I’ve taken on their platform, so I’ll write a little review afterwards.

That’s it for today. Here’s to a more productive day tomorrow!