On 24/02/2011 10:59 AM, Kalai R wrote:
> We are going to design database for a large company with multi branches.
> I am using PostgreSQL
>
> For example,
>
> I create a single database for all branches. After 10 years, database
> size is too large.
Oh yeah, for what it's worth: my employer has 10-year-old database
stored in a shared-access ISAM-variant database last updated in 1983,
running on a scary old SCO OpenServer 5.0.5 machine that runs the
software in a Microsoft Xenix (1895) personality. Despite the total
inability to maintain the database or the runtime its self, the app's
performance has IMPROVED over time because the hardware has become so
much faster. Most recently, I moved it from physical hardware into a
VMWare container, at which point it began benefiting from Linux's
efficient use of lots of RAM for caching (something SCO is terrible at)
and more than quadrupled in speed. Operations that used to take an hour
when the system was first deployed in 1991* now take less than a minute.
About the only significant scaling design choice made in the original
software was the decision to partition the biggest table into history-
and live- sections. That alone has preserved performance to a more than
satisfactory level.
If we can get that kind of result with a scary ancient monster, it's
possible you'll be OK. On the other hand, said scary ancient monster
just doesn't collect that much data... and that makes a big difference.
* Yes it's insane to write a mission-critical system in 1991 using a
closed source runtime that was abandoned and dead in 1983. It was before
my time at the company, which just means I get to suffer through
maintaining the damn thing while trying to replace it.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
