Month: August 2013

Learning MongoDB // The CRUD

If you have not been following my blog for the training i am undertaking on mongodb, it is time you do so now because this is getting way too much interesting. Last night I took the Week 2 course and it was a slam dunk. I opened tbe course at around midnight and I wanted to finish the same yesterday as I wanted to submit my homework and get on the scorecard. It took me around 3 hours and honestly I skipped the last 5 Lectures. I realized that a) I should not be doing this past midnight as it gets real hard to focus with you wanting to sleep and b) should not have a movie running on the side. Anyways, I managed to finish the course in just under 3 hours and it felt good.


What I learnt?

Week 2 is about CRUD which in mongo terms is Insert, Find, Update, Remove (they didn’t have a cool acronym like CRUD). First half of the course was heavy in mongoshell and work with various commands, The session was high enough to share all possible commands especially when you have query with various operators like $gt, $lt, $and, $or and several others. The 2nd half of the course moved over into Java and we were asked to do similar operations using the Java driver for Mongo // there were no frameworks like Spring and it was all native Mongo. To list down all that I learnt:

a) insert()

b) findOne() and find()

c) update() (including multi updates)

d) remove()

e) Query using $gt, $lt, regex, $exists, $type, $or, $and, arrays, $in, $all, $set, $unset, $push, $pop, $pushAll, $pullAll

f) Cursors and find, sort, limit (paginate)

When I tell you that this week will come as a big surprise and it is heavy considered to what Week 1 is // so be prepared to focus.


My Takeaways

This week we did not get into modelling where I really want to go to, but this week was insightful as it allowed me to understand the power of the mongo’s schemaless design principle. There are ways in mongo that we can get data and only get what we need, we can even set what we need to. So the need to work on various joins and managing schemas as the domains grows is really pretty easy in mongo. We have been looking to use mongo in a setting to manage data for various tenants and the profile itself will vary not just from a tenant to tenant, but also between tenants as they might work with multiple profiles and also at times just may need to update profiles. Last night, provided me a good understanding of how we can meet all those uses and not dealing with a lot of Java boilerplate code aka delegating the stuff/tasks over to mongo and let it do it for us.

The other big takeaway was that working with mongo’s document structure is much more simpler to what RDBMS is. While was I working in mongoshell where I was using JavaScirpt to write code and later when i moved over to Java classes it was fairly simple. It was all about knowing 3 classes (if not 2) and you are done. Working with Maps (or Dictionaries) is pretty simple and using that knowledge in any language cant really be difficult. I was able to go back and learn JavaSciprt all over again and code a logic pretty quick.


Key Takeaways

a) The flexibility that MongoDB brings with itself is pure awesomeness and amazing // it has the capability to get anyone started in matter of minutes

b) The operations and way they work on the underlying documents is pretty slick and present several opportunities – must try

Learning MongoDB // It sinks in

Today I finished the 1st week of the course and as they promised it was didnt take very long – under 5 hours with what they wanted me to do (listen to lectures, answer quizzes and submit myhomework) + some other stuff I wanted to try out.


About the course so far

A true 101 courseware, and this one was even more basic – it was all about setting up the environments, running some basic commands and the quizzes were almost novice assuming that people won’t know any tools. They asked us to execute commands on a terminal window and put the output in a textbox. Barring the aspect that I am being treated like a school kid who seems to have got his hands on a computer for the first time I liked it overall.


What I learnt about MongoDB?

a) how to install it

b) how to interface with the database // add records, query records (very simple like “select *”)

c) its operating model // schemaless nature of it

d) comparison of a relational model and how i could possibly fit it into a no-schema document store like MongoDB


My Takeaways

My primary objective has been to build a POV that allows me to decide when to use a Mongo instead of a relational database. I definitely took a step in that direction. My current viewpoint is that Mongo will force us to think of data structure more close to what our Class Object Models are. We have strived for some time to put in ORM tools like iBatis and Hibernate to abstract the developers from the underlying data-models. I am not sure why we never wanted out developers to work with data-models, but Mongo will definitely take the folks away from relational models and allow them to think of objects as store them as is.


Other key aspect is if I was to architect an application (a simple layer cake design), it would be interesting for me to see where do i draw the line between the conventional Services -> DataAccessor layer cake design. I looks at Spring’s implementation of the Mongo and it very different than what Spring has (or had if they have changed) for say hibernate and MySQL. In past Spring had a clear distinction of what a DataAccessor is and what a service is and the demarcations of Transactions etc. Spring’s implementation of Mongo is pretty simple and almost unilateral when it comes to layers that define – so much so that the lines between the Service and Access are blurred and I struggle to define if i even need it.


As for modelling (which will remain key), unlike in RDBMS where we have a normal form and rules in place and where a 1st normal form was almost bad, and 4th normal form is where we wanted to go, Mongo will leave the modelling (of whatever schema it has) to the logical thinking of the application. It is my understanding that the balance of modelling the “collections” will rely with Application Architects (not with DBAs). It might be too early to say, but it seems that we need to design for “fast reads” and we aim to put whatever data we can in a dictionary that can hold all of it. The interesting aspect is when you need to see the data from another dimension. Here is an example (building upon what was presented to me course). The course is asking me to create a web application that is a blog basically. Keeping other stuff aside, we have “Post” and every post has “Tags”. As a requirement we need to show all tags for a post next to it and also for a tag as we can show all posts.


We all know a many-to-many relation in a relational database will do this trick for us, but in a document database we put (or so was I asked) Tags as a array in the Post Object itself. The power of it was now i dont need to join the two tables and the retrieval is super fast but now when I need to meet my need for getting all Posts for a given tag or if i need to change the name of the Tag globally – what was supposed to be a simple label change in RDBMS now becomes a marathon. As for the later case, I was arguing how many times does that really happen (aka change tag labels) but the first one is pretty important for my blog requirements. The course didn’t answer that one. They explained the benefit (no join hence fast fetch) and left it at it.

I start off the Week 2 tomorrow and I will want and see if they actually explain some of these over the course of the classroom else I will go about digging? Would any of you know?


Key Takeaways

a) Pretty quick to get going off the ground. I’d actually use this one instead of a mysql if i am trying a few things and need to use quick-start backend. (where in production – i don’t know yet)

b) If you are taking this course be mindful of not making judgements on the technology or how you’d want to use it especially model your schemas (or shall I say documents). Wait for the now or go and read more.

Learning MongoDB // Getting Started

My status on FB today was “Back to School”. After several years or running with the philosophy of “I don’t like sitting in classrooms” to learn technology, today I finally went back to an online classroom and it was to learn development with MongoDB.


The objective I started off was pretty simple – “I have worked with RDBMS several times in my life and now I want to know what does a “Document Store” like MongoDB brings to the table”. I hear everyone that we should move over to a NoSQL but I am not convinced in my head what problems it will really solve for me – scale, no-schema or something else. More importantly, I want to form a POV as to what I should be using a RBMS vs. a “Document Store” like a MongoDB.


I had registered for this “free” online course here – (via a cross post on VOX that I cant seem to find). This course started on July 29th, but today is my first day for the class (and this is what I loved – i can’t work on my own terms and schedule). The week 1 course has about a dozen or so online lectures and they range from introducing Mongo, differences from relational, installations and some commands.


My first experience today after spending 1 hour on the course:

  1. Pretty easy to install and get going // I use a Mac and hence some manual steps but I had the mongo db and shell up and running in about 10 minutes (download time included)
  2. Working with Shell is pretty simple // similar to working on a SQL shell for MySQL. No need to create any schema – just fire away and if you know JSON (which i did) i am entering records in under a minute
  3. Fetching records was even simpler – another couple of commands and I was rolling


Tomorrow is another day // so keep tuned.