Oracle acquired Pillar Data Systems on June 29, 2011 and I was quite silent on the matter because the topic was not blog-worthy. But, I’m not blogging about the blog-worthiness of old news. The day after the news regarding the Pillar acquisition, Oracle executives held a webinar covering the latest turn in Oracle’s storage strategy. Some of the content in that webinar was, in fact, worthy of a blog entry.
The webinar slides can be found here: Oracle Storage Strategy Update June 29, 2011 (slides).
Fair or Foul?
Imagine for a moment that SAP spends the money to compete in the America’s Cup to race the Oracle boat. Imagine further that the captain of the boat fouled in some way during a race (I know nothing about sailboat races because I’m a mere mortal). It would take Oracle executives about 42 seconds to call out the issue. Well, as I see it, slide number 15 in the above-referenced Storage Strategy webcast slide deck is a foul and while it took me longer than 42 seconds to get to the matter, I’d like to address the matter now.
As the following screen shot of slide 15 shows, Oracle is specifically targeting EMC storage technology to contrast to Exadata. Forget for a moment that the design center for Exadata was DW/BI so the logical comparison would be to Greenplum. That’s saved for Part II. The problem with calling out EMC specifically is in doing so one tends to attract the attention of guys like me. You know, guys who know Exadata really, really well. I’m going to strive to choose my words carefully at this point as I’m sure Oracle did when they scooped all those words into slide 15.
In my assessment, Oracle used misleading information while poking the Slide 15 Stick™ at EMC. But not misleading in the manner you might expect. The misleading information isn’t what Oracle stated about the EMC product in the comparison. Instead, the misleading information is actually in under the Exadata column! So, I’ll call out these errata in the following list and then show the screenshot after that.
- Database IOs per second. This bullet grants a dubious 150,000 to “EMC Symmetrix” and clearly sets the stage for an OLTP-slanted comparison by citing the 1.5 million read IOPS (datasheet) capability for a single full-rack Exadata as per the information in the Exadata column. Don’t get me wrong, I don’t question the 1.5 million read IOPS capacity for 8KB random I/O because I held the position of Performance Architect in Oracle’s Exadata development organization for years and I’ve used my own test kits to get that many IOPS on my own Exadata lab gear. But stick with me for a moment. It’s really, really faulty marketing to pick random capabilities cited in the datasheet and plop them in a slide for your executives to present. The next row in the Exadata column cites a compression figure–and a Hybrid Columnar Compression (HCC) figure at that. Folks, Exadata cannot achieve the datasheet read IOPS figures (1.5 million) with compressed data—most particularly not HCC data. By citing the the 1.5 million read IOPS Oracle sets the stage that this is an OLTP/ERP-slanted comparison to EMC. After all, IOPS is not a DW/BI issue. So I’m scrutinizing the rest of the list from that position.
- Average Database Compression Factor. This is a new move for Oracle. I’ve not seen the claims for “average database compression” before. Generally, you’ll see wording such as “up to 10x compression” or “10x to 15x” compression when referring to the full HCC suite–which offers both query and archive compression. But, no matter. What you shouldn’t like about the claim of “average database compression” is the fact that Exadata is marketed as an OLTP machine yet HCC cannot be used for OLTP. So if you’ve bought Exadata for OLTP you’re probably wondering where your “average” 10x savings is. On the other hand, if you are using Exadata for OLTP, and wisely employing the only compression technology suitable for OLTP ( Oracle Advanced Compression (a.k.a, ACO) ) you are enjoying the same 2-4x compression you would have if your database was stored on any storage—even EMC! Imagine that. Oracle and EMC share tens of thousands of Oracle customers running OLTP or ERP and enjoying the same compression ratios across the board. So, stating zero for EMC in the compression class is, well, you know…
- Database bandwidth, high performance disks. This line in the table is bizarre. I know the Exadata bandwidth datasheet numbers by heart (shouldn’t come as a surprise). The full-rack X2 models with High Performance drives sustain 25 GB/s when scanning only the HDD disks. When scanning both HDD and flash cache concurrently the bandwidth number jumps to 75 GB/s—again, for a full-rack with High Performance drives. I can only surmise that the person who filled in this slide simply multiplied the HDD-only scan rate by the “average” compression factor (10x) to get 250 GB/s. That means the row should be called “effective bandwidth.” But then that isn’t the real problem I have with this point. The row is labeled “database bandwidth.” OLTP databases are databases and I assure you there is no 10x effective increase for OLTP, ERP database I/O bandwidth with Exadata because (and I can’t repeat this enough) there is no HCC for OLTP/ERP use cases. Perhaps the row should be called “HDD Effective Scan Rate” which has little to nothing to do with OLTP so I’m looping back to the 1.5 million read IOPS citation again.
- Database cache usable capacity. This one is really broken. First off, we all know that the “database cache” is first and foremost the Oracle System Global Area which all Oracle databases have regardless of the storage. That is the database cache. If the slide was meant to allude to “storage cache” then fine, let’s take it that way. The slide cites 53 TB for Exadata. Those are lovely characters and numbers but they don’t mean anything. The Exadata Storage Server (X2) has 384 GB of Exadata Smart Flash Cache in each of the 14 storage servers in a full-rack configuration. That’s 5,376 GB. I think, here again, the cited number is a mash-job of physical capacity and the DW/BI compression ratio commonly achieved with HCC (10x). The title of the slide is “Better than EMC for Database I/O.” OLTP databases are indeed databases and OLTP is not compatible with HCC compression. So, the information is…a foul.
So, as in the case of my America’s Cup racing foul example, I cry foul. It took me more than 42 seconds to do so though.
Here is Slide 15:
Kevin Closson's Blog: Platforms, Databases and Storage 
Kevin,
Brilliant post. My client was the very first Exadata customer in entire EMEA region. And there experience has not been very positive due to all the bugs and patching complexity. Now my client is thinking about Greenplum as well for their DW strategy. I guess, i better start learning Postgres now.
Hi Kevin,
I agree that some of the points in the above slide are questionable, especially
a) ‘Database bandwidth 250 GB/s’ and
b) ‘Database cache usable capacity 53 TB’
When we look at the (quite good & fair, IMHO) whitepaper about x2-8
Click to access 173705.pdf
we say 25 GB/s uncompressed raw disk bandwidth. So a) can only be done with scanning compressed data, as you pointed out already, while b) is on the Database Layer, not on the Storage Layer.
I do not think, though, that it is so unfair to list metrics that apply to OLTP and DW on the same slide.
We have indeed these impressive IOPS metrics (1.5 Million) on Exadata as well as impressive compression rates (higher than on the slide even, typically), and some customers will well have hybrid Databases where both is relevant, so why not quote that?
The unfairness is maybe in the fact, that we just offer HCC only on Exadata, although it would have been technically possible to do HCC on any storage. Zero for EMC is also not fair, because customers could use non HCC compression on EMC to achieve more moderate compression rates like 4 times.
On the bottom line, I think it is true that the Exadata Oracle DB/Hardware combination delivers the best metrics for OLTP & DW – although not necessarily on the same system simultaneously – compared to any other Oracle DB/Hardware combination that uses similar hardware. It just doesn’t sound so impressive without numbers 🙂