Re: postgresql clustering
От | Tino Wildenhain |
---|---|
Тема | Re: postgresql clustering |
Дата | |
Msg-id | 433BEEB8.4080508@wildenhain.de обсуждение исходный текст |
Ответ на | Re: postgresql clustering ("Daniel Duvall" <the.liberal.media@gmail.com>) |
Ответы |
Re: postgresql clustering
|
Список | pgsql-hackers |
Daniel Duvall schrieb: > While "clustering" in some circles may be an open-ended buzzword -- > mainly the commercial DB marketing crowd -- there are concepts beneath > the bull that are even inherent in the name. However, I understand > your point. > >>From what I've researched, the concepts and practices seem to fall > under one of two abstract categorizations: fail-over (ok... > high-availability), and parallel execution (high-performance... sure). Well, I dont know why many people believe parallel execution automatically means high performance. Actually most of the time the performance is much worser this way. If your dataset remains statically and you do only read-only requets, you get higher performance thru load-balancing. If howewer you do some changes to the data, the change has to be propagated to all nodes - which in fact costs performance. This highly depends on the link speed between the nodes. > While some consider the implementation of only one of these to qualify > a cluster, others seem to demand that a "true" cluster must > implement both. > > What I'm really after is a DB setup that does fail-over and parallel > execution. Your setup sounds like it would gracefully handle the > former, but cannot achieve the latter. Perhaps I'm simply asking too > much of a free software setup. commercial vendors arent much better here - they just dont tell you :-) There is pgpool or SQLRelay for example if you want to parallelize requests, you can combine with the various replication mechanism also available for PG and get what you want - and most important - get whats possible. Nobody can trick the math :-) Greets Tino
В списке pgsql-hackers по дате отправления: