On Mon, Aug 31, 2015 at 01:16:21PM -0700, Josh Berkus wrote:
> I'm also going to pontificate that, for a future solution, we should not
> focus on write *IO*, but rather on CPU and RAM. The reason for this
> thinking is that, with the latest improvements in hardware and 9.5
> improvements, it's increasingly rare for machines to be bottlenecked on
> writes to the transaction log (or the heap). This has some implications
> for system design. For example, solutions which require all connections
> to go through a single master node do not scale sufficiently to be worth
> bothering with.
Well, I highlighted write IO for sharding because sharding is the only
solution that allows write scaling. If we want to scale CPU, we are
better off using server parallelism, and to scale CPU and RAM, a
multi-master/BDR solution seems best. (Multi-master doesn't do write
scaling because you eventually have to write all the data to each node.)
For read-scaling, having the read queries go to streaming slave seems
best.
Only sharding allows for write scaling, but only in very limited
use-cases, where the queries use multiple shards and the
sharding/communication overhead doesn't overwhelm the benefits.
For these reasons, I think sharding has a limited use, and hence, I
don't think the community will be willing to add a lot of code just to
enable auto-sharding. I think it has to be done in a way that adding
sharding also gives other benefits, like better FDWs and cross-node ACID
control.
In summary, I don't think adding a ton of code just to do sharding will
be acceptable. A corollary of that, is that if FDWs are unable to
provide useful sharding, I don't see an acceptable way of adding
built-in sharding to Postgres.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +