My first wrangle with NoSQL. An explanation of what I made and my thoughts on NoSQL versus the traditional RDBMS
I had a random idea the other day. I wanted to write a server that would serve, generate and store image manipulations on the fly. So that’s what I made. You can check out the GitHub repository here. The server itself takes HTTP requests much like a standard web server. It takes an image id and any sizing or cropping parameters you would like and returns the image. When you pass sizing or cropping parameters it checks to see if the image with those parameters already exists and returns that if it does. This avoids regenerating images all the time. It stores information about the images in the Mongo database.
This was sort of a new field to me as it was my first venture into the world of NoSQL. I really like the way everything works. I think this project worked well with the “Unstructured Data” that NoSQL is really good for. Different images could have a couple of sets of different attributes (and of course this would expand if I added more types of manipulations). It would certainly have been doable in an relational database, but I think this works better.
MongoDB uses a notation called BSON for its definitions and queries. BSON is much like the - probably more – familiar JSON, except with the ability to have binary objects (hence the B in BSON). Defining the data in BSON is rather trivial and, in my opinion, more natural than SQL (and certainly less verbose). I also like the fact that you can have nested data. In some instances this can be used as opposed to the using a foreign key in an RDBMS.
I did a good bit of reading before I dove into NoSQL to see if it was really any better. I had heard lots on how “NoSQL is the new wave and it’s so much better!”. Well the answer I found: It depends. There’s lots of arguments that say NoSQL, because of it’s unstructured nature, is much better at scaling. However, there’s plenty that say RDBMSs scale just fine too. I think it’s not that one can scale up better than the other, I think it’s just easier to scale up a NoSQL database in terms of code implementation. What I really got out of my reading was that the reason to use NoSQL is not necessarily for scaling, but really, it comes down to whether you need the ability to have unstructured data. As I stated, what I did with my server was not necessarily completely structured, however it could still have been implemented in typical relational style. I’ve heard that there are scenarios where you would need to have unstructured data storing abilities. I assume it’s true, though I can’t really think of an example so who knows.
All in all, I like the interactions with MongoDB a lot better than I do using SQL like I would with MySQL (Which is what I have been using for data storage since I started programming 8 years ago). However, I could get very similar interactions by using an ORM (Object Relational Mapper). Those pretty much keeps the SQL away from my eyes and lets me use an Object-Oriented interface with the server. In general, for my needs, I could use either one. I don’t really have to worry about the scale issue (for now anyways) but like i said, it really comes down to the need for structured vs. unstructured data.
I should note: my GitHub project code is not ‘ready for distribution’. It was really just a test project. The code is there for anyone to play with and modify, or look at as an example. It wont run straight away if you download it and fire it up. You will need to modify it for your environment.
