From: | "Gordan Bobic" <gordan(at)freeuk(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Database cluster? |
Date: | 2000-12-01 09:05:33 |
Message-ID: | 005601c05b75$df0dd1e0$8000000a@localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > I actually analyzed it once. I came to the conclusion that to do it
right
> > it would be easier to make an almost entirely new db but use the same
> > external interfaces as PostgreSQL. To do a kludge of it, one might
just
> > implement a tier that sits between the user and a bunch of standard
> > PostgreSQL backends.
> >
> > It'd make a neat companion project, though. Like PG/Enterprise or
> > PG/Warehouse or something.
>
> I'm currently developing a simple version of such a system as an
> university project. It is a fairly simple aproach with a proxy or a
> distributor in front of a bunch of standard postgresl database servers.
>
> The proxy monitors and forwards the requests from the clients to the
> database servers. If it is a read-only request the query is forwarded to
> the databaseserver currently experiencing the lowest load/most free
> memory, otherwise it is sent to all database servers.
Surely, you have to send off a query to all servers that the specific
tables you are searching are split across. How are you handling splitting
of the data?
> This approach obviously only performs well in systems with a high ratio
of
> read-only queries, such as search engines and so on.
This implies lots of servers with identical data on them. Am I right?
Could you tell us a bit more about your project (if it's not breaching any
non-disclosure agreements, that is)? It could be a good starting point for
what we are talking about implementing.
Regards.
Gordan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Korsgaard | 2000-12-01 09:31:45 | Re: Database cluster? |
Previous Message | Gordan Bobic | 2000-12-01 08:58:58 | Re: Database cluster? |