• Solid-state memory will soon be the right storage technology for a large fraction of databases, OLTP and analytic alike. I’m not sure whether the initial cutoff in database size is best thought of as terabytes or 10s of terabytes, but it’s in that range. And it will increase over time, for the usual cheaper-parts reasons.
• That doesn’t necessarily mean flash. PCM (Phase-Change Memory) is coming down the pike, with perhaps 100X the durability of flash, in terms of the total number of writes it can tolerate. On the other hand, PCM has issues in the face of heat. More futuristically, IBM is also high on magnetic racetrack memory. IBM likes the term storage-class memory to cover all this — which I find regrettable, since the acronym SCM is way overloaded already.
• Putting a disk controller in front of solid-state memory is really wasteful. It wreaks havoc on I/O rates.
• Generic PCIe interfaces don’t suffice either, in many analytic use cases. Their I/O is better, but still not good enough. (Doing better yet is where Petascan – the stealth-mode company I keep teasing about – comes in.)
• Disk will long be useful for very large databases. Kryder’s Law, about disk capacity, has at least as high an annual improvement as Moore’s Law shows for chip capacity, the disk rotation speed bottleneck notwithstanding. Disk will long be much cheaper than silicon for data storage. And cheaper silicon in sensors will lead to ever more machine-generated data that fills up a lot of disks.
• Disk will long be useful for archiving. Disk is the new tape.

*When the first three people to the question microphone include both Mike Stonebraker and Dave DeWitt, your thinking tends to clarify in a hurry.

Related links

• A slide deck by C. Mohan of IBM similar to the one he presented at the NEDB Summit about storage-class memories.
• A much more detailed IBM presentation on storage-class memories.
• Oracle’s and Teradata’s beliefs about the importance of solid-state memory.
  

Other posts based on my January, 2010 New England Database Summit keynote address

• Data-based snooping — a huge threat to liberty that we’re all helping make worse
• Interesting trends in database and analytic technology
• Open issues in database and analytic technology

So far there are two confirmed speakers — Raghu Ramakrishnan of Yahoo and me.  My talk title will be something like “Database and analytic technology: The state of the union”, with all wordplay intended.

There’s more information at the official New England Database Summit website. There’s also a post with similar information on Daniel Abadi’s DBMS Musings blog.

Edit after the event:

Posts based on my January, 2010 New England Database Summit keynote address

• Data-based snooping — a huge threat to liberty that we’re all helping make worse
• Flash, other solid-state memory, and disk
• Interesting trends in database and analytic technology
• Open issues in database and analytic technology

• MapReduce is something very new
• MapReduce involves strict adherence to the Map-Reduce programming paradigm
• MapReduce is a single technology

So let’s give it a try.

When Dave DeWitt and Mike Stonebraker leveled their famous blast at MapReduce, many people thought they overstated their case. But one part of their story – one that both Mike and Dave say was most central to their case – was never effectively refuted, namely the claim that these ideas aren’t particularly new. I haven’t actually read enough computer science literature to have an independent opinion on that issue. But I’ll say this – claims from companies such as SenSage, Oracle, or Splunk that “We’ve been doing MapReduce all along” seem pretty credible to me.

True, what those companies were doing things may not have looked exactly like the instant-classic MapReduce programming paradigm. But the same is true of many things almost everybody would agree count as MapReduce. In particular, it is often not the case that you alternate Map and Reduce steps, each of whose outputs is a set of simple <Key, Value> pairs, with data redistributed based on Key at every step.

Here are some examples of what I mean, drawn from my recent MapReduce webinar.

• If you do text indexing in MapReduce, your goal is to wind up with a text index. So at some point you Reduce to a pair <WordName, {all the (DocumentID, offset) pairs for the whole corpus, suitably ordered}>. That’s a heckuva compound “Value”.
• The goal of data mining is usually to estimate a rather small number of parameters based on a large overall data set, often – depending on algorithm – in the form of a single vector. When you do that in MapReduce. you partition data among nodes, calculate something on each node that is structured more or less like your final vector. So when it comes time for the reduce, you just ship all of your vectors – one per node – to a single Reduce node, and do the appropriate math. Redistribution based on Key would be quite pointless.
• When you sessionize clickstream logs in MapReduce, you may have just as many output records as input records. However, they now are reformatted, and might have a SessionID appended. In those cases, Reduce isn’t doing much by the way of reduction.
• And as I happens in some Vertica-Hadoop use cases around mortgage trading, sometimes MapReduce can even make data sets vastly larger.

By no means do I think this is a weakness of the MapReduce programming paradigm. Rather, I think it’s a MapReduce strength. But it’s not quite the way MapReduce has been promoted and explained to the IT public.

Finally: MapReduce, as commonly conceived, spans two different – albeit closely related – technology domains:

• Parallel programming
• Distributed data management

For example, I imagine Greenplum’s and Vertica’s MapReduce/SQL combined syntaxes are very similar to each others. But Vertica’s data management implementation of MapReduce, which relies on Hadoop, is very different from Greenplum’s, which is tied into the Greenplum DBMS. Similary, non-DBMS MapReduce implementations are commonly associated with distributed file systems – notably HDFS (Hadoop Distributed File Systems) or Google’s internal GFS (Google File System). In those systems, the parallel language execution part should be aware of how the distributed file management part works – but perhaps that awareness can be pretty lightweight.

Right now, this is a distinction pretty much without a difference. If you choose an implementation of MapReduce — like pure Hadoop (say in the Cloudera distribution) or Hadoop-Vertica or Aster Data’s SQL/MapReduce – you’re basically picking an entire technology stack. But those stacks are going to do a whole lot of changing and maturing in the near future – and as they do, it’s likely that projects will interact or even combine in all sorts of interesting ways.

Bottom line: There are a lot of different ways to exploit MapReduce-related technology.

XLDB more or less comprises:

• A series of what have now been three workshops: XLDB1 in 2007, XLDB2 in 2008, and XLDB3 in 2009 (the closest thing to a master link is probably the XLDB3 site’s related link page). Participants have included, among others:
  • A lot of big-name database-oriented computer science researchers — Mike Stonebraker, Dave DeWitt, Martin Kersten, and numerous others
  • Academics responsible for scientific database management, especially but not only in the astronomy area
  • Some vendors (although vendor participation was cut back after XLDB1) — at XLDB3, which is the one I went to, the three vendor folks who actually talked were Stephen Brobst of Teradata, Luke Lonergan of Greenplum (who worked in scientific high performance computing earlier in his career), and Jeff Hammerbacher of Cloudera.
  • eBay and to some extent other large web companies
  • A European Union funding bureaucrat
  • Me
• An attempt to kick start a broader movement, perhaps comprising (it’s not totally clear yet):
  • Computer science researchers interested in database issues
  • Database technology vendors
  • Scientific researchers (academic) who have very large or otherwise difficult database management problems
  • Scientific researchers (commercial) who have very large or otherwise difficult database management problems
  • Other commercial users who have very large database management problems

The first result or spin-out from the XLDB effort seems to have been the SciDB project. This is an effort to build an open source DBMS called SciDB that will address some of the needs the XLDB effort is uncovering. (More on that in other posts.) Somewhat confusingly, all the use cases the XLDB group is collecting are currently being posted on SciDB’s website, apparently because it’s glitzier and healthier than, say, the excessively sparse XLDB wiki. Some SciDB development has happened, but no large sugar daddy has yet been found. (It’s a fairly open secret that eBay looked seriously and favorably at funding SciDB before the economic downturn.) hit.

Numerous big-name computer scientists are associated with SciDB, indeed more closely (it would seem) than with XLDB. That said, I’m guessing Dave DeWitt’s involvement in the open-source SciDB isn’t what it would be if he hadn’t gone to Microsoft. DeWitt actually skipped XLDB3, although he was in town for VLDB. (XLDB3 was back-to-back with VLDB 2009 in Lyon, France in late August.) Stonebraker just didn’t make the flight for either conference, due to the double-knee “upgrade” he had back in March.

There’s a lot more to be said about the cross-discipline or science-specific requirements that researchers place on data management, but I’ll leave that for later and just get this posted as a start — assuming, of course, that blog outages permit.

Related links

• Paper laying out the SciDB project
• One version of a SciDB overview page, with links to academic papers

• In most cases, no.
• Most of these technologies are designed for simple, high-volume OLTP (OnLine Transaction Processing.) Most large enterprises have an established way of doing OLTP, probably via relational database management systems. Why change?
• MapReduce is an exception, in that it’s designed for analytics. MapReduce may be useful for enterprises. But where it is, it probably should be integrated into an analytic DBMS.
• There’s one big countervailing factor to all these generalities — schema flexibility.

As for the longer form, let me start by noting that there are two main kinds of reason for not liking SQL. First, you might be fine with the idea of a (somewhat) nonprocedural, schema-aware DML/DDL (Data Manipulation/Description Language), but just think another kind is better, or more suited to your use case. If your reason is like that, you might favor alternatives such as:

• OLAP-based languages such as MDX.
• XML-oriented languages.
• “True” relational languages, because SQL deviated from the path of relational virtue under the corrupt influence of IBM — aka “Blue Babylon” — and the IT world has been languishing in sin ever since.

The second class of reason for avoiding SQL is because you don’t like the idea of a separate schema-aware DML at all. Possible reasons for this orientation include:

• You just like to program, and want to manipulate stored data the same way you do anything else. Thus, you are bothered by an “impedance mismatch” between SQL and your favorite programming languages.  This is real. It also has been overcome by many, many enterprises around the world.
• You believe that more procedural alternatives are a better fit for cloud computing and extreme scale-out on failure-prone commodity hardware. Facebook made that case to me. However, I have trouble thinking of very many enterprise scenarios where it applies, especially when one considers electricity costs and the like.
• Your schemas change more quickly than your data architects can reasonably be expected to keep up with. Facebook made that case to me too. Enterprise examples might include marketing campaigns and M&A. I’ve long thought this to be a legitimate, looming concern. But I don’t know that stripped-down DBMS are the way to address it.
• You believe that SQL has severe processing overhead. In most enterprise use cases, that would just be bogus.
• You lack familiarity with SQL.

That last point is not a joke. One of the weirder database architectures I know of is the one underlying Guild Wars. Its developer — a brilliantly impressive guy — told me flat-out that he learned in college how to build a DBMS, but he didn’t learn how to develop for a conventional one. This was instrumental in his decision to build an unconventional data management architecture that uses SQL Server as little more than a smart file manager.

The questions of SQL performance and — often-unspecified — “overhead” are interesting to view through the lens of the H-Store/VoltDB project. Mike Stonebraker et al.:

• Are building a scale-out-oriented OLTP DBMS that is meant to run in RAM, preserving data through replication to other servers’ RAM more than through output to disk.
• Believe that 95% of what a typical SQL DBMS does to manage OLTP is wasteful overhead
• Originally planned to not use SQL, but wound up going with SQL because alternatives were insufficiently performant.

Mike himself, of course, has been all over the spectrum on SQL-like languages. First he favored QUEL vigorously over SQL for mainstream relational DBMS. Then he led the charge to extend SQL in PostgreSQL, Illustra, et al. Then he actually staked out a contrarian position in the area of complex event/stream processing by favoring a SQL-like language in an area where other alternatives were better established — but that was at what turned into StreamBase, which now emphasizes visual programming over any kind of coding language.

I need to write much more about schema flexibility, but tonight — which will be my third straight of <<8 hours sleep — is not the time for that.

Last week I went back to California, visiting — among others — Greenplum, Aster, and eBay. Greenplum turns out to have a somewhat more skeptical view of MapReduce than they held previously. Aster Data continues to be somewhat more bullish, a difference I attribute in part to a focus on slightly different customer segments. (For the record, I probably put more weight on that reason than Aster itself does.) eBay seems even more negative on MapReduce, if that is possible, than it previously was. Also, I gathered I should talk with Hadoop-centric start-up Cloudera, and arranged to do so for this Tuesday, after which I planned to write a MapReduce update.

This afternoon (Monday) I was at Vertica, with Mike Stonebraker part of the meeting. He mentioned that he and David DeWitt had a new SIGMOD paper that compared MapReduce unfavorably to parallel SQL DBMS, both Vertica and a row store “DBMS-X”. Mike offered to get me a copy next week, and I agreed to hold off on my MapReduce update until then.

At 6:30 this evening, Eric Lai of Computerworld emailed me with a draft of the paper he’d gotten from DeWitt, with a request for comment. He was submitting the story at 8 pm. I sent email back to Vertica saying “What the hell??????” (after editing my original draft of the third word in that) and set to work. Later in the evening, coauthor Andy Pavlo posted a web page with the benchmark particulars, and eventually posted a link to the paper to. And I rushed out several related blog posts.

Frankly, my views on MapReduce are more balanced than today’s weary negativity would seem to imply.  But I didn’t have time to wait and lead off with an overview post reflecting that balance.  Stay tuned.

There. I’ve vented. I feel better.

And by the way, I’m not angry at anybody.  Really.  What amazes me is how SNAFUed things manage to get without anybody doing anything particularly wrong.

• A couple of different flavors of a Grep task originally proposed in a Google MapReduce paper.
• A database query on simulated clickstream data
• A join on the same clickstream data.
• Two aggregations on the clickstream data.

Both DBMS outshone Hadoop, and Vertica outperformed DBMS-X. This was true both on the Grep task, and also on all the other DBMS-like tasks the authors specified. Reasons for the DBMS outdoing Hadoop included compression and optimization. Reasons for Vertica outdoing DBMS-X included the usual benefits of column stores.

More precisely, both DBMS clobbered Hadoop on throughput. Hadoop, however, had some advantages in load speed and the like.

The paper also argues strenuously that for complex and/or team-oriented database programming, one is much better off using a DBMS rather than reinventing the software wheel. However, it concedes that for simple programming tasks, Hadoop may be easier and lighter-weight. For example, some of the benchmark tasks required user-defined functions (UDFs) or the equivalent, and those weren’t as easy to write in the DBMS as one might think.

Frankly, the paper is less extremely anti-MapReduce than I expected based on the authorship, or on how Mike Stonebraker framed it to me when he told me about it Monday afternoon. That said, it is absolutely in line with the DeWitt/Stonebraker meme “MapReduce isn’t nearly as good for DBMS-style processing as a DBMS is.”

It’s pretty obvious who’s running the show. Sam Madden’s name is given as a contact; elsewhere it’s referred to as being organized by Madden and Mike Stonebraker.  Of the six identified papers, 2-3 look like the subjects or people could be taken straight from Vertica’s Database Column blog.  But that hardly means the event will be one long Vertica commercial.  For example, the other papers include one from Netezza and one on Flash memory data access methods.

I really doubt I’ll make to Cambridge in time for the 9:00 am opening remarks , but I’ll try to swing by later on.

• Map functions can’t do anything you can’t also do in PostgreSQL user-defined functions (assuming, of course, PostgreSQL UDFs can be written in the language you want to use).
• Reduce functions can’t do anything you can’t also do in PostgreSQL user-defined aggregates (with the same caveat).
• Map and Reduce functions always write their result sets to disk. This can create a large performance loss.
• Map and Reduce functions require new instances to be fired up to run them. This can also create a large performance loss. (Without checking, I’m guessing that one is very implementation-specific. I.e., even if it’s true of Hadoop, it may not be true of Greenplum’s or Aster Data’s MapReduce implementations.)
• Mike and his associates are working on benchmarks that he believes will show that MapReduce performance is 10X worse than parallel row-based SQL DBMS, and 100X worse than columnar SQL DBMS.
• MapReduce doesn’t play nicely with the SQL Analytics part of the SQL standard.
• The one advantage Mike concedes to MapReduce — more graceful degradation when nodes fail — isn’t that important in the hardware configurations on which parallel analytic DBMS actually run today. I.e., a Greenplum or Vertica installation is going to have nodes fail much more rarely than a Google data center will.

Bottom line: Mike Stonebraker more than disagrees with the claim that MapReduce is a valuable addition to SQL data warehousing, on somewhat different grounds than he emphasized in the Great MapReduce Debate last January.

• Oracle and Microsoft are doomed in the data warehouse market unless they acquire MPP/shared-nothing data warehouse DBMS and/or data warehouse appliances.
• DATAllegro is the ideal acquisition for either of them.

Microsoft has now validated my claim by agreeing to buy DATAllegro. As you probably know, we’ve been covering DATAllegro extensively, as per the links listed below.

Basic deal highlights include:

• A definitive agreement has been signed.
• Deal closing is expected in a few weeks.
• I got the impression that the undisclosed price is surely a nice step-up from the Series D round that closed a few months ago.
• DATAllegro CEO Stuart Frost will run an engineering division, based at DATAllegro’s current headquarters, reporting into Microsoft’s SQL Server division. He seems to be locked into staying at Microsoft for at least a couple of years.
• DATAllegro’s software will be ported from its current Linux/Ingres stack to Windows/SQL Server.
• The DATAllegro brand name will probably go away.
• Everything else is either undisclosed or truly not yet decided. In particular, there’s no word as to whether Stuart will run any parts of what now is Microsoft.

To understand how DATAllegro will fit into Microsoft’s SQL Server product line, let’s start by reviewing aspects of DATAllegro’s product architecture:

• Each DATAllegro node except the head runs a full copy of Ingres, an OLTP DBMS, over Linux.
• Thus, both data and SQL are shipped from node to node. Like vendors of comparable systems, DATAllegro does a better job each release of either resolving queries on one node or shipping data from peer to peer, rather than sending all intermediate results up to the head node for further processing.
• The whole thing runs on standard blades and EMC storage, plus Cisco Infiniband.
• The DATAllegro head node runs DATAllegro’s own SQL optimizer. Thus in some ways each query is optimized twice – once overall in the head node, then again as different pieces of the query are run on different nodes. (Actually, it’s generally more accurate to say that each piece of the query is run once per node, but sometimes that isn’t literally true due to considerations of partitioning.)

Feasibility work has already been done on the port to SQL Server. Stuart reports that the work so far indicates a significant speed-up, which he attributes to data warehouse performance optimizations present in SQL Server that are lacking in the less well-funded Ingres. (Specifically mentioned were star joins and some sort of memory-centric capability.) One interesting implication is that when DATAllegro’s optimizer is rewritten for the port, it will largely do less than it has been doing to date, since SQL Server needs less “help” in optimizing the single-node parts of queries than Ingres does. The port will also of course involve changes to the file structures, due both to the change of DBMS and operating system; I got the sense that in this area, final decisions truly haven’t yet been made.

And yes – Stuart now confesses that DATAllegro was designed for acquisition from the get-go, e.g. in the choice to incorporate a third-party OLTP DBMS.

Related links (some about to go up)

• Why DATAllegro could provide Microsoft with a true enterprise data warehouse sooner than you think
• How will Oracle save its data warehouse business?
• The data warehouse DBMS consolidation has begun
• Our best cut at DATAllegro’s numbers
• Two white papers (dated March and May of 2007) focusing on DATAllegro’s product architecture
• Why MPP/shared-nothing architectures (which neither Oracle nor Microsoft SQL Server have) will win in the data warehouse market
• Why Oracle’s counterarguments don’t hold water
• Three ways Oracle and Microsoft could go MPP
• Deal prospects in the data warehouse DBMS market
• DATAllegro’s web site
• DATAllegro CEO Stuart Frost’s spirited blog
• A general link to all our DATAllegro coverage

]]> http://www.dbms2.com/2008/07/24/microsoft-is-buying-datallegro/feed/ 5