HP and Violin build Oracle Exadata killer

Exadata Killer

By my assessment the HPDBS (DL980 + Violin solution) is likely not positioned as an Exadata killer for bandwidth-sensitive DW/BI workloads. It simply doesn't have enough high-bandwidth storage plumbing. On the other hand, a single-rack Exadata only supports a scalable read:write ratio of 40:1 (their data sheet 1,000,000 RIOP : 50,000 WIOPS). Actually, that 50,000 WIOPS is a gross number accounting neither for redundant writes (ASM redundancy) nor the larger sequential writes that a transaction processing system also must concurrently sustain. In other words, mileage varies (downward trend).

kevinclosson.wordpress.com

Voices...

What exactly is exadata?

I get more and more confused each day. 8 Node Database Cluster, with Spinning Media, and Flash.

I am not discounting the Exadata Software, just looking at what the elements are.

You go to Oracle's website and you buy all of these items, you build this Hardware mirror to the DB Machine. Your clustering skills are bit rusty, so you hit the RAC SIG to get the latest tweaks.

Is this Exadata?

You say no, you have to have the Software, ok you get the software and install it.

What do you have?

As the owner of the report, the website, the application, the Business unit et. al. I just see a database, not the bandwidth, not the latency, or cluster cost or parallel execution, smart scan offloading, etc.

I just notice that what took an 1hour now takes less time, maybe 2x, 10x faster etc.

Do I really care what delivered it faster?

Take a look at the HP gear, it is not reinventing the storage tier, is is simply offering something that goes faster, that delivers that report, that web session, that response faster.

Hilarious!

Hilarious! "The infamous write cliff?" What are they talking about - consumer SSD drives from three years ago? It's such an infamous thing that they just made it up?

Maybe other people have that problem but we certainly don't. Off the top of my head I can think of one my customers pushing 2TB/day through a 1.5TB appliance with no "write cliff".

I swear, the bigger they are, the DUMBER they are. How any of these multi-billion dollar IT firms have any credibility is beyond me...

Texas Memory Systems responds

Sent to me by TMS:-

There are a few things that are not presented clearly in the write performance comparison from the slide deck that you uncovered and I thought it might be helpful to shed some light on this. Flash chips need to have entire blocks (256 KB) written and erased at the same time. Since applications write in smaller chunks than this there is some over-provisioned capacity and between the host and the flash chips is something called a Flash Translation Layer. I’ll try to summarise the details of dealing with the writes here. For more information, SNIA’s Solid State Storage Initiative’s performance test specification goes into quite a bit of depth: http://www.snia.org/forums/sssi/knowledge/education/SSS_PTS_Whitepaper_Nov2010.pdf

The Flash Translation Layer keeps an index of where a block is physically written and the logical address that is presented to the host. After a continuous small block random write workload, eventually there are not any pre-erased blocks available to write to. The flash controller has to perform “moves” of data from a few blocks that have some valid data and some stale data. These moves are performed to get a few completely full blocks and a new empty block to write to. A move operation ties up the chip and is just a little less work than a write. The amount of over-provisioned capacity determines how many background moves you will have to perform for each new write that comes in under the worst possible scenario. On the RamSan-20 datasheet http://www.ramsan.com/files/download/589 we list this number for our random writes: 50,000 IOPS. Outside of this worse case, we can achieve 160,000 write IOPS.

In many ways the sustained number is not terribly important to real-world applications as anytime that you are not doing 100% random writes a good flash controller will perform background move operations to defragment the valid and stale data. To get to the worst case, you have to randomly write across all of the capacity and more without ever stopping to read. While some logging applications have this type of constant write workload they are never random.

So that brings us to the interesting question: can a flash controller be designed that doesn’t have this drop off in performance? Absolutely – you merely need to have more chips on the backend than the frontend can drive. That means that for most workloads you have idle chips. Notice that in the comparison from the presentation, a 10 TB flash chassis (8 TB after over provisioning) is being compared to the performance of single PCIe cards with 450 GBs or less. If you multiply the performance of any one of the cards presented below by ratio of their capacity to 8 TBs that they are being compared to, every single one beats the 1.4 GB/s that is provided by Violin.

Texas Memory Systems had to ensure we had a fast enough front-end on our high-capacity RamSan-630 system to drive all of the chips that are available in 10 TBs of flash (after over provisioning). That is why we support ten QDR InfiniBand (40 Gbps each) or ten 8 gbps FC ports and can supply over 10 GB/s of bandwidth from a single 3u system. Flash is still quite a bit more expensive than disks, so adding capacity without adding the front end performance doesn’t serve customers well.

------------------------

Thanks TMS!

Technical criticism is here:

There are several single point of failure stuff. You need clusters to support 24/7.

Here is some relevant technical critisicm:

http://www.c0t0d0s0.org/archives/7256-It-takes-more-than-a-rack,-some-flash-and-a-server-to-kill-an-Exadata-system.html