RE: Oracle Exadata Machine

From: Matthew Zito <mzito_at_gridapp.com>
Date: Fri, 15 May 2009 09:32:39 -0400
Message-ID: <C0A5E31718FC064A91E9FD7BE2F081B101D4B921_at_exchange.gridapp.com>



Sergey,

I'm no data warehousing DBA - I'm not much of a DBA at all, in fact. But we're not harping on the speed of the filesystem, per se, we're harping on the fact that the Exadata offers similar functionality to the Netezza without needing to migrate your database to an entirely new architecture.

I can't speak to star transforms, but for sorting, predicate exclusion, simple joins, etc. the Exadata architecture should be comparable to the Netezza in terms of raw throughput. Kevin Closson has done some research showing that for ETL activities, the Oracle Database Machine should scream past Netezza:

http://kevinclosson.wordpress.com/2009/03/17/no-proof-means-all-spoof-exadata-lags-competitor-bulk-data-loading-capability-really/

Obviously, he's biased, but he's a bright guy, so I tend to listen to him.

Of course it's a Rev 1 product, and sure there's uncertainty about the Oracle and Sun acquisition. But I could say similar things about Netezza:

- "Why would you trust your data warehouse to a $500m company?"
- "If they get bought by IBM or someone like that, they'll kill the product, and you'll have to port it to DB2"
- "How can they think they'll keep competing against Vertica, Greenplum, etc. when they're so much more expensive?"

Sales people for all of these companies get paid to spout these things - that's why we call it FUD. If Oracle is the right solution, use Oracle - if Netezza is the right solution, use Netezza.

Thanks,
Matt
--

Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito_at_gridapp.com
http://www.gridapp.com

-----Original Message-----

From: oracle-l-bounce_at_freelists.org on behalf of Sergey Popov Sent: Thu 5/14/2009 9:15 PM
To: oracle-l_at_freelists.org
Subject: Re: Oracle Exadata Machine  

I'm not understanding why everybody got stuck on Exadata I/O throughput. Just having a fast filesystem is not enough to guarantee lowest query execution time. How is it different from measuring performance using cache hit ration?

What's important is to have intelligent storage that does table joins, sorting and aggregation to minimize the final result set to be transferred to the DB host. What can Exadata offer from this prospective:
1) Row elimination based on a predicates received 2) Start transformation

I know for sure it does not have the following functionality: 1) Hash join
2) Merge join

Not sure about sorting and aggregation.

What Netezza offers on this department:

1) Predicate based row elimination
2) Hash join
3) Merge join
4) Sorting
5) Aggregation

All of that is happening at the storage level. The fact is as long as the data is distributed correctly there is no need to transfer huge result sets from storage to host to execute joins. Even with less than perfect row distribution Netezza does SPU-to-SPU re-distribution bypassing host all together. End of day join is a row elimination as well.

Netezza has partitions as all data is distributed either based on a hash (column) or randomly. There are materialized views but they can be created on a single table only and in fact look more like indexes or limited materialized result sets distributed on a different key. Netezza documentation is very limited compare to Oracle. Lots of command line utilities and shell scripts involved in administration. NZPLSQL is introduced in version 4.6 but performance is something. Inserting < 900 rows into a single column table in a loop takes minutes.

Most of us don't have worm and fuzzy feeling about Oracle release 1 products. Uncertainty in relationship with HP after SUN acquisition contributing to the slow adoption problem as well.

I never worked for either company. I work with Oracle products since '92 and just happened to have an opportunity to work with Netezza on my current project.

Sergey
--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Fri May 15 2009 - 08:32:39 CDT

Original text of this message