Comments on: SANs vs. DAS in MPP data warehousing

By: Ian

Ian — Thu, 28 May 2009 11:41:57 +0000

The most important thing IMHO is cost per MB/s of throughput. When you factor in how much it’ll cost you, SAN doesn’t get a look-in. I currently work on a system with total sequential throughput of 3 GigaBYTES per second which cost around USD 35,000. We costed out the same throughput on SANs – it would have worked out as 8 times more expensive.

You also can’t say that you’ll use enterprise infrastructure to deliver the performance without compromising performance service levels — after all, as soon as you use the Enterprise SAN, you’ve now got contention on fabric switches and any other shared components.

By: shshme

shshme — Thu, 21 May 2009 09:21:57 +0000

There is a good Cost Comparison at the site link above.

By: Infology.Ru » Blog Archive » Exadata: Oracle наконец отвечает бросившим вызов в области хранилищ данных

Thu, 09 Oct 2008 20:26:28 +0000

[...] SANs vs. DAS in MPP data warehousing [...]

By: Exadata and Oracle Database Machine parallelization clarified | DBMS2 -- DataBase Management System Services

Mon, 29 Sep 2008 06:03:40 +0000

[...] that follows this optimal storage-facing parallelization strategy. Actually, opinions differ as to whether rigid coupling of processors to specific disks is actually necessary. But after supporting one extreme (the disk part of shared-everything), Oracle with Exadata has [...]

By: Doug's Oracle Blog

Doug's Oracle Blog — Thu, 25 Sep 2008 18:16:33 +0000

Day 4 – Grumpy Old Man…

Well, I was starting to worry that I was completely out of step with the blogosphere, because finally a keynote presentation worth writing about and no-one seems keen, but I’ve only just noticed this quote in Pete Scott’s blog posting."For str…

By: Exadata: Oracle finally answers the data warehouse challengers | DBMS2 -- DataBase Management System Services

Thu, 25 Sep 2008 00:25:14 +0000

[...] SANs vs. DAS in MPP data warehousing [...]

By: Jeff Vogel

Jeff Vogel — Sat, 13 Sep 2008 22:12:39 +0000

Chuck,
Good to see you taking an interest in the DBMS subject of SANs. As to your comment regarding “pushing logic to the array”, EMC should be careful not to think about this in one dimensional terms of DBMS logic and it’s clearly not just about performance benefits. Given EMC’s early market leadership in creating SANs (Mike Ruettgers comes to mind), you wouldn’t want to be caught sleeping at the wheel of a multi-billions dollar market where storage management is concerned (-: Sorry for being somewhat elusive, but confidentiality is important.

By: How will SSDs get incorporated into data warehousing? | DBMS2 -- DataBase Management System Services

Sat, 13 Sep 2008 10:50:30 +0000

[...] visible Information Week blog post. After the great recent (and still ongoing!) discussion in the SAN vs. DAS comment thread, I’d like to throw some questions out for discussion, [...]

By: Curt Monash

Curt Monash — Sat, 13 Sep 2008 08:58:28 +0000

The sequential I/O issue, like most of the others here, is not trivial. If you’re mainly doing queries that access a lot of data, it’s possible for a large fraction of your query I/O to be sequential. If you’re doing pinpoint data lookup in some operational BI type of scenario, however, then you’re apt to be pretty random.

Even for analytical queries, the more complex your partitioning and/or schema, the harder it is to be purely sequential. And by the way, Luke has been giving me an earful recently about the breadth of Greenplum’s schema agnosticism and support for various index types.

As for updates — in many warehouse scenarios, even low-latency updates can be a lot more sequential than Chuck suggests. MVCC approaches lend themselves to sequential updating. Or if you’re on a once-every-few-minutes microbatch updating schedule, the whole thing is apt to be either pretty sequential or else so low-volume as not to be a major performance concern.

CAM

By: Curt Monash

Curt Monash — Sat, 13 Sep 2008 08:43:59 +0000

Here’s what I suspect is going on. The arguments for not sharing RAM and for not sharing disk are quite different. They’ve tended to be conflated, for historical reasons, in that the most archetypical vendors and products (Oracle, Teradata, Netezza, et al.) tended to be either ones that share both of those resource or ones that share neither of them.

Not sharing RAM saves you from all sorts of thread synchronization issues. Unless there’s something about multi-core evolution I’m not understanding, the case for not sharing RAM seems solid for the foreseeable future.

Not sharing disk, however, stems largely from bandwidth concerns in current SAN configurations and/or manufacturing cost concerns in custom appliance designs. Those arguments are lot less robust or future-proofed than the ones against sharing RAM, as is evidenced by the number of unshared-RAM MPP data warehouse DBMS providers who DO support SANs in theory and practice alike.

Sound reasonable?

Thanks for the great discussion,

CAM