Como fazer o pool de conexões
Cada plataforma tem uma interface de pool de conexão diferente. Você precisará ler a documentação para a plataforma específica que usa (Ruby+Rails ou qualquer outra), ou usar uma camada intermediária de pooling genérica como o PgBouncer.
Respostas relacionadas a uma ferramenta (digamos, PHP com Zend Framework) não terão nada a ver com respostas relacionadas a outra ferramenta (como Ruby on Rails). Mesmo se você escolher algo como o PgBouncer, ainda há detalhes relacionados a como a plataforma lida com o tempo de vida das transações, o modo de pool para escolher com base nas necessidades do aplicativo etc.
Então você precisa primeiro determinar o que você está usando e o que você precisa fazer com ele. Então estude como configurar seu pool de conexões. (Com muitas ferramentas é apenas automático).
Se você ainda estiver travado depois de ler a documentação da plataforma escolhida , pergunte a um novo detalhado e específico pergunta marcada apropriadamente para a plataforma.
Agrupamento e middleware
Não faça com que seu aplicativo se conecte diretamente ao PostgreSQL. Especialmente se for pela Internet de clientes aleatórios.
Use um servidor da Web próximo ao servidor PostgreSQL e faça com que ele aceite solicitações de serviço da Web para intermediar o acesso ao banco de dados por meio de uma API da Web bem definida com transações curtas com escopo para solicitar o máximo possível.
Este não é apenas um caso de sabedoria recebida - há boas razões para fazê-lo, e sérios problemas com a execução do PostgreSQL a partir de dispositivos aleatórios pela Internet.
Aplicativo Android falando direto com Pg
Problemas ao falar com o Pg diretamente pela Internet de muitos clientes incluem:
-
Cada backend do PostgreSQL tem um custo, inativo ou não. O PgBouncer no modo de pool de transações ajuda com isso até certo ponto.
-
As conexões se perdem aleatoriamente quando você está trabalhando na Internet. Quedas de WiFi, mudanças de endereço IP em serviços IP dinâmicos, serviço móvel que diminui ou atinge o máximo em capacidade ou apenas cambaleia junto com alta perda de pacotes. Isso deixa você com muitas conexões PostgreSQL em estados indeterminados, provavelmente com transações abertas, dando a você<IDLE> in transactionproblemas e a necessidade de permitir muito mais conexões do que realmente estão funcionando.
-
É transacional - se algo não terminar, você pode encerrar a transação e saber que não terá efeito.
Vantagens de ter uma camada intermediária
Um servidor respondendo a solicitações de serviço da Web HTTP do seu aplicativo em dispositivos Android para atuar como um agente de acesso ao banco de dados pode ser uma grande vantagem.
-
Você pode definir uma API com versão, portanto, quando você introduz novos recursos ou precisa alterar a API, não precisa interromper clientes antigos. Isso é possível com o Pg usando procedimentos armazenados ou muitas visualizações, mas pode ficar desajeitado.
-
Você controla estritamente o escopo do acesso ao banco de dados e os tempos de vida das transações.
-
Você pode definir uma API idempotente, onde executar a mesma solicitação várias vezes tem apenas um efeito. (Recomendo fortemente fazer isso por causa do próximo ponto).
-
Tudo é sem estado e pode ter tempos limite curtos. Se algo não funcionar você apenas tente novamente.
-
Cada conexão de banco de dados passa por um pool, para que você não tenha sessões ociosas. Cada back-end de banco de dados está trabalhando duro para obter o máximo rendimento.
-
Você pode enfileirar o trabalho em vez de tentar fazer toneladas simultaneamente e sobrecarregar o servidor. (Você também pode fazer isso com o PgBouncer no modo de pool de transações).
... e re sua edição para alterar o significado da pergunta:
Desempenho
Seu desempenho "Also" re é realmente uma questão totalmente diferente (e deve preferencialmente ser postado como tal). A versão muito curta:totalmente impossível de prever sem muito mais informações sobre a carga de trabalho, como número de solicitações de banco de dados por solicitação de aplicativo cliente, tipo de dados, tipo de consultas, tamanho dos dados, frequência de consultas, praticidade de armazenamento em cache, .. .... infinitamente. Qualquer um que afirme responder definitivamente a essa pergunta é o primeiro verdadeiro médium da história ou completamente cheio disso.
Você precisa descobrir aproximadamente qual será o tamanho dos dados, os padrões de consulta etc. Descubra quanto você pode armazenar em cache em um cache de camada intermediária como redis/memcached, quão obsoleto você pode deixá-lo ficar, qual nível de invalidação de cache você precisa. Determine se o seu conjunto de dados "quente" (que você acessa muito) caberá na RAM ou não. Determine se os índices das tabelas consultadas com frequência caberão na RAM ou não. Descubra qual é o seu saldo aproximado de leitura/gravação e quanto suas gravações provavelmente serão somente inserção (anexar) ou OLTP mais regular (inserir/atualizar/excluir). Simule um conjunto de dados e algumas cargas de trabalho do cliente. Então você pode começar a responder a essa pergunta - talvez. Para fazer isso direito, você também precisa simular clientes parados/desaparecidos, etc.
Veja porque não é apenas um "Também?".
