September 26, 2008
Oracle Exadata Smart Scan Join Processing
Oracle has put up an Exadata white paper (hat tip to Kevin Closson’s Exadata FAQ). There’s a section on Smart Scan Join Processing. Sounds exciting, huh? It reads, in its entirety:
Exadata performs joins between large tables and small lookup tables, a very common scenario for data warehouses with star schemas. This is implemented using Bloom Filters, which are a very efficient probabilistic method to determine whether a row is a member of the desired result set.
Jeez. That almost sounds as if Exadata is an immature, Release 1 data warehouse appliance!
Categories: Data warehouse appliances, Data warehousing, Exadata, Oracle
Subscribe to our complete feed!
Comments
14 Responses to “Oracle Exadata Smart Scan Join Processing”
Leave a Reply
This describes processing that can be done on the Exadata Storage Server. The Oracle Database Server connected to the Exadata Storage provides full parallel query processing.
Just how parallel is it? Are tables and intermediate result sets broken up by key value and sent to different processors to be joined in parallel at the same time?
[…] Oracle has put up in 22 page paper. The newly Exadata performs joins between large tables and small lookup tables, a very common scenario for data warehouses with star schemas. Read details […]
“Just how parallel is it? Are tables and intermediate result sets broken up by key value and sent to different processors to be joined in parallel at the same time?”
Yes, of course.
Kevin,
Thanks. I’m sorry to be conducted this discussion in blog comments and the like, but the last time Oracle briefed me on data warehouse DBMS, they — specifically Rita Sallam — said things very contradictory to what you all are saying now.
So should I assume that UDF execution is parallelized by the RAC cluster as well?
And just how much overhead is RAC causing in all this?
Thanks,
CAM
Kevin,
I should add — just how much manual intervention, if any, is needed to insure that the execution of a single query is parallelized among multiple nodes? E.g., is “In Oracle Real Application Clusters environments running on shared-nothing or MPP platforms, placing partitions on nodes is critical to achieving good scalability.” from http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10736/parpart.htm#i1006203 still accurate?
Thanks,
CAM
Curt, if you weren’t so overtly anti-Oracle biased you might have a more regular flow of information. That aside, you seem to be (often) confused about what the term MPP means to all the rest of us. You are that only one I know of who ignores the fact that MPP has never manditorily equated to shared-nothing. MPP isn’t a term relevant to only shared-nothing architectures as you routinely suggest. Oracle has run on shared-disk MPPs as well as shared-nothing MPP using proxy I/O (e.g., the old IBM SP2) dating back to Oracle Parallel Server in the late 1980s.
All mention of MPP in that documentation reference you cite have nothing to do with Exadata. When RAC is serviced by Exadata it is still shared-disk, but the Exadata Storage Servers are, indeed, shared-nothing. Disks in any architecture are shared-nothing. For instance, two disks in your beloved Thumper (GreenPlum) know nothing about each other. Two disks in a CX4-960 DAE drawer know nothing about each other. Disks and Cells in the Oracle Exadata Storage Server architecture know nothing about each other, but the Cells *do* know about the database(s). With Exadata, the datbase architecture (RAC) is shared-disk. The storage is shared-nothing.
I need to make a blog entry about that seemingly confusing mention of MPP in that documentation reference in spite of the fact that it is 10g doc. I do see how that would be confusing to people who are unaware of the fact that Oracle works on MPP systems although at this point I think that is mostly historical (e.g., Siemens/Pyramid, nCube, etc).
As long as things don’t get ugly, and you remain honestly curious I will enrich your blog comment threads. I do think that “Release 1/immature” comment in your other recent post was a bit of a farce. Isn’t all Release 1 product in every industry “immature” by definition? Do you think we’ll never check in another line of code?
Kevin,
Please don’t lecture me about my relationship with Oracle. I’ve been accused of being biased in favor of Oracle many times since I first met Bob Preger and then Larry Ellison 25 1/2 years ago. I’ve been accused of being biased against Oracle about as many times in the same period. Sometimes I’ve been accused of both the same week. And I’ve communicated offline with more than one Oracle person recently who’s a heckuva lot more senior than you. It wasn’t in time to get me properly briefed yet, but I’m optimistic — albeit not certain — things will get back on track soon.
As for your last comment — I continue to be amazed at how people can misread the simplest things. *I* was the one pointing out that Exadata had the immaturity of a Release 1 product.
As for your other comments — you seem to be lecturing me about details of Oracle’s product naming that only were disclosed a few days ago. Frankly, I don’t give a hoot as to whether the RAC Cluster plus the storage server is officially called “Exadata” or — as is actually the case — just the storage server is offically called “Exadata”. The one-word common-consensus name for the technology will wind up being “Exadata” and the two-word common-consensus name for the technology will wind up being “Oracle Exadata”. “Exadata” is Oracle’s competitor to “Teradata”, “Netezza” (not NPS or NPS 10-800), “Greenplum”, “Aster” (or “Aster Data”, but not “nCluster”), et al. Longer names — except when they contribute precision to discussions on topics such as pricing or data flows — are just a waste of pixels.
Now, as for MPP, shared-nothing, etc. — if you have a catchy, industry-standard phrase for “shared disk, unshared RAM” I’d love to hear it. I’m not aware of any.
Thanks,
CAM
Curt,
You have gotten the last word.
Kevin,
You say above “You are that only one I know of who ignores the fact that MPP has never manditorily equated to shared-nothing.” Well, quite apart from whether or not I actually ignore that (which I usually don’t), http://www.oracle.com/technology/products/bi/db/11g/pdf/twp_bidw_parallel_execution_11gr1.pdf says “In a shared nothing system CPU cores are solely responsible for individual data sets and the only way to access a specific piece of data you have to use the CPU core that owns this subset of data; such systems are are also commonly known as MPP (Massively Parallel Processing) systems.”
Perhaps you should introduce yourself to your colleagues who were involved in writing that. I believe some of them are involved in Parallel Query, and at least one is known to me to be an extremely smart person.
Or perhaps you should just continue the extremely popular — and deservedly so — work you do explaining Oracle’s technology, while dialing down the volume of personal attacks.
CAM
Curt,
It is a shame it had to go this way. I have made no personal attacks on you. Read the thread. It is a ***professional*** attack for me to point out your error when you continue to insist that MPP must be shared-nothing to be MPP. I’ve tried to point out that there is commonly accepted middle ground which has ALWAYS been the requirement for Oracle on MPP and that is either direct, parallel I/O connectivity to storage or proxy I/O. That is, shared-disk. Yes, even with an MPP.
You throw Oracle documentation references to me to shore up your assertion that MPP == shared nothing and I’m telling that Oracle has always required access to the ENTIRE database by all instances, again, be it by proxy I/O or direct-parallel I/O (as was implemented by the better of the age-old Oracle-supported MPP platforms).
Oracle is shared disk architecture and when it runs on an MPP it either needs physically “cabled” direct access to all disk or the illusion of same via message-passing proxy I/O. Some OPS platforms supported proxy, others worked out switches for point-to-point I/O but in the end Oracle gets shared disk. This is why those old docs you pointed to discuss the idea of physical partitioning because in a proxy I/O implementation certain instances of Oracle would have a direct physcial I/O path to a given block of the database but other instances would have to route a proxy I/O…but in the end both instances “see” the entire database and that is a shared-disk architecture.
You said, “So should I assume that UDF execution is parallelized by the RAC cluster as well? And just how much overhead is RAC causing in all this?” which indicates you don’t know RAC. And that, Curt, is also not a personal attack. Queries are parallelized across instances for free, without physical partitioning of the data. In today’s world RAC only runs on directly connected shared disk architectures regardless of how massivley parallel it might be. That takes us full circle to Exadata.
I think the HP Oracle Database machine with the maximum single-switch scale out would be considered MPP (based on sheer CPU count alone), but RAC, as Oracle Parallel Server before it, requires the all instances have “connectivity” to all blocks of data in the database–shared disk! That’s how it was on nCUBE, Pyramid RM1000 and every other MPP of the day.
I should have handled this in a blog post because I do understand your confusion.
Kevin wrote “It is a shame it had to go this way. I have made no personal attacks on you. Read the thread. It is a ***professional*** attack for me to point out your error when you continue to insist that MPP must be shared-nothing to be MPP”
It’s not personal, you are out just of your league, Kevin. Curt is a light year ahead of you.
Let’s try to calm the waters here.
1. It is rarely productive to debate semantics, grammar, and so on on the Internet. And that was true even before the proliferation of people for whom English isn’t their native language. (The passage I quoted above from the Oracle document actually has a grammatical error. But so what? I can’t speak other people’s native languages NEARLY as well as they speak English.)
2. When it’s absolutely necessary to debate semantics — as Kevin evidently feels it is in the case of “MPP” and “shared nothing” — it should be done very, very carefully.
3. Example of what can go wrong: Kevin completely misread my “immature, Release 1” comment, perhaps because he forgot what a comma means. Or perhaps he uses commas differently than I do. Either way, he attacked me — “personally” or “professionally” as the case may be — over a comma.
4. It is almost always a bad idea to insist that terms have one and only one precise meaning. I frequently cite the marketing fact — aka Monash’s First Law of Commercial Semantics — that “bad jargon drives out good.” Meanings evolve; that’s just a fact of life.
5. It’s a particularly bad idea to assert that everybody uses a term one way when in fact your own employer uses it a different way. 😉
6. I don’t think that Kevin’s distinction between “personal attack” and “professional attack that uses loaded words like ‘biased'” is a clear or useful one. But as noted above, people can disagree about semantics.
7. Kevin has been working nonstop AND putting up a ton of blog posts over the past week. He should be excused for being a bit cranky, or for misreading the occasional turn of phrase.
And by the way, I WAS wrong about the division of labor between Oracle RAC and Oracle Parallel Query.
CAM