Re: tablespaces and DB administration - Mailing list pgsql-hackers

From Darcy Buskermolen
Subject Re: tablespaces and DB administration
Date
Msg-id 200405271650.11598.darcy@wavefire.com
Whole thread Raw
In response to Re: tablespaces and DB administration  (pgsql@mohawksoft.com)
Responses Re: tablespaces and DB administration
List pgsql-hackers
On May 27, 2004 01:38 pm, pgsql@mohawksoft.com wrote:
> > pgsql@mohawksoft.com wrote:
> >>As you can see, it takes a LOT longer. That's because the disk has to do
> >> a
> >>lot more work, the hardware data path has to carry twice as much data,
> >> and
> >>you have to manage multiple accesses to a single object, the disk.
> >>
> >>It doesn't take much imagination to see what this would mean for pg_xlog.
> >
> > Well, writing off-reality benchmarks on hardware setups I'd never
> > suggest for db server usage proves... what?
> > Additionally, do you care about safety?
> >
> > Regards,
> > Andreas
>
> It was a demostration of the effect that multiple drives has. There is a
> very real and measurable I/O bandwidth advantage to be gained by putting
> concurrently accessed data on separate data channels. Any test that is
> capable fo utilizing multiple I/O channels will show it.
>
> This is not the place to really discuss this, and if you want to persue
> this discussion, lets take it off line.
>
> As for RAID5, it has its advantages, as does RAID0 and RAID3, and yes,
> RAID1 and higher are pretty safe. A *good* RAID system goes for thousands
> or tens of thousands of dollars. A 24x7 redundant storage system may not
> be required by everyone. With new IDE with DMA interface cards, it should
> be possible to create a very high performance system. A system which will
> perform better if the pg_xlog is on a different disk than the data.
>
> As for "do I care about safety?" Yes, yes I do, but "safe" and "paranoid"
> are two different things. There is always a cost/benefit analysis for any
> system. RAID5 and RAID3 are calculated risks. The bet is that no more than
> one drive will fail at any one time. It is a good bet, but not 100%. I've
> seen RAID systems have two drive failures at the same time, during the
> auto-rebuild to the spare, a second drive dies. Game over.
>
> Since RAID5 is a risk, maybe we should mirror, RAID0+1. That's a risk too,
> what if the two mirrored drives die? Yikes, then you're screwed again.
>
> If you want to be safe, you may want RAID5+1, where you mirror two RAID5
> systems. That's really safe. You should have each RAID5 system on its own
> controller with its own independent battery backed up redundant power
> supply. That will be safe. Wait.. What about earth quakes? Shock mounted
> racks. Lightning? Surge suppressors on the SCSI cables. Flood? Wrap it in
> a zip-lock bag. Al Qaeda? Wrap it in a kevlar!!
>
> There is a cost/benefit analysis for everything. RAIDs are very good and
> reasonably safe devices, but the argument that the performance will be the
> same as multiple individual disks (which are equivilent to the ones in the
> RAID) preferably on different I/O channels is proveable nonsense and you
> should know that.

One other huge advantage that tablespaces will bring, it the ability to place 
data based on "cost" ie, you can put your 10 most used tables on fast disk 
(or perhaps solid state devices), and move the seldom used data off onto the 
slower (lower cost) disks/storage array. 



-- 
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com


pgsql-hackers by date:

Previous
From: pgsql@mohawksoft.com
Date:
Subject: Re: tablespaces and DB administration
Next
From: John Hansen
Date:
Subject: Re: How to get the Oid of the Primary key relation ??