Databases: Relational or NoSQL? Once upon a time, the distinction between the two was clear, but has been muddied lately by the addition of JSON support to various relational databases.
But does merely adding JSON support to an RDBMS make it a competitor for NoSQL? Not by a long shot. The real differences between a relational database and a NoSQL product remain root- and core-deep, and they aren't likely to change with JSON support for Oracle or with SQL querying to Hadoop.
It ain't only JSON
For starters, JSON support by itself doesn't make a NoSQL database. Tomasz Kunicki of AdRem Software, creators of the NetCrunch monitoring system (which uses both in-memory, SQL, and NoSQL technologies), agrees: "JSON does not count much [by] itself. It is just a convenient way to represent data, especially when you write code in JavaScript."
The real point of NoSQL, in Kunicki's opinion, is its "schema-free databases and scalability -- but it does not mean it doesn't need database modeling, as many people think." He says this has led to hype and misapplication of NoSQL technologies, which work "especially good for time based data (and they originate from this application)."
Bob Muglia, a longtime presence at Microsoft and co-creator of the Snowflake data warehouse as a service, sees relational and NoSQL databases as fundamentally different in how their design reflects their intended use.
Relational databases, Muglia noted, are created for strong consistency, but at the cost of speed and scale -- at least, having speed and scale for those databases being expensive and difficult. NoSQL slightly sacrifices consistency across nodes for both speed and scalability.
That hasn't stopped anyone from trying to graft NoSQL-style speed and scale onto relational databases, but it's almost always a tough break. "We built Snowflake, to begin with, on MySQL as our original system to store our metadata for which we needed fully ACID-based transactions," Muglia said. "Scaling that and achieving the level of availability we wanted, five nines -- it's virtually impossible to get five nines with a relational database.... So for our metadata store, we moved away from MySQL to a fully ACID-based NoSQL system, FoundationDB."
NoSQL storage plus SQL querying still equals NoSQL
Adding JSON support to a relational database doesn't make it into a NoSQL system, nor does adding SQL querying to a NoSQL store turn it into -- or even competition for -- a relational database. Using SQL to query a NoSQL store is about providing convenience for the user, not redefining the workings of SQL (or NoSQL) on the inside.
As Muglia pointed out with regard to SQL as a querying system, there's a trend toward SQL for analytics, "regardless of the implications" (that is, what's running underneath), and a corresponding trend away from SQL in transactional systems, "at least for high scale, high availability."
Kunicki feels that the differences between database systems must be respected. "Adding SQL at the top of NoSQL database," he said, "and adding support for JSON documents to SQL databases are unfortunate attempts to trick the users."
Some folks are serious about seeing how the best of relational databases (ACID transactions) and NoSQL (speed, scalability) can be merged. Apart from FoundationDB, other projects and products like Splice Machine (derived indirectly from Hadoop and Apache Derby) are in the works.
The field remains in its infancy, but a true next-generation product is most likely to come from aggressive envelope-pushing experiments, rather than grafting the data formats or querying systems of one onto the underlying technology of the other.