Re: High volume inserts - more disks or more CPUs?

Поиск
Список
Период
Сортировка
От Lincoln Yeoh
Тема Re: High volume inserts - more disks or more CPUs?
Дата
Msg-id 5.2.1.1.1.20041213171532.02c538b8@localhost
обсуждение исходный текст
Ответ на High volume inserts - more disks or more CPUs?  ("Guy Rouillier" <guyr@masergy.com>)
Список pgsql-general
--=======174A76C=======
Content-Type: text/plain; x-avg-checked=avg-ok-15674D89; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

At 12:16 AM 12/13/2004 -0600, Guy Rouillier wrote:

>(3) If we go with more disks, should we attempt to split tables and
>indexes onto different drives (i.e., tablespaces), or just put all the
>disks in hardware RAID5 and use a single tablespace?

Fast inserts = fast writes.

RAID5 = slower writes.

You may wish to consider mirroring and striping aka RAID10... With a 4 disk
array, reads could be 4X faster and writes could be 2X faster compared to
single disk (assuming decent RAID controllers or RAID software). For the
same number of disks, RAID5 would be slower than RAID10 but RAID5 will have
more storage capacity. RAID10 would have slightly better redundancy - if 2
out of 4 of the right disks fail, you could still have all your data :).

If the insert performance is more important then go for more disks over
more CPU.

If the read queries are more important than the insert performance AND the
queries are likely to fit within RAM, then more CPU could be better.  If
you're not doing lots of fancy queries and the queries don't fit in 16GB,
then go for the 50% more disks (6 vs 4).

But I'm not a DB consultant ;).

Regards,
Link.




--=======174A76C=======--


В списке pgsql-general по дате отправления:

Предыдущее
От: Janning Vygen
Дата:
Сообщение: Re: table with sort_key without gaps
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: Substring question