More on the Pros/Cons of SQL and NoSQL
More on the Pros/Cons of SQL and NoSQL
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
Is NoSQL just a controversial buzzword? Could you imagaine if the term 'Object Orientated' didn't exist and instead architectures based on concepts such as encapsulation, polymorphism and inhertiance were referred to as 'NoProcedural'? Could you imagine if .net was called 'NoJava'? Leinster was called 'NoMunster'?
Well controversial name aside, a good way to appreciate the hype about NoSQL is to consider scalability - the classical non-functional architectural concern. In a classical OLTP architecture, when load increases and your JVM is under pressure, you need to scale. You have two choices:
- vertical scaling - adding more CPU power to your JVM
- horizontal scaling - adding more JVMs (usally one more boxes)
The leading relational databases will scale horizontally. But only by so much. To get around this an architect usually will consider:
- Scaling vertically - putting the database on the best hardware that can be afforded
- Partitioning out legacy data and thus reduce things like the size of index tables. This will boost performance and put less pressure on the need to scale
- Remove the amount of pressure on the database by caching more in the business tier
- Pay a DBA a lot of money!
But what if you just run out of all possible database optimisations options and you have to scale horizontally? Not just to a few machines but to a few hundred if not thousand. This is where NoSQL architectures become relevant.
With a NoSQL database there is no strict schema. Everything is effectively collapsed into one very fat table - a bit like an old skool flat file, but where each row stores a huge amout of data. So, instead of having a table for Users and a table for Activities (representing User's activities), you put all the User information together in one fat row. This means there are no joins across tables. It also means there is a lot of data redundancy which means more storage space required. In addition, more computational power will be needed for writes. But because data that is used together is located at the very same place - within the same row - it means no complex joins and hence it is easier to scale. The computational requirement for reads is also less. So reads can go faster.
Another advantage of NoSQL databases is derived from the freedom that comes with not having to be tied to strict schema. You know that headache where a change to a data model can cause big problems? Well since there is no strict schema with NoSQL - this problem does not exist. This makes the architecture more flexible and more extensible.
Right now, it's fair to say NoSQL is only relevant in the minority of architectures. But could this be another case of technical innovation driving business innovation as we have seen with smart phones? There wasn't a need for smart phones but the technical innovation provided business opportunities. I think the same could happen with NoSQL Architectures.
Take a step back from Computer Science and just think Science. Science used to be hypotheisis centric, now it is becoming more and more data centric. CERN, genome sequencing, climate change analysis - all involve tonnes and tonnes of data. Surely NoSQL architectures allied with searching technologies such as MapReduce / Hadoop will open up new ways to do Science?
So any disadvantages with NoSQL architectures? Well it's still an immature technology. Indexing, Security models are just not as sophisticated as they are with classical relational databases. And because most of it is coming from the open source community the support is not as good as it is for relational databases. So don't throw out your SQL just yet!
Published at DZone with permission of Alex Staveley , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.