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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
