From: Bruce Momjian <bruce@momjian.us>
To: Marco Colli <collimarco91@gmail.com>
Cc: Gunther Schadow <raj@gusw.net>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
Date: Wed, 23 Dec 2020 14:09:19 -0500
Message-ID: <20201223190919.GA10547@momjian.us> (raw)
In-Reply-To: <CAFvCgN7nTA5wEkKbeTg9fOOExAVjhxBUvZvho2uA0=nrDV9+4g@mail.gmail.com>
References: <311b7c3a-23d9-42a9-b444-1a7bfcfe1897@gusw.net>
<CAFvCgN7nTA5wEkKbeTg9fOOExAVjhxBUvZvho2uA0=nrDV9+4g@mail.gmail.com>
On Wed, Dec 23, 2020 at 07:34:01PM +0100, Marco Colli wrote:
> 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.
Agreed. There are really two parameters:
1. percentage of reads vs writes
2. number of standbys
If you have a high value for #1, it makes sense to use pgpool, but
having only one standby doesn't buy you much; add three, and you will
see an impact. Second, if writes are high, only scaling up the primary
or adding sharding will help you. It is kind of an odd calculus, but it
makes sense.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bruce@momjian.us, collimarco91@gmail.com, raj@gusw.net, pgsql-performance@lists.postgresql.org
Subject: Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
In-Reply-To: <20201223190919.GA10547@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox