Back on Oct. 26, eWEEK published a slideshow entitled "Why Relational Databases Don't Handle Big Data Well." It was an op-ed piece that looks at one side of the database debate and was labeled as such. This point of view was espoused by Matt Allen, senior manager of product solutions at NoSQL database specialist MarkLogic.
Let's be clear: MarkLogic makes and provides services for an alternative database to the big relational databases Oracle, IBM, SAP HANA, Microsoft SQL, Software AG, Teradata and others have built and refine all the time. So the article amounted to "fightin' words" to these companies.
MarkLogic, whose CEO, Gary Bloom, was an Oracle executive for 14 years, is one of a number of companies that produce software and offer services for NoSQL databases. Others include Couchbase, Datastax, ReThinkDB, Cassandra, MongoDB, FoundationDB, MariaDB, MarkLogic, and Basho.
Oct. 26 Slideshow Highlighted NoSQL Attributes
eWEEK expected a response, and sure enough, we received one from Andy Mendelsohn, executive vice president for Database Server Technologies at Oracle. We're publishing that side of the issue in this article.
To capsulize the key points in the article from a month ago:
--Relational databases, the dominant technology for storing and managing data, are not designed to handle big data. They also cannot handle mixed workloads very well.
--In fact, relational databases still look similar to the way they did more than 30 years ago when they were first introduced.
--Businesses focused on big data no longer can rely on the one-size-fits-all relational model; they must look toward new databases better designed to handle current workloads.
Allen's main point was that new-gen databases are more agile, more scalable, more affordable and faster to move data than relational databases.
Oracle's Side of the Story
"Number one, let me start by saying that we at Oracle have a broad array of data management products," Mendelsohn reminded eWEEK, "including NoSQL products and several SQL (structured query language) products—such as the MySQL, Oracle DB and TimesTen. So we definitely understand the roles of NoSQL products versus the relational SQL engine very well.
"If you go back to the beginning of time before relational databases in the '80s, what was out there were no-SQL databases," Mendelsohn said. "NoSQL databases are not new, they go back to the '70s and '80s. IBM mainframes have this product called VSAM; VSAM was a key value store. [Virtual storage access method (VSAM) is an IBM file storage access method, first used in the OS/VS1, OS/VS2].
"People in these startups want you to think these are new technologies; these are very old technologies that predate relational databases. There's just a new generation of them that has come out recently."
Customers were struggling with these "pre-relational" databases back in those days because they were very hard to write applications for, Mendelsohn said.
"If I wanted to do a simple reporting application, I had to have a developer write pages of code to write a little report," Mendelsohn said. "Relational databases were developed to solve this problem, because instead of writing pages and pages of what was then Cobol code, you just write a couple lines of SQL, and you could get your answers back without any developers required. You could have a business analyst do it, and later, tools came along that generated the SQL.
"The bottom line was that SQL was created to solve a developer productivity problem."