Skip to content

On the evolution of “non-relational databases”.

by Roberto V. Zicari on November 25, 2009

What is the opinion of the relational database community on the so called NoSQL?
I asked Giuseppe Maxia, MySQL Community Team Lead. Giuseppe is a system analyst with 20 years of IT experience, he has worked as a database consultant and designer for several years.

RVZ

RVZ: Why NoSQL databases?

Giuseppe Maxia:
The evolution of non-relational databases (NRDB: I prefer this name to no-SQL) is rightfully puzzling. Their usefulness and efficiency are difficult to quantify in general terms and a comparison to relational database system is far to be objective.
There are cases where you can easily demonstrate that NRDB scale better than their relational counterpart. But only with a lot of ifs and buts.
Basically, the highest traffic web sites such as Facebook or Digg can’t live with a database alone. There are two factors that limit their simple adoption of a relational schema:

1) the high traffic requires that the same values are fetched several times from the database. This requirement becomes a bottleneck for data. To overcome this limitation, there are auxiliary servers, such as memcached, which keep the most requested items in a fast network of in-memory storage systems. For all practical purposes, this technology converts the majority of the data into a series of key-value records.

2) when a site reaches a high number of registered users (or a high numbers of items to trade), a single server can’t contain the database anymore. There is no way of fitting 300 million Facebook users into a single server. Thus, they do “sharding”, i.e. a logical split of the data into tables, databases, and remote servers. With such organization, the relational model is conceptually broken, and the data looks more and more like a collection of key-value sets.

In both the above cases, you see that there is a trend to converting the relational data into key-values. The administrators of such sites start asking themselves why they keep bearing the burden of a relational database overhead since they can’t have its main advantage, namely the precise and mathematically proven organization of data. In this scenario, the key-value databases are becoming popular among those users who are forced to break relational integrity.

Add to it the large number of developers who never managed to understand the relational model, and you can explain why the non-relational database systems are gaining momentum. The drawback is that NRDB can’t retain meaningful metadata information, or, if they do, they achieve it through internal extension to the key-value model that is not easily exportable.
The immediate effect of the above points is that more and more systems that are based on non relational storage are now entirely depending on the application that uses them, a situation that brings us back to the COBOL times. This kind of storage is convenient only for either simple applications or for organizations that can afford to employ a large number of developers to cope with the increased complexity of the applications. For the rest of us, relational databases are still the best way of storing data.

Cheers

Giuseppe

From → Uncategorized

One Comment Leave one →
  1. I'd like to add two things:

    1) IMO, "NoSQL" is more than being merely non-relational. It is true that being non-relational is a defining characteristic of "NoSQL", but a very import additional characteristic that is present in all DBMS-es I heard of that are labelled "NoSQL", is the ability to participate in a cluster – i.e. these solutions are all inherently designed to build distributed datastores.

    2) It's not just a matter of IO bottlenecks in retrieving data, or volume constraints in storing it in a single instance. The distributed architecture sort of naturally calls for parallel query execution, which is very important from a performance perspective.

    kind regards,

    Roland Bouman

Leave a comment to Roland Bouman Cancel reply

Note: HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS