Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
От | Marco Colli |
---|---|
Тема | Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc. |
Дата | |
Msg-id | CAFvCgN7nTA5wEkKbeTg9fOOExAVjhxBUvZvho2uA0=nrDV9+4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc. (Gunther Schadow <raj@gusw.net>) |
Ответы |
Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
|
Список | pgsql-performance |
Hello,
I asked the same question to myself in the past years.
I think that the question boils down to:
How can I achieve unlimited database scalability?
Is it possible to have linear scalability (i.e. throughput increases proportionally to the number of nodes)?
The answer is "sharding". It can be a custom solution or a database that supports it automatically. In this way you can actually split data across multiple nodes and the client contacts only the relevant servers for that data (based on a shard key). See also https://kubernetes-rails.com/#conclusion about database. Take a look at how Cassandra, MongoDB, CouchDB and Redis Cluster work for example: however there are huge limitations / drawbacks that come along with their unlimited-scalability strategies.
For hot standbys, those are only useful if you have a relatively small number of writes compared to reads. With that slave nodes you only scale the *read* throughput.
Hope it helps,
Marco Colli
В списке pgsql-performance по дате отправления: