From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Partitioning Vs. Split Databases - performance? |
Date: | 2006-12-24 17:00:16 |
Message-ID: | 200612241702.kBOH238Y068026@smtp5.jaring.my |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 08:12 AM 12/22/2006, Joshua D. Drake wrote:
>
> > With One Big Database, you can get a SAN and attach a whole lot of
> > disk space, but your mobo will only accept a certain number of DIMMs
> > and processors of certain designs. And when your growing mega
> > database maxes out your h/w, you're stuck.
>
>Define mega... Because you would need to be in the multi-terrabyte
>range.
Why multi terabyte? All that needs happen is for the hardware to run
out of I/O. Nowadays with the sizes of disks, you can run out of I/O
way before you run out of space.
It could start to take way too long to backup/restore the entire database.
If your app lends itself to horizontal scaling and you think you will
need to scale to more than say 5X, its better to scale horizontally
than go vertically (get a bigger box).
Has clustering technology advanced to the point where making a
"bigger box" can be done easily and cheaply with just many small
boxes? I've seen stuff like OpenSSI etc, but how well does Postgresql
run on such stuff? Shared memory is usually slow/problematic on such systems.
Regards,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Shoaib Mir | 2006-12-24 17:29:41 | Re: Partitioning Vs. Split Databases - performance? |
Previous Message | Ben | 2006-12-24 05:35:42 | Re: tape backups |