SQL vs. NoSQL - some initial findings

Let me first say this post is not a scientifically controlled report - it is nothing more than some initial findings I thought it worthwhile sharing when it comes to SQL vs. NoSQL - in this case MongoDB. I know way more about SQL than I do NoSQL, but I am embarking on a project which will involve large amounts of real time data manipulation and processing for retail, and I’ve been having a play with MongoDB. There were some surprises:

1. I believed based on things I had read that a carefully structured relational database, with an optimised schema would be faster answers the questions it was designed for than any NoSQL solution. I’m not entirely sure this is true in the vast majority of cases. I actually wonder if the edge cases where this may be true make it worth using SQL unless you can really, REALLY show that it’s a good idea.

2. I had not really thought too much about the boilerplate that goes with SQL vs. NoSQL, but compare these two bits of code:




and:




These both do the same thing - use a DataGenerator to generate a bunch of test data, which in this case creates a load of first and last names, and emails. In the case of the SQL test (no ORM to be fair) there’s way more code because you have to somehow map the object domain to the data domain. Not so in the second, where you just chuck the object into the db.

This leads me to:

3. There is no “schema” per se. There are just buckets. This feels a bad thing - strong typing is good, right? Well, adding a column to a database that’s been running for a while and may have millions of records is a big deal. In a NoSQL solution you just add the new kind of object. Old objects will simply not have the new field (so one assumes you need some null checking and maybe be careful how you rebuild your Java object akin to serialisation perhaps (?) but the db is ultimately flexible.

4. Last one for now - check out the search code below. Each does the same thing - does a search for all names that start with a capital “A”:




and now the MongoDB version:



See the function chaining in the MongoDB solution? How elegant is that? Rather like Java8 streams or the kind of sequence processing you see in Clojure this is a really elegant way to process the results. Incidentally, it’s a load quicker in MongoDB than it is in Derby DB for any number of records. I’d like to say that this is because it’s a LIKE type query which is just about the most horrible thing you can do in an RDBMS, but actually, EVERY query is quicker in MongoDB. Counting the records, searching for a specific record - they’re all just quicker in my MongoDB version.

I’m sure there will be people thinking I’ve got my RDBMS tables set up badly or whatever, and while there may be optimisations I could do I’ve done nothing to either Derby or Mongo - this is just out of the box.

Interesting stuff - download MongoDB from www.mongodb.org and have a play.