What is NoSQL, and why do you need it?
Summary: NoSQL is a whole new way of thinking about a database. Though NoSQL is not a relational database, the reality is that a relational database model may not be the best solution for all situations.
Imagine that you have coupons that you wanted to push to mobile customers that purchase a specific item. This is a customer facing system of engagement requires location data, purchase data, wallet data, and so on. You want to engage the mobile customer in real-time.
What you require is a very agile delivery system that is easily able to processes unstructured data. The system of engagement would need to be extremely dynamic.
A traditional database product would prefer more predictable, structured data. A relational database may require vertical and, sometimes horizontal expansion of servers, to expand as data or processing requirements grow.
An alternative, more cloud-friendly approach is to employ NoSQL.
The load is able to easily grow by distributing itself over lots of ordinary, and cheap, Intel-based servers. A NoSQL database is exactly the type of database that can handle the sort of unstructured, messy and unpredictable data that our system of engagement requires.
NoSQL is a whole new way of thinking about a database. NoSQL is not a relational database. The reality is that a relational database model may not be the best solution for all situations. The easiest way to think of NoSQL, is that of a database which does not adhering to the traditional relational database management system (RDMS) structure. Sometimes you will also see it revered to as 'not only SQL'.
It is not built on tables and does not employ SQL to manipulate data. It also may not provide full ACID (atomicity, consistency, isolation, durability) guarantees, but still has a distributed and fault tolerant architecture.
The NoSQL taxonomy supports key-value stores, document store, BigTable, and graph databases.
MongoDB, for example, uses a document model, which can be thought of as a row in a RDBMS. Documents, a set of fields (key-value pairs) map nicely to programming language data types. A MongoDB database holds a collection which is a set of documents. Embedded documents and arrays reduce need for joins, which is key for high performance and speed.
Why NoSQL? It's high performance with high availability, and offers rich query language and easy scalability.
NoSQL is gaining momentum, and is supported by Hadoop, MongoDB and others. The NoSQL Database site is a good reference for someone looking for more information.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Any simple working examples?
Is there a simple example of this? (e.g the equivalent to the student database example usually given for relational databases)
SumAll
Thanks for your comment.
“SQL” ≠ “Relational”
Neither the example used, nor the explanations used, are useful...
Also, from what was explained in the article, which wasn't much and basically very lacking, it sounds like, NoSql simply takes us back to the VSAM days and the flat file systems where, each file record can be directly accessed, via a key/value design. Not much different there. But, if NoSql is to be something that companies cannot absolutely do without, then, there needs to be a much better sales pitch than what I read above and hear all the time. Fact is that, most small and medium sized companies will never need NoSQL or "big data"; and even most large organizations can make do with high-scale SQL databases without having to delve into big-data/NoSQL structures.
Neither the example used, nor the explanations used, are useful...
NoSQL is a different (i.e non-conventional aka relational) approach to addressing different problems, such as what we commonly see these days - in the era of social applications, mobile, and of course web 2.x(?). In contrast to a more "structured" handling - and therefore processing - of information, this approach is built to deal with unstructured content (tweets or wall posts, for eg). It's inherent architecture, and characteristics are designed differently. Eventually Consistent, for one. Such as, for inherent distributed processing and more read-intensive than write-intensive.
Sure, so far, SQL (rather RDBMS) -based was the preferred (only?) choice. But the demands of today's social and cloud-based applications, needed new thinking. That's what NoSQL aims to address. Designing such a class of applications is possible - but, easily tend to increase in complexity, when you have to address the specific challenges involved with the scale of such systems. For eg. imagine replicating the data for 1000s of users (say, Twitter or Facebook) over a relational setup. Will it work. Sure. Is it the best/optimal solution? That will surely open up a big debate i'm sure :) In a sense, it's like comparing procedural coding to object-oriented coding. Both work - and can work well for whatever problem. But which is a wiser choice? it depends.
Here's a good overview and introduction to NoSQL: http://thetechnicalweb.blogspot.in/2011/05/building-scalable-web-applications-non.html
- saurabh