What is NoSQL, and why do you need it?

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.

Topics: Data Management, Cloud

Gery Menegaz

About Gery Menegaz

Gery Menegaz is a Chief Architect for IBM with more than 20 years supporting technologies in the financial, medical, pharmaceutical, insurance, legal and education sectors. My Full-Time Employer is IBM. I write as a freelancer for ZDNet.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Any simple working examples?

    Would be interesting to know more about this, not sure I understand how it works. Especially with regards to reporting capabilities. For example, the document store, does this take the view that the contents of the documents are less important than the number of documents?
    Is there a simple example of this? (e.g the equivalent to the student database example usually given for relational databases)
    • SumAll

      What SumAll is doing with MongoDB is a good case example. Check them both out and let me know if you want more info.

      Thanks for your comment.
  • “SQL” ≠ “Relational”

    Does not using SQL necessarily mean the database is nonrelational? SQL is in fact quite a clumsy notation for dealing with relational databases: look at relational algebra and relational calculus for mathematical notations that provide a more uniform treatment of concepts (e.g. relations as first-class objects). Also there’s nothing in the mathematical notation that requires a fixed schema.
  • Neither the example used, nor the explanations used, are useful...

    since, I can easily develop a coupon application, which dynamically grows, and makes access to any and all coupons, with ease, and without worrying about huge storage needs and without worrying about huge storage manipulation. In fact, I did design such a coupon system (still have it in my computer, but never implemented), and storage and manipulation of it, was the least of my problems. Most coupons will become extinct within a short period of time, and can be renewed for another sales cycle, or can just be dropped altogether.

    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...

    Alas! The article is greatly lacking in terms of explaining the what, how or why. It seems quite disjoint - with a number of points that it relates to. Sorry to say this.

    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
  • Where was the editor?

    A very poor article, both with respect to the content and the overall quality of the written article itself. For example, how did the quote: "a database which does not adhering to the traditional" make to through to the final published copy?

    ZDNet should be aspiring to a higher standard than this.
  • Hmm, so what *is* NoSQL

    According to this article, NoSQL is exactly what the term claims to be. Everything what SQL isn't. I.e. remove all the features from "ordinary" SQL / relational databases and be left with what? A pile of bits and bytes? That's NoSQL?

    The NoSQL vs. SQL debate has been going on for a while, but if there is one consensus at all, then it's the fact that NoSQL is a very poor taxonomy for a set of ideas that are maybe not relational.
    Lukas Eder