Should this be summarized somewhere in our docs; just a few lines with the tradeoffs, direct storage = cheaper, faster, SAN = more configurable? --------------------------------------------------------------------------- Scott Marlowe wrote: > On Feb 13, 2008 5:02 PM, Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > > On Wed, 13 Feb 2008, Tobias Brox wrote: > > > > > What I'm told is that the state-of-the-art SAN allows for an "insane > > > amount" of hard disks to be installed, much more than what would fit > > > into any decent database server. > > > > You can attach a surpringly large number of drives to a server nowadays, > > but in general it's easier to manage larger numbers of them on a SAN. > > Also, there are significant redundancy improvements using a SAN that are > > worth quite a bit in some enterprise environments. Being able to connect > > all the drives, no matter how many, to two or more machines at once > > trivially is typically easier to setup on a SAN than when you're using > > more direct storage. > > SNIP > > > There's no universal advantage on either side here, just a different set > > of trade-offs. Certainly you'll never come close to the performance/$ > > direct storage gets you if you buy that in SAN form instead, but at higher > > budgets or feature requirements they may make sense anyway. > > I agree with everything you've said here, and you've said it far more > clearly than I could have. > > I'd like to add that it may still be feasable to have a SAN and a db > with locally attached storage. Talk the boss into a 4 port caching > SAS controller and four very fast hard drives or something else on the > server so that you can run tests to compare the performance of a > rather limited on board RAID set to the big SAN. For certain kinds of > things, like loading tables, it will still be a very good idea to have > local drives for caching and transforming data and such. > > Going further, the argument for putting the db onto the SAN may be > weakened if the amount of data on the db server can't and likely won't > require a lot of space. A lot of backend office dbs are running in > the sub gigabyte range and will never grow to the size of the social > security database. Even with dozens of apps, an in house db server > might be using no more than a few dozen gigabytes of storage. Given > the cost and performance of large SAS and SATA drives, it's not all > unlikely that you can fit everything you need for the next five years > on a single set of disks on a server that's twice as powerful as most > internal db servers need. > > You can hide the cost of the extra drives in the shadow of the receipt > for the SAN. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
