SQL Zone is brought to you in partnership with:

I am a software engineer at Google on the Android project and the creator of the Java testing framework TestNG. When I'm not updating this weblog with various software-related posts or speaking at conferences, I am busy snowboarding, playing squash, tennis, golf or volleyball or scuba diving. Cedric is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

NoSQL explained correctly (finally)

03.31.2011
| 11479 views |
  • submit to reddit

Now here is a definition of “NoSQL” that I can agree with:

A very interesting write-up with one little oversight: you’re wrong.

I am part of a large program to write a NoSQL database for military applications. It’s not a backlash against paying Oracle (the DoD has a blanket license for Oracle installations) or a philosophical stance by the hippies in the defense arena; it’s the fact that RDBMSs are built in a different space in the CAP trades (see this article).

Google, Amazon, Facebook, and DARPA all recognized that when you scale systems large enough, you can never put enough iron in one place to get the job done (and you wouldn’t want to, to prevent a single point of failure). Once you accept that you have a distributed system, you need to give up consistency or availability, which the fundamental transactionality of traditional RDBMSs cannot abide. Based on the realization that something fundamentally different needed to be built, a lot of Very Smart People tackled the problem in a variety of different ways, making different trades along the way. Eventually, we all started getting together and trading ideas, and we realized that we needed some moniker to call all of these different databases that were not the traditional relational databases. The NoSQL name was coined more along the lines of “anything outside of the SQL part of the Venn diagram” rather than “opposed to SQL”.

The NoSQL databases are a pragmatic response to growing scale of databases and the falling prices of commodity hardware. It’s not a noble counterculture movement (although it does attract the sort that have a great deal of mental flexibility), it’s just a way to get business done cheaper.


This is a comment to this article.

The commenter is dead on. There is nothing (well, very little) wrong with SQL. It’s an old language, but it’s still the best language that we have today when we need to retrieve data stored in tables. Nothing comes even close. And as a matter of fact, NoSQL products have typically very crippled query functionalities compared to SQL.

This is not to say that NoSQL is useless, but as the commenter correctly points out, NoSQL is just an extension of the current model to meet certain specific needs.

I bet that in ten years from now, we will still have a majority of SQL based systems complemented by a small portion of NoSQL frameworks.

References
Published at DZone with permission of Cedric Beust, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Dominique De Vito replied on Thu, 2011/03/31 - 7:50am

IMHO, NoSQL databases are disguised object databases.
NoSQL products sound like a kind of object databases:
- Column-oriented stores: column-oriented storage mode for object databases
- Document databases: normal storage mode of object databases
- Graph databases: distributed (fine-grained) object databases
- Key-value stores: BLOB-like storage mode of object databases

While I have personally brought closer NoSQL bases and OO bases, I have had little surprise reading the post NoSQL or NoJoin? This post suggests that "the NoSQL solutions should really be called NoJoin because they are mostly defined by avoidance of the join operation".
My point of view makes sense, again, as object databases are not join-friendly, just like NoSQL too.

To be more precise, NoSQL databases are dynamic object databases (as the former are very often schemaless databases).

 

The point with my disguised object database theory is twofold:

- first, it's about to say NoSQL databases are not a completely new kind of database! Indeed, object databases are very close to NoSQL databases, when one think in terms of data model and relaxed constraints.

- secondly, while some developers have hard time to classify this new kind of databases, to think about them, I thought it's quite valuable to imagine them as (disguised) object databases, with relaxed constraints! Then, developers get a known mind model to deal with this new kind of databases.
 

Valdemar Júnior replied on Thu, 2011/03/31 - 7:58am

It's a excelent point of view: "This is not to say that NoSQL is useless, but as the commenter correctly points out, NoSQL is just an extension of the current model to meet certain specific needs." I'll read more about noSQL databases, but there are a lot of sources, blogs and frameworks to do it. I'd like to have more time to do it, but I'll try. Congrats by the excellent post.

Dmitriy Setrakyan replied on Thu, 2011/03/31 - 1:56pm

I bet that in ten years from now, we will still have a majority of SQL based systems complemented by a small portion of NoSQL frameworks.

Could not agree more.

--Dmitriy
www.gridgain.com

Loren Kratzke replied on Thu, 2011/03/31 - 11:19pm

I am what you might call old fashioned in the nosql sense, however I how no love for sql beyond its raw power. This is the single best argument that I have heard. I am swayed by this argument.

My thoughts are that yes, you are giving up one thing but gaining another. Weigh the difference and factor the exponentials and you are there. But only when talking clouds. When it comes to hard core business logic, raw sql will rule just as lower level languages currently rule hardware. Gotta run on something.

It will take business requirements to raise to the level of the cloud for sql to be considered as C and asm are today - tools to build the platform as opposed to the solution.

Shai Levi replied on Sun, 2011/04/03 - 12:43am

Cloud based Scalability and High-Availability for SQL will get more and more into the main stream in the comming years. Xeround (http://xeround.com) is one example and there are several more.

Shoaib Almas replied on Sat, 2012/08/25 - 5:58am

The end result in 10 years (less I hope) is some more very smart people figure out how to make RDBMS scale as well as the NoSQL solutions, to make them function in a distributed fashion which does not have a single point of failure. I hope these smart people are working on this right now, as I am desperate need for it.

Java Forum

Carla Brian replied on Mon, 2012/07/30 - 6:33pm

Thanks for sharing this one. I am new to this. At least I have a simple background about this one. Good thing I stumbled upon in this post. - Mercy Ministries

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.