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:
- If we believe Oracle’s claims of 10X compression, Exadata 2 costs more per terabyte of user data than Netezza TwinFin — $22-26K/TB vs. TwinFin’s <$20K — but less than the Teradata 2550.
- These figures are highly sensitive to assumptions about Oracle’s hybrid columnar compression.
- Similarly, if Netezza or Teradata were to significantly upgrade their own compression, the price comparison would look quite different.
- Options such as Data Mining or Oracle Spatial add 12% or so each to Exadata’s total system price.
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:
- Similar overall pricing
- Twice the disk capacity
- Better compression
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:
- The re-usability of Oracle licenses on other hardware. Most of Exadata’s cost is either for hardware, or for server software that’s priced on a per-core basis. Neither of those is going to manage much (or any) more data three years from now than it can today.
- What Oracle claims as pricing metrics. Oracle’s comments on Exadata pricing generally sow confusion, which is why I do my own spreadsheets.
Related links
- The hunt for Oracle Exadata production references (but hopefully some will be revealed at Oracle Open World)
- A favorable rumor about Exadata sales
- Issues in integrating OLTP and data warehousing in a single system
- James Kobielus of Forrester tweets that there are “plenty” of pleased Exadata users
- More on Oracle Exadata hybrid columnar compression
Comments
13 Responses to “Oracle Exadata 2 capacity pricing”
Leave a Reply
I believe that hybrid columnar compression is a exadata only feature: http://blog.tanelpoder.com/2009/09/01/oracle-11gr2-has-been-released-and-with-column-oriented-storage-option/
Interesting. Thanks!
That should slow things down, however, in gathering data about how the compression performs in real life.
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.
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
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/
I read the incorrect Oracle document more recently than Kevin’s blog, and forgot the conflict between them. My bad. Corrected above.
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 ).
The only pricing metric that the industry has unanimously settled on is dollars per purchase order.
Everything else is up for grabs.
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 🙂
@ 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.
[…] my recent post on Exadata pricing, I highlighted the importance of Oracle’s compression figures to the discussion, and the […]
>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/
@apex. Kevin corrected this on his post. It can exist in the cache in compressed form