On Tue, Sep 7, 2010 at 1:36 PM, Craig James <craig_james@xxxxxxxxxxxxxx> wrote: > On 9/7/10 12:06 PM, Jesper Krogh wrote: >> >> On 2010-09-07 20:42, Scott Marlowe wrote: >>> >>> With the right supplier, you can plug in literally 100 hard drives to >>> a regular server with DAS and for a fraction of the cost of a SAN. >> >> Ok, recently I have compared prices a NexSan SASBeast with 42 15K SAS >> drives >> with a HP MDS600 with 15K SAS drives. >> >> The first is 8gbit Fibre Channel, the last is 3Gbit DAS SAS. The >> fibre channel version is about 20% more expensive pr TB. >> >> So of course it is a "fraction of the cost of a SAN", but it is a >> fairly small one. > > Are you really comparing equal systems? "8gbit Fibre Channel" means a > single Fibre Channel shared by 42 disks, whereas "3GBit DAS SAS" means 42 > 3gbit channels running in parallel. It seems like you'd really need some > realistic benchmarks that emulate your actual server load before you'd know > how these two systems compare. Well, not usually. Most SAS DAS systems use a single multi-lane cable that gives you 4x3GB channels, etc. However, unless you're doing little than sequentially scanned reports of a large size being read, the difference between 8gb and 3gb is not going to matter. There are lots of very hard working transactional databases that are lucky to see more than 20 or 40 megabytes a second getting trasnferred spread out over 30 or 40 drives. What really matters here is if the 8gb SAN is as fast as or faster than the DAS setup. For most people measuring the speed of the interface is a lot like the famous Tom Lane quote about benchmarking jet fighters versus airliners by measuring the amount of runway they need. If you can get 10k tps on the SAN and 10k tps on the DAS So to the OP, what are hoping to get from the SAN that you won't get from the DAS? Also, how reliable are these two in comparison to each other is kinda of important. Speed of the interface isn't a real big deal for a database server Size of the battery backed cache in each one is And how each survives the power plug pull test. If your SAN salesman balks at a power on test you don't have to run it, you'll know. -- To understand recursion, one must first understand recursion. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
