Original URL: https://www.theregister.com/2010/09/13/michael_stonebraker_interview/
SciDB: Relational daddy answers Google, Hadoop, NoSQL
Stonebraker doesn't drop ACID
Posted in Databases, 13th September 2010 03:47 GMT
Mention "relational databases" and a few people's names might spring to mind: Oracle's Larry Ellison, thanks to his billions, or Monty Widenius, main author of the ferociously popular MySQL. Geekier types might plump for Oracle's former Dr DBA Ken Jacobs or open-sourcer Brian Akers, who helped architect MySQL.
Michael Stonebraker's name probably doesn't jump very high in many minds outside computer science, yet it was Stonebraker's quick thinking 40 years ago that paved the way for the industry these better-knowns call home.
A faculty member of the University of California in Berkeley, Stonebraker seized on the research of IBM mathematician Tedd Codd to start work co-developing the industry's first relational database in 1973: Ingres. Ellison wasn't around until 1977, while it took lumbering IBM, owner of the mighty DB2, another eight years before it had something.
Ingres fed into Sybase as Sybase founder Robert Epstein was one of those who worked on Ingres, and then Microsoft's SQL Server. Through his various teaching positions, Stonebraker has also schooled CEOs, CTOs, founders and vice presidents of engineering at VMware, Sleepycat Software, Tibco, Oracle, Documentum, Alfresco and Cloudera. Along the way, Stonebraker found time to deliver Postgres, Mariposa, Aurora, C-Store and H-Store and help found startups to sell and support them: Illustra Information Technologies, Cohera, Streambase, Vertica and VoltDB.
After 40 years, though, Stonebraker finally thinks it's no longer a "one-size-fits-all" world and that there could be more to life than just relational. His latest work, SciDB, is going post-relational to serve the needs of those working with big data - large volumes of information crunched on thousands of nodes in distributed data centers.
"In the 1980s, the 'answer' was if all you wanted to do was business data processing, then it was relational databases. Try to stretch SQL to do everything, though, and that's an unnatural act."
And as this pioneer from the past keeps working, he's come into conflict with those on today's leading edge - the NoSQL movement - as he's put the sacred cows of the Web 2.0 crowd in their place for cheaply sacrificing the benefits of the relational technology he pioneered.
As autumn kicks in, the 66-year-old MIT adjunct professor is on the cusp of releasing the first code under open source for SciDB, a collaboration with long-time colleague Dave DeWitt.
SciDB is Stonebraker's big-data analytics play in an era of Google's MapReduce, Apache Software Foundation's Hadoop and the NoSQL evangelists who seem to be setting the pace, if not hogging the limelight, on big data in massive data centers today.
The database targets boffins, number crunchers and computer scientists and will scale, it's claimed, from megabytes of data to petabytes running on tens of thousands - all on industry standard, multi-core x86 servers with little human administration.
"The 'answer' is the current thing I'm focused on," Stonebraker told The Reg about the work on SciDB.
"The 'answer' in the 1980s was there was only one database market. In 2010, there are business processing databases with OLTP, science databases, document databases. There are genomic databases. The horizontal world of the database space has mushroomed.
"In the 1980s, the 'answer' was if all you wanted to do was business data processing, then it was relational databases. Try to stretch SQL to do everything, though, and that's an unnatural act."
According to Stonebraker, the relational model he helped popularize doesn't work in data-intensive scientific discovery because the data is multidimensional.
Combining and sharing that data means complicated engineering work on the part of developers and database admins, and it produces bottlenecks. Scientists have been rolling their own architectures or - recently - deploying Hadoop, the open-source implementation of Google's MapReduce.
SciDB goes beyond the relational world Stonebraker helped pioneer by swapping rows and columns for mathematical arrays that put fewer restrictions on the data and can work in any number of dimensions. Stonebraker claimed arrays are 100 or so times faster than a RDBMS on this class of problem.
A database for all seasons
It's a world away from where Stonebraker started. In addition to being multidimensional and offering array-based scaling from megabytes to petabytes and running on tens of thousands of clustered nodes, SciDB's will be write once read many, allow bulk load rather than single road insert, provide parallel computation, be designed for automatic rather than manual administration, and work with R, Matlab, IDL, C++ and Python.
SciDB's being piloted by healthcare products giant Novartis, the Large Synoptic Survey Telescope (LSST), Fermilab and an unnamed Russian astronomy project.
"Postgres is no good at the data warehouse market because the science market wants arrays, they don't want tables. But arrays are impossibly slow on top of tables. Postgres has arrays, but they were supported by blobs, so weren't first-class citizens," Stonebraker said.
"I learned if you want to advance the data warehouse market and want to go fast, you need a column store, not a row store...There are unbelievable advantages to specialization."
SciDB's is Stonebraker's biggest departure from the rules of the relational road. It's a journey that in the last five years has seen Stonebraker reinvent different parts of the relational stack.
Battle of the rows
Stonebraker reckons the relational staples such as logging, locking, latching and buffer management that have helped pioneer and maintain a crucial feature of databases - data integrity according to the atomicity, consistency, isolation and durability (ACID) principles - have also become its biggest burden. Processing alone to make these features work soaks up 90 per cent of a transaction's time in terms of CPU cycles, slowing performance and wasting power.
The serial inventor's answer to this particular problem was initially VoltDB. His database speeds things up by moving data into memory and using distributed data partitioning with multi-core processors and server memory. ACID is retained because VoltDB uses single-threaded partitions that run autonomously while data is replicated in a cluster for high availability.
VoltDB claims to be 45 times faster than an Oracle relational database on a Dell PowerEdge R610 cluster based on Intel's Xeon 5550 with near-linear scaling on a 12-node cluster. VoltDB was the product of H-Store-project, a collaboration between Stonebraker's MIT home, Brown University, Yale University and Hewlett-Packard Labs.
Before VoltDB, there was Vertica. This used a column-oriented, shared-nothing architecture with a massively parallel processing (MPP) engine and data compression to reduce storage and speed queries. Vertica claims query results between 50 and 200 times faster than databases that store data in rows. Vertica started as the C-Store project also with Brown and MIT, plus Brandeis University and University of Massachusetts, Boston.
"Talk to the MapReduce guys and they are fanatical about 'not invented here'... MapReduce was written by people who don't understand databases at all."
Stonebraker reckons columnar-databases are quicker than relational databases because they know what they are looking for. They don't need to waste time sorting rows.
VoltDB, Versa, and - soon - SciDB take Stonebraker into a growing tussle against NoSQL over which architecture is "right" in a fight for mindshare and for customers. SciDB is listed as a NoSQL database, here.
Facing off against SciDB, Vertica and VoltDB in a range of scenarios are Hadoop, MapReduce, Cassandra, CouchDB, Amazon's SimpleDB and Memcached - the latter being the distributed memory caching companion to MySQL used for scale and speed. Helping push them are their creators such as Google and Amazon or startups like Cloudera, mega-scale customers such as Twitter and Facebook, and an army of evangelists convinced that NoSQL is the future.
Sparks flew between Stonebraker and the NoSQL movement in 2008 when the relational expert incensed MapReduce fans in a joint blog with DeWitt for calling MapReduce a "giant step backward in the programming paradigm for large-scale data intensive applications".
Stonebraker and DeWitt professed amazement at the hype over how MapReduce represented a "paradigm shift in the development of scalable, data-intensive applications" and called MapReduce a good idea for writing "certain types" of general-purpose computations but lacking many tools and features commonly associated with DBMS that users have come to depend on.
Bloggers stormed back, damning these "so-called" database experts for "not getting" data in the cloud and - like jealous suitors jumping to their lover's defense - demanded a retraction of this "highly inaccurate article" as if it had slandered their beloved MapReduce.
Most missed the point: Stonebraker and DeWitt weren't calling MapReduce a bad database. They were picking up on the fact that MapReduce - like its open-source clone Hadoop - are being used as if they are databases, with more data being dumped in them by customers on a daily basis and with those customers then needing to transact and analyze that data. It's a problem that's been creeping into Memcached and NoSQL, with people now trying to make Memcached and NoSQL work with relational databases.
Was Stonebraker surprised by the flames?
"The NoSQL guys are people who know nothing about databases and their first reaction is to lash out, so I'm not surprised [by the reaction]," he said.
"Talk to the MapReduce guys and they are fanatical about 'not invented here'... MapReduce was written by people who don't understand databases at all," an unapologetic Stonebraker continued. "They produced a thing that worked for their crawling applications. MapReduce was written to support the processing pipeline behind Google."
Turning MapReduce and Hadoop into databases would take a long time and a huge rewrite to inject things like data repositories, indexes, query languages and updates.
Does he recant in the face of such a flaming? Far from it. He's as critical as ever.
"If you are over 35, you are over the hill apparently in math," he claimed. "In computer science, the grey beards like me are still viable, and it's for this reason that what goes around comes around. The young guys haven't seen it before and the problem with our computer science education system is the lessons from the past seem to get lost."
And, it would seem, Google agrees with him.
Accidental SQL supporter
Stonebraker's got little time for those who claim it's the language that's slowing down databases serving big data. Hadoop is written in Java, CouchDB in Erlang, and in-memory key-value persistent storage engine Memcached in C. For Stonebraker, the interface is the problem, not the language. Hence Volt has been rewritten to remove 90 per cent of the overhead associated with OLTP.
"I'm not a particular fan of SQL but I don't mind it. Jettisoning it just to, say, "get record" is a huge mistake."
Interestingly, Stonebroker wrote Ingres in QUEL and left SQL to Ellison. The industry, and history, swung behind SQL, helping catapult Oracle to today's number-one position while Ingres didn't switch to SQL until version six in the mid 1990s - too late to catch Oracle.
ACID fan and language lessons
"I can remember a debate in the '70s: assembly language jockeys would say C is too slow. I need to control my own registers. Twenty-five to 30 years later, we know that's not true and compilers are as good as or better than humans at producing machine-optimized code. Just like you'd never bet on assembly language today. You should not bet on low-level database repositories by alleging they are faster than a higher-level language."
As far as Stonebraker is concerned, these NoSQL architectures were built to fix specific problems by the companies that made them. Now, they are being peddled to the wider world. And that's the real problem because they undermine the principles of ACID that have helped guarantee the performance and reliability of data and that have fundamentally underpinned relational and Stonebraker's work. Even as he's gone non-relational with SciDB, Stonebraker said SciDB will comply with ACID.
Sure, Memcached, for example, is popular - used by Twitter, YouTube and Digg - and it's often used in conjunction with MySQL. But Memcached is not ACID-compliant. It might be fine at processing observations, tweets, videos and news, but customers outside the world of Web 2.0 clouds won't want to run things like financials through a Memcached system. Memcached is not alone: most NoSQLers make no bones about dumping ACID.
Stonebraker is more than just an MIT academic - he's part businessman: he's co-founder and chief technology officer for VoltDB, and a co-founder and board member of Vertica. That makes this more than a battle of architectures - it's a fight for customers' dollars.
Stonebraker reckons the NoSQL community has ditched ACID because it's "too expensive" but installing an ACID-free database is a bet against the future. As organizations grow, they will take decisions that inevitably put more of their important data into such systems and it's then that data integrity as guaranteed by ACID will matter.
"I'm a huge fan of ACID," Stonebraker confessed. "The database transaction model has served us well for 30 years and essentially everyone who jettisons it regrets it because it gives you a systematic underpinning for your data. A lot of the NoSQL guys jettison ACID and that's a huge mistake because, by and large, the NoSQL guys are not database experts.
"You might not need ACID now, but database applications live a very long time...requirements may change over that time. If you decide not to run ACID, make sure you never need it in the future," Stonebraker said.
ACID is what businesses need for mission-critical stuff. "I have a friend at a large telco who's not interested in NoSQL because they give up ACID compliance," Stonebraker reckoned.
Of course, Stonebraker is more than just an MIT academic. He's part businessman. He's co-founder and chief technology officer for VoltDB, and a co-founder and board member of Vertica. That makes this more than a battle of architectures. It's a fight for customers' dollars. It was no coincidence that Stonebraker and DeWitt's attack on MapReduce was launched from their Vertica blog.
Vertica's customers include Mozilla - the open-source operation uses Stonebraker's creation with open-source BI Pentaho to analyze billions of Firefox user log records per day in an attempt to improve product R&D. Guess.com, meanwhile, uses Vertica with MicroStrategy to analyze retail and inventory data in its US and European data centers.
Vertica's also landed some Web 2.0 big-data fish: Zynga, maker of the popular FarmVille and Mafia Wars hits on Facebook has come out as a relational fan for analytics. In a statement supporting Vertica 4.0, Zynga's vice president of analytics Ken Rudin called Vertica a "no wind-up toy", running a daily load of 40 million players and 3TB of data across 230 nodes and two clusters on the database's columnar data warehouse.
This wouldn't be so awkward if it weren't for the fact that Facebook has built its own big-data offering, Cassandra, which has its own take on columns. Cassandra's columns require a mind switch for those coming from a relational background, while Vertica provocatively calls itself "the only true enterprise-ready MPP columnar database" with an emphasis on "only" and "columnar database".
Stonebraker's other recent creation, VoltDB, which started operations in 2009, doesn't yet list any customers.
Roasting relational elephants
Stonebraker's not just critical of the NoSQL new wave: he's got plenty of fire left for the relational "elephants," Microsoft and Oracle. Increasingly, their answer to high-end relational processing is to boost the software by fusing it with the underlying hardware.
Oracle's built the Exadata server, a hardware appliance running Oracle's database that combines Smart Flash Cache to reduce bottlenecks and columnar compression to reduce data warehousing table size with solid-state multiterabyte storage arrays to offload data. Microsoft's partnered with Bull, Dell, EMC, HP and IBM on massively parallel processor appliances running SQL Server - SQL Server 2008 R2 Parallel Data Warehouse.
The concepts are similar to Stonebraker's warehousing and analytics work, but Stonebraker has not allowed himself to become married to a small set of certified hardware suppliers with specialized chips or hardware. Stronebraker's goal is to achieve scale through software working on affordable, commodity hardware - taking advantage of multi-core CPUs and greater memory. According to Stonebraker, Oracle and Microsoft can just keep adding more expensive hardware but the fundamental problems or bottlenecks won't be solved.
Keep on keeping on
"VoltDB runs more transactions per second on fewer dollars than Exadata 2 on all its hardware," Stonebraker said. "If you give 20 nodes to the elephants, you get 20 nodes of performance. If you give the same 20 nodes to VoltDB, we will go a factor of 40 faster. This particular elephant runs for a while but there are problems with RAC and Exadata 2."
With SciDB coming, Stonebraker believes the technologies he helped turn into a multibillion-dollar industry no longer have the monopoly. But diversity doesn't mean abandoning the architectures of the past and he remains committed to the underlying principles of reliability, integrity and familiarity of SQL and relational in the world of big data.
What comes after SciDB for Stonebraker and for databases? Stonebraker still sees "horrible challenges" in data integration, especially unstructured and semi-structured data.
He quotes an unnamed New-York bank he once advised that was massively decentralized and had no easy way to establish a single customer list. "The bank couldn't tell IBM in Armonk was the same as IBM SA in Madrid and had no way to solve this problem. Eventually, with a lot of pain and suffering, they sent letters to all their customers asking: 'Who are you?'"
"My suspicion is the number-one cause of outages is human error and after that is badly tested apps, and everything else is way down. What we ought to be focused on in terms of high availability is probably not what we are focused on at all."
Scalability is a major issue and he points to Cassandra's father Facebook that runs MySQL "4,000 ways" and has added 9,000 instances of Memcached. "I shudder at how they keep that thing up, because it's glue and bailing wire and application-level recovery. They are desperate for anything that's more scalable and goes faster," he said.
For all that, he sees a world where NoSQL co-exists with relational and some NoSQL systems will survive a likely shakeout and consolidation. Features will also cross over: VoltDB, for example, will get a JSON interface, adding a document management model on top of SQL.
"The future will hold some number - maybe half a dozen or a dozen - of interesting data management alternatives that are very good at what they do and complement database systems like SQL Server, Oracle and DB2. Conventional legacy row stores will be one of the half dozen things and there will be others."
High availability is another concern especially as data gets bigger and services larger and supposedly more critical. Stonebraker's studying outages at an unnamed "major worldwide institution".
"My suspicion is the number-one cause of outages is human error and after that is badly tested apps, and everything else is way down. What we ought to be focused on in terms of high availability is probably not what we are focused on at all," he says.
It was the technology that inspired Stonebraker in 1973 when he started Ingres and stole a march on IBM: "Ted Codd's ideas were clearly superior to Codasyl and IMS. Hence my early interest in the technology," he said. And now, after 40 years?
"It is possible that DBMS research will peter out and there will be no more innovation. However, I doubt it." ®