From: | Paul Sheer <paulsheer(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Hadoop backend? |
Date: | 2009-02-23 14:08:42 |
Message-ID: | c67e3dc60902230608x12fd290dqc369b667ddb5b92f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> It would only be possible to have the actual PostgreSQL backends
> running on a single node anyway, because they use shared memory to
This is not problem: Performance is a secondary consideration (at least
as far as the problem I was referring to).
The primary usefulness is to have the data be a logical entity rather
than a physical entity so that one can maintain physical machines
without having to worry to much about where-is-the-data.
At the moment, most databases suffer from the problem of occasionally
having to move the data from one place to another. This is a major
nightmare that happens once every few years for most DBAs.
It happens because a system needs a soft/hard upgrade, or a disk
enlarged, or because a piece of hardware fails.
I have also found it's no use having RAID or ZFS. Each of these ties
the data to an OS installation. If the OS needs to be reinstalled, all
the data has to be manually moved in a way that is, well... dangerous.
If there is only one machine running postgres that is fine too: I can have
a second identical machine on standby in case of a hardware failure.
That means a short amount of downtime - most people can live
with that.
I read somewhere that replication was one of the goals of postgres's
coming development efforts. Personally I think hadoop might be
a better solution - *shrug*.
Thoughts/comments ??
-paul
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-02-23 14:35:01 | Re: Hadoop backend? |
Previous Message | Bruce Momjian | 2009-02-23 13:45:20 | Re: 8.4 features presentation |