Communications of the ACM
Why Enterprises Are Uninterested in NoSQL
According to a recent ReadWriteWeb blog post by Audrey Watters, 44% of enterprise users questioned had never heard of NoSQL and an additional 17% had no interest. So why are 61% of enterprise users either ignorant about or uninterested in NoSQL? This post contains my two cents worth on the topic.
At a recent trade show I attended, which highlighted NoSQL engines, there were many Web developers, mostly from startups. However, I was struck by the absence of enterprise users. Hence, my (totally unscientific) experience confirms the basic point of the above blog post.
Moreover, in my experience, most information among enterprise users occurs by word of mouth. Hence, if they don’t hear about something, it is because their professional network does not pass the word along. In other words, an interested enterprise professional generates additional interest. Non-interest generates the behavior seen in the above blog post. So why is enterprise interest lacking?
To get more color on the situation, I contacted a very senior technical guru at a large enterprise who is responsible for looking at new database management system (DBMS) technology for his company. I asked him how interested he was in NoSQL and, in effect, how interested his company was. He reported “no interest.” I asked him why.
He first said that the vast majority of his company’s applications are classifiable as online transaction processing (OLTP) where there are frequent small updates to a database of structured records or data warehouses/data marts which assemble historical business data for ad-hoc query by analysts. Although there are some other applications around the “edges,” such as document management, these are not considered important.
He then made one comment about OLTP, one comment about warehouses, and one general comment. These follow.
No ACID Equals No Interest
Much of the OLTP data kept by this company is mission critical. Screwing it up causes people to lose their jobs. In his world, ACID is the gold standard for update to shared data sets. Any system that does not support real transactions is considered a nonstarter in his OLTP environment.
Even if a data set can get by with single-record transactions now (a common feature of NoSQL DBMSs), he is unwilling to guarantee that it will never need multi-record transactions in the future. Put differently, his company assumes that ACID may be required in the future for any OLTP data set, and nixes non-ACID systems.
A Low-Level Query Language is Death
Data warehouses are subject to frequent ad-hoc queries like “Tell me whether pet rocks are selling better than Barbie dolls in the south?” Ted Codd’s pioneering paper, "A Relational Model of Data for Large Shared Data Banks," in 1970 advocated a user interface whereby one stated what is required and not how to fetch it from disk. In the subsequent 40 years of DBMS activity, high-level languages, like SQL, have been shown to offer ease of programming for such ad-hoc data warehouse inquiries. My enterprise guru’s company is rarely interested in the algorithmic record-at-a-time interfaces seen in most NoSQL products, as they are seen as a throwback to the days of IMS and CODASYL.
NoSQL Means No Standards
His company has a large number of databases (apparently more than 10,000), and the company is clearly concerned with the number of different kinds of interfaces their application programmers have to learn. Hence, standards are important to a large enterprise.
Seemingly, there are north of 50 NoSQL engines, each with a different user interface. Most have a data model, which is unique to that system, along with a one-off, record-at-a-time user interface. My enterprise guru was very concerned with the proliferation of such one-offs. In contrast, SQL offers a standard environment.
I want to close this blog post with a single comment: “Those who do not understand the lessons from previous generation systems are doomed to repeat their mistakes.” In other words, “Stand on the shoulders of those who came before you, not on their toes.”
Disclosure: Michael Stonebraker is associated with four startups that are either producers or consumers of database technology. Hence, his opinions should be considered in this light.
Comments
Antonio Vieiro
Google Percolator and CloudTPS are examples of NoSQL with ACID support. Claiming that NoSQL implies no ACID capabilities is just plain wrong.
Finally enterprises uninterested in new technologies are doomed to failure. You just can't remain competive if you ignore technology advances (not trends) nowadays.
K. Babu
I have not worked with NoSQL system systems other than to become aware of them in recent years. However, because of my networking equipment background, I can say that it does seem possible that NoSQL databases would do well in "data plane" section of the database systems, whereas SQL databases would be required -- ACID test -- in the "control plane" section of database systems. (In networking equipment software, data plane logic needs to be blindingly fast, say 100 Gbit/s, in order not to bring down transmission efficiency; control plane software, on the other hand, does not have to deal with such speeds). In other words, where performance is a sole criterion, NoSQL databases may have an edge; however, in the overall combination system, we have the obligation to ensure ACID property.
Anonymous
We'd better look back on the discussion now.
Enterprise Organisations do have more and more interests on NoSQL products.
Anonymous
Any serious data processing in RDBMSs is done at record, not set level. Oracle's PL/SQL stands for Programming Language SQL, and it operates on cursors, which basically proceduralize SQL data sets i.e. flatten them out into records that are processed one at the time.
Lack of ACID is theoretical disadvantage ( as someone said - apps abuse ACID all the time ).
I would agree that lack of more or less standard query language is a problem for NoSQL offerings. Some NoSQL products offer limited query capabilities ( Hive, Pig ), but it is all far below what SQL gives.
Ranko Mosic, CEO
Lotus CSP
www.lotus.in.rs
Displaying comments 11 - 14 of 14 in total