October 5, 2009

Oracle Exadata 2 capacity pricing

Summary of Oracle Exadata 2 capacity pricing

Analyzing Oracle Exadata pricing is always harder than one would first think. But I’ve finally gotten around to doing an Oracle Exadata 2 pricing spreadsheet. The main takeaways are:

Longer version

When Oracle introduced Exadata last year it was, well, expensive. Exadata 2 has now been announced, and it is significantly cheaper than Exadata 1 per terabyte of user data, based on:

Compression is the big question mark. Row-based DBMS vendors have traditionally been, if anything, conservative in their compression claims, although Netezza recently went with a not-sandbagged 2.25X compression estimate to get below the $20K/terabyte price point. Columnar software vendors have tended to be more aggressive, with figures of 10X or more casually thrown around, or 40-50X for archival storage. But since columnar vendors sell mainly on a software-only basis, those claims haven’t generally shown up in per-terabyte total system cost comparisons, which most commonly focus on data warehouse appliance product lines.*

*Kickfire, the one columnar pure-play appliance vendor, hast to date been quite conservative in its compression marketing claims.

Oracle, however, recently announced a feature called hybrid columnar compression, and is now making compression claims with the usual columnar grandiosity. Oracle’s story is 10X compression, and they’re sticking to it, perhaps because 10 is such a nice round number.* Since Oracle hybrid columnar compression is part of 11g Release 2, and isn’t Exadata-specific, wWe can hope to eventually get a sense from the field of what levels of compression are actually realistic. (Edit: Actually, it seems that hybrid columnar compression only works with Exadata, at least at this time.) But for now, we don’t have much to go on except Oracle’s claims.

*Greg Rahn of Oracle tweeted me yesterday that one customer is getting 12-17X compression on “dimensional model” data. That sounds comparable to Vertica’s claim of 20X on “marketing analytics” and 30X on “consumer data” datasets.

Based on 10X compression (vs. Netezza’s 2.25X and Teradata’s lower figure), Oracle Exadata 2 is somewhat more expensive than Netezza TwinFin, and significantly cheaper than Teradata’s 2550. Specifically, Oracle Exadata 2 comes in around $22K/TB of user data for a full rack, and $26K/TB for a quarter rack, which is the Exadata 2 configuration more comparable to a TwinFin rack in user data capacity. This is if you look at the Exadata hardware version that uses 600 GB SAS drives (vs. 1 TB SAS drives for TwinFin and 300 GB SAS drives for Teradata). With 2 TB SATA drives, at the same system pricing, Exadata prices are 70% lower, getting down to $6K/TB for a full rack. You can see how I got these figures on my Oracle Exadata 2 pricing spreadsheet linked above.

Obviously, price/terabyte is just one metric. Throughput is often even more important, but also is a lot harder to quantify simply. Oracle Exadata 2 offers more raw I/O than Netezza TwinFin. Netezza TwinFin, with its FPGA-based pipelining, probably has more processing oomph than Oracle Exadata. Oracle’s compression could lead to better use of RAM cache. And so it goes.

Meanwhile, two factors that in my opinion don’t matter much to the analysis are:

Related links

Comments

13 Responses to “Oracle Exadata 2 capacity pricing”

  1. RC on October 5th, 2009 9:45 am
  2. Curt Monash on October 5th, 2009 10:09 am

    Interesting. Thanks!

    That should slow things down, however, in gathering data about how the compression performs in real life.

  3. Michael McIntire on October 5th, 2009 12:32 pm

    We should stop talking about compression comparisons with vendors. yes – every product needs to do compression. Problem is that it is a data dependent problem. Columnar databases for example, can do absolutely nothing with an extremely high cardinality unstructured text column (nearly all web data – like URL Arguments), and row stores can do little outside of generalized compression with low-mid cardinality columns.

    Maybe the simplest thing to do – since most all implementations appears to be sensitive to cardinality at one end or the other – is to derive a simple cardinality metric, and apply that to each compression claim (TPC – are you listening???)

    In the end, I think we need to start focusing on benchmarking frameworks which make it simple for consumers to subset their data and queries in realistic ways – because until you actually stuff your data in a product with measurable results, these claims are wildly untrue for everyone.

  4. RC on October 5th, 2009 2:52 pm

    It seems that columnar hybrid compression was present in the non-exadata 11gr2 beta release but is omitted in the non-exadata production release: http://guyharrison.squarespace.com/blog/2009/9/2/columnar-compression-in-11gr2.html

  5. Bence Arató on October 5th, 2009 4:07 pm

    Oracle’s Kevin Closson explicitly states in his blog that the hybric compression method only available with Exadata storage:

    “Oracle Database 11g Release 2 does not offer column-store technology as thought of in the Vertica (for example) sense. The technology, available only with Exadata storage, is called Hybrid Columnar Compression. The word hybrid is important.”

    http://kevinclosson.wordpress.com/2009/09/01/oracle-switches-to-columnar-store-technology-with-oracle-database-11g-release-2/

  6. Curt Monash on October 5th, 2009 4:09 pm

    I read the incorrect Oracle document more recently than Kevin’s blog, and forgot the conflict between them. My bad. Corrected above.

  7. Jerome Pineau on October 5th, 2009 6:54 pm

    Oracle pricing is still indeed “rocket science”! Has the industry pretty much settled on this $/TB metric or do I get a feeling it’s not a satisfactory or sufficient measure still? What is you had a database that priced dynamically based on query complexity and/or depth? Has anyone every tried something like that? Just curious as this pricing business is all very flaky to me (that’s just me of course ).

  8. Curt Monash on October 5th, 2009 7:05 pm

    The only pricing metric that the industry has unanimously settled on is dollars per purchase order.

    Everything else is up for grabs.

  9. Jerome Pineau on October 5th, 2009 9:05 pm

    I always found the per-TB model to be questionable. Kinda like paying more for Word depending on how many documents you’ll be handling. It seems to me, unless you know fairly precisely how much data you will ingest incrementally, it’s impossible to properly map your costs over time. And I don’t understand either how this pricing changes (if at all) periodically say every year. Do vendors do some sort of audit every 12 months or something? I don’t know how they manage to control this. Sorry for the naive questioning; no one’s ever been able to explain this to me before in any way that made sense 🙂

  10. rnm1978 on October 6th, 2009 3:54 am

    @ Jerome – isn’t the metric for comparison of vendor’s pricing, rather than a pricing tool for a specific implementation? I don’t think the suggestion is that Oracle or Netezza will come and weigh your data and then give you a price, rather that knowing you have a 50Tb DW and are looking for a shiny new toy you can get a (very) rough idea of how much it’s going to cost you from the different vendors and/or how they compare to each other.

  11. Oracle and Vertica on compression and other physical data layout features | DBMS2 -- DataBase Management System Services on October 6th, 2009 8:19 am

    […] my recent post on Exadata pricing, I highlighted the importance of Oracle’s compression figures to the discussion, and the […]

  12. Apex on October 7th, 2009 2:16 am

    >Oracle’s compression could lead to better use of RAM cache. And so it goes.
    Actualy it is not fuly true. Data in Oracle DB Cache exists in uncompressed form only.
    “In the meantime I need to point out that data flows from the intelligent storage grind into the database grid in uncompressed form when Oracle Exadata Storage Server cells are scanning (Smart Scan) Hybrid Columnar Compression tables. So, the DRAM cache capacity of the database grid is an aggregate 400 GB. *Note: Please see the blog correction above regarding how this DRAM cache is populated to achieve the advertised, effective 10TB capacity.”
    http://kevinclosson.wordpress.com/2009/09/24/sun-oracle-database-machine-cache-hierarchies-and-capacities-part-0-i/

  13. Shrikanth on October 7th, 2009 2:17 pm

    @apex. Kevin corrected this on his post. It can exist in the cache in compressed form

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.