Maturing the NoSQL argument

Maturing the NoSQL argument

Summary: A system cannot mature its way out of a fundamentally wrong architectural choice. Companies as modern and data-focused as Facebook, Google, and Cloudera continue to make meaningful investments in SQL technologies.

SHARE:

Ryan Betts is CTO at VoltDB.

Recently Max Schireson, CEO of MongoDB, shared his thoughts on relational databases. His statements deserve a direct and frank opposing response. Let’s walk through the myths that Mr. Schireson promoted.

Myth One: SQL is old (and old is bad).

"The database market is in need of a big change. The technology that people typically use, the database layer, was designed in 1970 with a very different set of requirements in mind."

In reality, modern SQL systems have been designed and deployed over the last 10 years to address both large volume analytic workloads and high-performance transaction processing workloads. Modern columnar OLAP stores offer combinations of rich query semantics and impressive data ingest rates that document stores certainly can’t match.

Meanwhile, transaction-focused modern row stores can perform millions of SQL database transactions per second enabling sophisticated real-time analytics and decisions.

Myth Two: Relational systems are limited by their data model.

"The first rule of a relational database is that every row in a table has to have the same set of columns as every other row, which we didn't think reflected reality."

All popular SQL systems support document types. Many of these at performance and benchmark levels that can’t be matched by document stores. In fact, a major advantage of SQL is the abstraction-from-storage model. Unlike document stores that require navigation-based proprietary querying, relational stores provide a clean abstraction that allows optimization of queries and variations in storage as appropriate to the problem.

The relative ease with which vendors integrated document-oriented types into the relational model shows the strength of this abstraction.

Myth three: Relational systems are limited by their storage model.

"When you enter an order into a relational database, it doesn't go into something that just holds the order as is. The order header gets stored somewhere, each order line gets stored somewhere else, the address information gets stored somewhere else."

Modern relational systems employ storage algorithms appropriate to the application – even the "big vendors" that Mr. Schireson uses as his straw man. Relational systems combine in-memory, columnar, row-store, flash and different indexing techniques into scalable, high performance solutions. Why can they do this while document stores are often stuck with naïvely buffer-cached mmap’d update-in-place storage layers? Because relational systems appropriately abstract users from storage via SQL and cost-based query optimizers.

Myth Four: Relational is not agile.

"Now you want to build applications in a much more agile way and include much broader and more varied sets of data. You need to be able to maintain those applications without down time and deploy them into cloud-style infrastructures and service massive numbers of users."

High availability, fault tolerance, cloud-friendliness, and scaling concurrent users have nothing to do with the relational model. Conflating these concerns is misleading. HA and fault tolerance concern transactionality and replication. Cloud deployment is about distributed architecture, careful I/O scheduling and the performance budget for virtualization. Agility is about time to deployment and time to value. ACID programming models and familiar SQL tooling enables both.

Myth Five: All NoSQL needs is "more maturing."

"But [relational SQL systems are] more mature and they've got this tool and that tool and they've got the skillset — it's that maturity gap that we need to close."

Relational systems are more mature. Not just by age, but they are more mature architectures based on decades of research, market acceptance and user feedback. The results are robust, modern, distributed architectures that leverage decades of experience to advance the state of the art. The toolset around relational SQL systems is mature because of standardization – in direct contrast to proprietary document interfaces.

A system cannot mature its way out of a fundamentally wrong architectural choice. The market chooses relational SQL systems over document-oriented proprietary systems not for lack of choice but for rational reasons. Relational SQL stores replaced document navigation models decades ago.

Companies as modern and data-focused as Facebook, Google and Cloudera have made and continue to make meaningful investments in SQL technologies. These investments are driven by user demands for improved interactivity with data, integration with standard tooling interfaces, applicability of existing user training and knowledge, and the need for meaningful query optimization.

Topics: Big Data, CXO, Enterprise Software, Oracle

Ryan Betts

About Ryan Betts

Ryan Betts is CTO at VoltDB, the world’s fastest operational database, delivering high-speed data processing and real-time, in-memory analytics in a single database system.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • Agree wholeheartedly with this article

    The whole, "data has a fixed design, that's horrible!!!" argument is just the dumbest thing I've ever heard. Although this scenario does happen, SQL Server manages it nicely with its XML data type, and heck a key/pair table can manage it if you don't like XML.

    As to the storage method, I've been playing with FileStreams in SQL Server that mount as a Windows UNC share. I'd dearly love to see MongoDB try that!
    Mac_PC_FenceSitter
  • I do agree but...

    Sometimes you need the right tool to solve a particular problem and sometimes noSQL could be the right solution.

    I have found that a lot of developers do not fully understand the richness and power of SQL and therefore create applications that may not always perform as expected.

    With noSQL developers face the issues that SQL hide from them, performing joins, grouping data etc.

    Products like dbSpaces which allow both SQL and noSQL requests against relational and non-relational data sources allowing developers to have the best of both worlds.
    pjc158
  • What is the correct tool

    I am familiar with relational (SQL) and document stores. Both have advantages and it is a matter of using the correct tool for the application. What is overlooked: databases are typically the backend to an application. The application requirements should determine the database options not much ink spilled out of context. Beware that each type is excellent for some applications, will work decently for many other others, and is horrible for the rest. It is not X is always good or bad but X is best here, reasonable there, and miserable elsewhere.
    Linux_Lurker
    • Exactly

      best tool for the job isn't the same as the same too for every job.
      wright_is
  • MongoDB

    would be better off arguing SPECIFIC use cases where their product would do better instead of making a blanket statement. Generalizations are easy to dismiss, as this article expertly does.

    Now if they could point to something specific and say "Our solution works better than SQL in this instance' they could probably persuade some people.
    luke mayson
  • The future is relational

    The relational model is one of the most elegant, sophisticated, simple and effective methods ever in invented in computer science. There is no adequate replacement for it in sight.

    It is a shame that Google and co are continuing to use SQL however.

    It would be a great step forward for companies to continue with relational but implement a truly relational language like Chris Date and Hugh Darwen's "D" rather than SQL.
    jorwell