Atualmente, meu empregador possui várias instâncias do Postgres (uma por cliente, com um código de site exclusivo) que estão fisicamente separadas nas instalações do cliente. Cada cliente tem de 1 a 4 bancos de dados em execução dentro de uma instância, com cada banco de dados contendo mais de 20 esquemas.
Estamos tentando reunir esses bancos de dados em uma única instância do Postgres, no local ou com um provedor de nuvem (pense em RDS), para que possamos simplificar o acesso/controle. O cliente continuará a acessar o banco de dados, mas introduziremos uma camada de serviço RESTful compartilhada, onde o banco de dados específico será direcionado usando um código de site adicionado como parte do caminho de URL de cada API. Para cumprir nosso SLA de desempenho (90% abaixo de 1s) e manter baixo o uso de recursos, pretendemos utilizar pooling de conexões na camada de serviço.
O principal problema que enfrentamos é que o Postgres requer um banco de dados durante a conexão, o que significa que teremos que ter um pool de conexões por cliente, o que utilizará muitos recursos de forma ineficiente. Como não estamos utilizando os recursos de forma eficiente, poderemos precisar de mais instâncias da camada de serviço, introduzindo mais custos e complexidade à arquitetura. Embora seja possível "fragmentar" efetivamente os clientes em múltiplas instâncias da camada de serviço, isso não resolve o problema real que é o uso ineficiente de conexões!
Existe outra solução que não considerei? Talvez uma maneira de ter um único pool de conexões onde as solicitações sejam encaminhadas para bancos de dados específicos? Ou talvez pools de conexões dinâmicas que podem ser redimensionados dinamicamente com base na carga?
Obrigado
Responder1
Proxy AWS RDSpode ser uma maneira prática de reduzir os requisitos de conexão.