Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ks9Vs-00053T-VA for pgsql-performance@arkaria.postgresql.org; Wed, 23 Dec 2020 19:09:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ks9Vp-0005mY-Ru for pgsql-performance@arkaria.postgresql.org; Wed, 23 Dec 2020 19:09:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ks9Vp-0005mR-Kj for pgsql-performance@lists.postgresql.org; Wed, 23 Dec 2020 19:09:29 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ks9Vi-0001SD-12 for pgsql-performance@lists.postgresql.org; Wed, 23 Dec 2020 19:09:28 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1ks9Vf-0004nJ-Gh; Wed, 23 Dec 2020 14:09:19 -0500 Date: Wed, 23 Dec 2020 14:09:19 -0500 From: Bruce Momjian To: Marco Colli Cc: Gunther Schadow , pgsql-performance@lists.postgresql.org Subject: Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc. Message-ID: <20201223190919.GA10547@momjian.us> References: <311b7c3a-23d9-42a9-b444-1a7bfcfe1897@gusw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee