Moving from SQL to NoSQL
Are you thinking on moving your database from a SQL implementation to a NoSQL one ?
Sometimes when you decide to move to a different approach lots of doubts pop out of your mind, there are a couple of actions that can make your decision more solid and secure. I’ll try to provide some tips that would help you to choose the right NoSQL implementation.
When do you need to think about NoSQL ?
Often web application start by being implemented on top of MySQL, the one day your application got traction and performance issues start to be a real pain due to high load of read/write queries on your system.
At this point you have 2 choices:
- “Shard” your data to partition it across several sites
- Go for a licensed SQL DBMS or move to a NoSQL DBMS
NoSQL use cases
- Massive data volumes
- Extreme query load
- Schema mutation (often called as evolution)
NoSQL most popular pro’s
- Scalability and Elasticity (at low cost)
- High Availability
- Flexible schemas (semi-structured data)
- Distributed (easily)
- Low Cost
NOSQL most popular con’s
- Weak integrity models
- Consistency (called eventual consistency)
- Transactions (You can do it by code)
- Complex queries
- No standardization
- Messy access control (Some popular implementations already doing this)
Basically, NoSQL runs away from the ACID (atomicity, consistency, isolation, durability) terminology.
NoSQL most popular implementations
As every topic, there are come popular and trendy implementations of NoSQL: CouchDb, MongoDB , Cassandra, Memcache.
For a complete list, please refer to wikipedia.
Interesting to read articles/presentations on NoSQL.
- “NoSQL Databases – Part 1 – Landscape” at VineetGupta.com
- “Why Digg Digs Cassandra” by Om Malik at Gigaom
- “NoSQL at Twitter (NoSQL EU 2010)” by Kwvin Weil at Slideshare
- “NoSQL databases” by Marin Dimitrov at Slideshare
But the sky isn’t always blue, you should read the voices that are against NoSQL also:
So how do you choose the right NoSQL implementation ?
I must answer with the magic sentence: It depends!
You must choose you database storage system based on the problem you are trying to solve, but there is one thing that is universal to all of them, you have to make tests with more than one and only by making results analysis you will be able to take decisions, unless you are a guesser, i am not.
My advice is, choose your most common use cases and perform small proof of concepts, and only after having the numbers you should choose.