<acronym id="uye6a"><small id="uye6a"></small></acronym>
<acronym id="uye6a"></acronym>
<acronym id="uye6a"><center id="uye6a"></center></acronym>
<acronym id="uye6a"></acronym>
Showing posts with label RDBMS. Show all posts
Showing posts with label RDBMS. Show all posts

Friday, March 5, 2010

NoSQL Is Not SQL And That’s A Problem

I do recognize the thrust behind the NoSQL movement. While some are announcing an end of era for MySQL and memcached others are questioning the arguments behind Cassandra’s OLTP claims and scalability and universal applicability of NoSQL. It is great to see innovative data persistence and access solutions that challenges the long lasting legacy of RDBMS. Competition between HBase and Cassandra is heating up. Amazon now supports a variety of consistency models on EC2.

However none of the NoSQL solutions solve a fundamental underlying problem – a developer upfront has to pick persistence, consistency, and access options for an application.

I would argue that RDBMS has been popular for the last 30 years because of ubiquitous SQL. Whenever the developers wanted to design an application they put an RDBMS underneath and used SQL from all possible layers. Over a period of time the RDBMS grew in functions and features such as binary storage, faster access, clusters etc. and the applications reaped these benefits.

I still remember the days where you had to use a rule-based optimizer to teach the database how best to execute the query. These days the cost-based optimizers can find the best plan for a SQL statement to take guess work out of the equation. This evolution teaches us an important lesson. The application developers and to some extent even the database developers should not have to learn the underlying data access and optimization techniques. They should expect an abstraction that allows them to consume data where consistency and persistence are optimized based on the application needs and the content being persisted.

SQL did a great job as a non-procedural language (what to do) against many past and current procedural languages (how to do). SQL did not solve the problem of staying independent of the schema. The developers did have to learn how to model the data. When I first saw schema-less data stores I thought we would finally solve the age-old problem of making an upfront decision of how data is organized. We did solve this problem but we introduced a new problem - lack of ubiquitous access and consistency options for schema-less data stores. Each of these data stores came with its own set of access API that are not necessarily complicated but uniquely tailored to address parts of the mighty CAP theorem. Some solutions even went further and optimized on specific consistencies such as eventually consistency, weak consistency etc.

I am always in favor of giving more options to the developers. It’s usually a good thing. However what worries me about NoSQL is that it is not SQL. There isn’t simply enough push for ubiquitous and universal design time abstractions. The runtime is certainly getting better, cheaper, faster but it is directly being pushed to the developers skipping a whole lot of layers in between. Google designed BigTable and MapReduce. Facebook took the best of BigTable and Dynamo to design Cassandra, and Twitter wanted scripting against programming on Hadoop and hence designed Pig. These vendors spent significant time and resources for one reason – to make their applications run faster and better. What about the rest of the world? Not all applications share the same characteristics as Facebook and Twitter and certainly enterprise software is quite different.

I would like to throw out a challenge. Design a data store that has ubiquitous interface for the application developers and is independent of consistency models, upfront data modeling (schema), and access algorithms. As a developer you start storing, accessing, and manipulating the information treating everything underneath as a service. As a data store provider you would gather upstream application and content metadata to configure, optimize, and localize your data store to provide ubiquitous experience to the developers. As an ecosystem partner you would plug-in your hot-swappable modules into the data stores that are designed to meet the specific data access and optimization needs of the applications.

Are you up for the challenge?

Thursday, September 6, 2007

Are RDBMS obsolete?

Today Slashdot has picked up a storycolumn-oriented databases. The story claims that one size fits all approach does not work well for the current data warehousing requirements and that the organizations should explore other options beyond legacy RDBMS. The post says "Hence, my prediction is that column stores will take over the warehouse market over time, completely displacing row stores."

The fundamental assumption here is that somehow the data warehousing solutions are drastically different than OLTP ones and that's why has different storage, or I should say access, needs. What the post is missing is that many modern OLTP applications require real time analytics side-by-side and cannot really depend upon a separate data warehousing. The technology such as in-memory databases and materialized views that run on top of OLTP RDBMS make it feasible for an application provider to just have one hybrid system - OLTP or data warehousing, whatever you want to call it. This was obviously not the case few years back and you could get shot if you propose to run your analytics on a production (OLTP) database. I do believe that there is a need for special purpose databases that are different in architecture for very specific kind of applications but RDBMS is far from being obsolete. I heard the similar arguments in the past when object oriented database vendors claimed that RDBMS would become obsolete when people would switch over to object-oriented programming languages. Deja vu all over again!
<acronym id="uye6a"><small id="uye6a"></small></acronym>
<acronym id="uye6a"></acronym>
<acronym id="uye6a"><center id="uye6a"></center></acronym>
<acronym id="uye6a"></acronym>