Guest post by Let’s say you’ve decided to set up a website or an application. You’ll obviously need something to manage the data. Yes, that’s right, a database. So, what is it going to be? MySQL, MS-SQL, Oracle or PostgreSQL? After all, nothing can be as amazing as a good old RDBMS that employs SQL to manage the data.Well, allow me to introduce to you an entirely unique and unconventional Database model – NoSQL.
NoSQL has been around well before SQL.
Also there is this talk.
http://www.youtube.com/watch?v=qI_g07C_Q5I
Where he said he remembered a time before SQL.
Most of these databases are key value stores and have their advantages in some circumstances.
No doubt. At my job we work with something called Cache, which used to be known as Mumps:
http://en.wikipedia.org/wiki/MUMPS
http://robtweed.wordpress.com/2012/10/21/mumps-the-universal-nosql-…
http://vschart.com/compare/intersystems-cache/vs/mongodb
It has changed quite a lot over the years, but this software is still in heavy use by the healthcare industry. It is used in a number of products, notably GE Centricity Business.
I can’t help but notice the similarities between Mumps and Mongo… They are VERY similar in form and function (although obviously differ in many of the details).
Mumps was introduced in 1966…
Edited 2013-08-02 22:13 UTC
NoSQL databases were a boom for a time till many started to note that it didn’t solved much of the scalability issues, and it was just on pair with traditional SQL Databases.
Edited 2013-08-02 19:00 UTC
That totally depends on the needs of the application.
It’s easier to scale something like Redis than to scale a SQL-server.
But that doesn’t mean you need to rely on just one.
PostgreSQL has a key value store called hStore and newer version have a JSON-type and also Foreigh Data Wrappers that can talk to other SQL or NoSQL or flat files or webclients, DNS-clients, whatever you want to create code for.
It’s easier to scale something like Redis than to scale a SQL-server.
That depends of you definition of scale.
True. If you are trying to scale up read performance and you do not have a write bottleneck – there is little inherent advantage to the noSQL approach. Generally speaking, either approach can scale out reads rather well, and traditional relational databases have tremendous advantages when it comes to querying flexibility.
Of course if you have that particular problem consider yourself lucky
On the other hand, if you are primarily write bound, can plan your data model so that you do not need the flexibility SQL offers, and can live with the consistency tradeoffs, noSQL approaches have significant advantages.
In my opinion it isn’t a matter of SQL vs noSQL, it is a matter of ACID vs BASE (eventual consistency) when the discussion is about scaling…
https://en.wikipedia.org/wiki/Eventual_consistency
https://en.wikipedia.org/wiki/CAP_theorem
I would add that, in my opinion, if your problem can be adequately handled by 1 or 2 high powered servers you are probably better off with a traditional RDBMS and all the benefits of ACID compliance that come with it.
NoSQL makes sense when:
1. Your problem is so simple and so small that it doesn’t actually matter. Some developers like the key-value approach just to avoid having to deal with a traditional RDBMS complexities. Schema-less datastores are nice and easy for developers who want to model their data in their application layer. If this is you go for it, you will likely learn a lot on the way – and if your problem set grows or evolves you will learn all the bad stuff about noSQL too… I’m not saying I think this is a “good” reason to use noSQL, I just think it is very useful to learn by doing, even if you discover it was a bad idea along the way…
2. Your problem is really big. You have a absolutely huge dataset that requires ALOT of write throughput and you only need to query it in very specific ways. If you _really_ understand your problem well and can live with some of the tradeoffs brought about in eventual consistency models, noSQL can make your life easier (and dramatically reduce your maintenance and hardware costs).
Most real world problems are somewhere in the middle of those two extremes… All I can say is you don’t really appreciate the benefits of an ACID compliant RDBMS until you discover you need them, usually at the point you are too far along to do anything about it
Tread carefully…
Eh, NoSQL and RDBMS’s solve different problems and it’s not only about scalability.
If your data is relational then an RDBMS is the best choice but for data that isn’t relational (and a lot of data isn’t) you might want to look at NoSQL. At least it might reduce the chance that you use an RDBMS as a glorified flat-file storage…
Assess the tools available to you and use the right one for the job. If you’re comfortable with SQL then that’s no excuse to ignore NoSQL methods.
IMO SQL databases are heavily overused on the web. If you don’t need to do highly selective data cherry-picking (such as filtering of a result set), or mashing of two sets of data together (analytics), then often a flat data store is simpler, faster and more reliable. For the web, you don’t need an SQL database to serve static content, and where you need to index and search content you have offline systems like Syphinx that give you a database for searching but you can keep the fast static caches for the content. (i.e. use flat files for what they’re good for and SQL for what it’s good for)
Because I didn’t like the downsides of SQL databases for web content (portability / maintenance / security / setup&config time) I created a forum system that has no database, just RSS feeds — each discussion thread is itself an RSS feed. This means that setup is a matter of seconds (unzip and run) and the data is portable, easy to parse, transform, manage, convert and generally process without the need of specialised / my software. Google for NoNonsense Forum should you be interested.Google for NoNonsense Forum should you be interested.
The benefits for my use case made NoSQL the right choice, but I wouldn’t think twice about using an SQL database if a project needed those kind of requirements. My point is: learn what’s possible with each approach (benefits / drawbacks) and use each to its full potential, and don’t be afraid of mixing methods!
Many now use a version control system to store their versioned flat files.
Some Wiki implementations for example store and retrieve directly from git.
I’ve done it as a traditional database, a key/value store and an ORM, where I really didn’t care what the DB looked like. Honestly, the best approach is to either ORM the dataset (I used Entity Framework code first in a number of projects, doing so, the database structure became competely opaque) or use tables for static data and K/V for dynamic data. The biggest issue with K/V is reporting on the data. If a reporting solution is critical (e.g. Sales, stats etc) then K/V really falls down. Pivoting giant chunks of data is no real fun. Neither is field bloat in traditional tabular databases, so the happy middle ground works well.
I find that in many use cases SQL is overkill where a document db will do, plus the flexibility afforded by storing straight JSON makes rapid prototyping a breeze.
For a while we had square peg round hole situations where everything was shoved into a relational model, which is where I think the rapid uptake of NoSQL databases came from.
For Redis, since stuff like ram became cheap, ensuring low latency by just using a K/V store in memory works pretty well too.
At massive scales, the least path of resistance to scale is usually the one that prevails.
There was IMS:
http://en.wikipedia.org/wiki/IBM_Information_Management_System
And don’t forget Lotus Domino either.
That wasn’t before SQL.
Many excellent points but one nobody has drawn attention to:
Calling NoSQL “a type of database” is about as accurate as calling atheism “a religion”.
I always hate seeing people lumping key-value stores, hierarchical databases, document-oriented databases, and everything else under the sun that isn’t SQL-based under one term. It smacks of “as long as it’s not SQL-based, it suits my needs” thinking.
Edited 2013-08-03 07:46 UTC
Well, it does seem like quite a few atheists practice it with an almost religious zeal and elitism.
Why? That’s what they are. Relational, object-oriented, key-value, hierarchical etc etc are all different types of databases.
What do those atheist practice? Not stamp collecting?
No argument there. The presence of personality attributes like zeal and elitism is orthogonal to the presence or absence of any given set of religious beliefs.
That’s what I said. They’re different types of databases so it makes no sense to use the same term to describe “every type of database except SQL-based relational”.
Edited 2013-08-05 12:54 UTC
Atheism is a religion in the same way that not smoking cigarettes is an addiction.