What scalability strategies are possible with YSQL?
This question because the Postgre drivers allow you to connect to a single server. I am looking for information and examples.
I think it can behave correctly in Kubernetes (I have not tried).
May be a connections pool?
All feedback and infos are welcome
Currently we don’t offer a cluster aware client (like in YCQL).
We’re actively working on recommended ways to support this.
For now, there are several ways:
- haproxy http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#option%20pgsql-check providing the list of servers and using pgsql-check to see if servers are up
by providing a list of ips to tservers and using a routing function (example: returning a random server)
- implementing on the client, keeping a connection pooler for each tserver and randomly using one on each session
https://github.com/yandex/odyssey as connection pooler
Any Postgresql connection pooler/proxy that can work with 1+ servers will work. The most efficient config will be with
To clarify the architecture, yugabyte is a sharded database with different nodes responsible for portions of the database. More information is available at https://docs.yugabyte.com/latest/architecture/docdb/sharding/
Another design feature is that each yugabyte node runs a proxy that can forward requests to the appropriate node responsible for the rows involved in that query.
@dorian_yugabyte has already listed different ways in which queries can be routed in a round-robin or other fashion to multiple nodes in the database (which will then forward requests to the right node for the query internally). For Kubernetes specifically, another option is to use the inbuilt service load balancer as described in the Helm chart documention for yugabyte. This eliminates the need to install separate loadbalancer software.
Ok thanks to you 2, I will look at the side of Kubernetes