Great read, Im off to read another!

-Dwayne

One question I do have: Using MySQL has been comfortable for a while, as we know that when we retrieve data from there, it will have a structure, and that structure won’t change often, becuase it can’t. When working with schema-less technologies, what do dev teams need to do differently or be more aware of?

The main gist of this post was simply that NoSQL databases often provide a way to persist your data that is closer to the way you actually use it and pass it around in your application, and eliminates a lot of setup work normalizing tables and data structures that probably isn’t that important for most web projects.

NoSQL is simply a tool, and you should always choose your tools based on your work requirements. It just happens that this tool is rapidly increasing in relevance, and I believe will be a very significant player in the near future because of all the benefits it provides and flexibility it has.

The right name on that boat should have been “Horizontally Scalable Data Storages”. And as the name suggests, the main passengers on that boat are cassandra, hadoop, bigtable, riak, voldemort.

Interestingly enough MongoDB team initially also missed the point of modern “NoSQL” phenomenon. But they quickly learned, and now automatic sharding is their top priority for next version.

As for impedance mismatch, the real NoSQL camp (oodb databases) were trying to sell it for decades. They failed. But this is a completely different story.

I think it is a real problem that MongoDB does not have transactions which span linked objects. I also think it’s not good that there are not ways to optimize the load of multiple linked objects across the network … which is generally a performance killer. For those developing it, these are some of the things I would suggest taking a look at in future implementations. Lessons learned nearly a decade ago in the object database space.

-Robert

It’s been said, “necessity is the mother of all invention”. I see this NoSQL “movement” as innovation driven by necessity.

The necessity stems from the fact that in the last decade, data has grown and continues to grow out of bounds, the internet has brought unprecedented concurrency, business value has driven software model complexity.

RDB’s are runtime relationship execution engines. Even though their called “relational”, they don’t actually store relations. They store descrete data and then at runtime the descrete data is “related” by performing set based operations. That was all well and good when you were dealing with 10′s of thousands of records and 20 tables. However today lots of systems are dealing with millions of objects and 100′s of classes with inheritance, recursive relationships, containment, polymorphism, etc. It’s not hard to imagine why the JOIN operation is having issues keeping up with near real-time requests in the face of these realities.

So, invention or ( existing alternate technologies – i.e. ODB’s ) which help to deal with this new reality are what is represented by the spirit of NoSQL. In the end, it just comes down to using the right tool for the job. RDB’s are still fine for the majority of applications, but when you are trying to build LinkedIn, Network Management, Protein-Protein analysis, Fuel flight path optimization, etc etc … these things need a better tool.

In some cases a MongoDB is the right tool and in other the Versant object database is the right tool and in other cases something else.

As software engineers we all need to become familiar with our choices and use the right tool for the job.

-Robert

Neither are “NoSQL” databases a general-purpose replacement for relational databases (the tone of your post seems to imply that, sorry if I got that wrong), nor have object databases “missed the boat”.

They can’t be a general-purpose “replacement” for relational databases because they don’t do the same thing, and they don’t want to, thats what its about. They want to choose different priorities than relational databases that have their strenghts and weaknesses elsewhere.

It’s also interesting how you:

1) seem to imply that using a relational database means an impedance mismatch per-se

and

2) that you don’t see an impedance mismatch between all the NoSQL databases (except object databases) and OO code. An object database is the only database that lets you store objects without any mismatch.

When you use relational data as relational data in your application, there is no impedance mismatch.

There are surely many reasons why object databases did not get as widespread acceptance as relational databases but discussing them here would go a bit too far. Object databases are still strong in their particular fields, mostly embedded systems. There is nothing easier than a small footprint object database on an embedded system to persist your objects when you’re programming in an OO language on such a device.

If I may link to a nice post by a core couchdb contributor about what NoSQL is about: http://blog.couch.io/post/511008668/nosql-is-about

You may just be overly enthusiastic over your recent findings but the new databases just mean more alternatives and thats a good thing. More alternatives you can choose from when you’re looking for the storage that best fits your usecase and data requirements of a particular application or even just a part of a particular application (polyglot persistence anyone?). Each of these databases have their own set of (different) characteristics that make them suitable for some tasks and not for others.

All this impedance mismatch talk is nice but at the end of the day its nothing more than transforming/moving data between different representations, sometimes its more difficult, sometimes less. Relational to OO is surely not easy. Documents to OO may be easier, it looks like it, but no mismatch at all? I dont think so. Transforming data between different representations is something we do all the day in all kinds of different ways in IT. If you can avoid it sometimes or make it easier, good.

Using an RDBMS is not “going back”. You should just make sure that it is the right tool for the job, as always. If you’re not aware yet of the *strenghts* of relational databases you should spent some time to learn them. Otherwise you may find yourself using some NoSQL database where a relational database would be the much better fit (yes, there are many such cases). Not everything is better with the new shiny databases

Just relax and enjoy the new choices. Don’t exchange one hammer for the other. Put them all into your toolbox.