NoSQL – Not Only SQL – to co-exist with SQL
NoSQL – as the name itself suggests – covers all forms of data management solutions that are not “strictly” relational databases. NoSQL is defined as the “next generation databases mostly addressing the points of being non-relational, distributed, open-source and horizontal scalable” (http://nosql-database.org/).
The key characteristics that NoSQL propounds are: schemaless, simple API, easy replication support, eventually consistent (as against ACID properties supported by traditional relational databases), and a ability to handle huge amount of data – and thus serve as modern web-scale databases supporting the growing needs of Internet and web 2.0.
NoSQL was the name given to an open source non-SQL RDBMS created in 1998. Interestingly their website states “NoSQL has been around for more than a decade now and it has nothing to do with the newborn NoSQL Movement. NoSQL is a relational database to all effects and just does intentionally not use SQL as a query language, the newcomer is a concept, which departs from the relational model altogether and it should therefore have been called more appropriately NoREL, or something to that effect”.
The new generation companies – Google, Amazon, Facebook etc. – found relational databases inadequate and expensive for their purposes. Production implementations of NoSQL, as expected, are Google’s BigTable, Amazon’s Dynamo, Cassandra used by Facebook, Twitter and Digg. The need for solutions that are not expensive and fitted their specific purpose is what drove the development of these non-relational data storage (also referred to as “structured storage”).
This NOSQL movement begun in early 2009, while most of the implementations they refer to – like Object databases, XML databases – have been in existence much earlier. Probably because of the name “No SQL”, there are hot debates going on about NoSQL vs SQL, NoSQL vs Relational – more on the lines of Windows vs Linux or even Mainframe vs J2EE – as if it is necessary for an enterprise to choose NoSQL at the cost of relational.
As in most of these new technology trends, NoSQL – as in “no Relational” – may work for new and SMB enterprises but the same is not true for large enterprises where relational databases form the backbone.
With the advent of NoSQL, the original tendency was to take a dig at Relational databases and everything associated with it – and such enthusiasts conveniently ignored the fact that Relational has had a strong foundation and had effectively served for three decades at least – predicting the death of SQL. And the relational / SQL fans reacted highlighting the benefits of Relational and pinpointing the weaknesses of the NoSQL options including issues relational to handling ad hoc queries and reporting. Now the NoSQL community clarifies that NoSQL is not anti-RDBMS and the term itself is misleading and should be consider “NOSQL” expanding to “Not Only SQL”.
The heavily growing Internet based applications and the paradigm shift brought by web 2.0, is pushing enterprises to look beyond relational databases as they are no longer adequate and turn out expensive proposition when used in web 2.0 type of load. The success of current NOSQL implementations and the promise of less expensive, scaling-out, open-source data storage and the wide variety of products currently available makes NOSQL an interesting proposition to the enterprises.
Co-existence of relational and NOSQL is what the future seems to hold – not just because Relational has been long and cannot be replaced, but because Relational and NOSQL are different concepts, and each have their own set of strengths and weaknesses and can effectively complement each other.
The choice of whether to use NOSQL or not should be driven more by the appropriateness of the concept to a particular application rather than the sheer enthusiasm to use new technology. What NOSQL effectively does is to give the choice of not using Relational databases and choose an alternative that is more suitable for your application.
I plan to cover the various categories of NoSQL and also dwell a bit deeper into why Relational is not suitable for all workloads in the later blogs. In the meantime, if there are any experiences you have in using NoSQL and any attempts at moving from relational to these new database, please share.