Pool de conexões do PostgreSQL:Parte 1 – Prós e contras

Há muito tempo atrás, em uma galáxia muito distante, 'threads' eram uma novidade de programação raramente usada e raramente confiável. Nesse ambiente, os primeiros desenvolvedores do PostgreSQL decidiram que bifurcar um processo para cada conexão com o banco de dados é a escolha mais segura. Seria uma pena se seu banco de dados travasse, afinal.

Desde então, muita água passou por baixo dessa ponte, mas a comunidade PostgreSQL manteve sua decisão original. É difícil criticar o argumento deles – pois é absolutamente verdade que:

• Cada cliente com seu próprio processo evita que um cliente com mau comportamento trave o banco de dados inteiro.
• Nos sistemas Linux modernos, a diferença de sobrecarga entre bifurcar um processo e criar um encadeamento é muito menor do que costumava ser.
• Mudar para uma arquitetura multithread exigirá reescritas extensas.

No entanto, em aplicativos da Web modernos, os clientes tendem a abrir muitas conexões. Os desenvolvedores geralmente são fortemente desencorajados a manter uma conexão com o banco de dados enquanto outras operações ocorrem. “Abra uma conexão o mais tarde possível, feche uma conexão o mais rápido possível”. Mas isso causa um problema com a arquitetura do PostgreSQL – bifurcar um processo se torna caro quando as transações são muito curtas, como o senso comum dita que elas deveriam ser.

A arquitetura do pool de conexões

Usar uma biblioteca de linguagem moderna reduz um pouco o problema – o pool de conexões é um recurso essencial das bibliotecas de acesso a banco de dados mais populares. Ele garante que as conexões 'fechadas' não sejam realmente fechadas, mas retornadas a um pool, e 'abrir' uma nova conexão retorna a mesma 'conexão física', reduzindo a bifurcação real no lado do PostgreSQL.

No entanto, aplicativos da web modernos raramente são monolíticos e geralmente usam vários idiomas e tecnologias. Usar um pool de conexões em cada módulo dificilmente é eficiente:

• Mesmo com um número relativamente pequeno de módulos e um tamanho de pool pequeno em cada um, você acaba com muitos processos de servidor. A alternância de contexto entre eles é cara.
• O suporte ao pool varia muito entre bibliotecas e linguagens – um pool com mau comportamento pode consumir todos os recursos e deixar o banco de dados inacessível por outros módulos.
• Não há controle centralizado – você não pode usar medidas como limites de acesso específicos do cliente.

Como resultado, middlewares populares foram desenvolvidos para o PostgreSQL. Eles ficam entre o banco de dados e os clientes, às vezes em um servidor separado (físico ou virtual) e às vezes na mesma caixa, e criam um pool ao qual os clientes podem se conectar. Esses middlewares são:

• Otimizado para PostgreSQL e sua arquitetura bastante única entre os SGBDs modernos.
• Forneça controle de acesso centralizado para diversos clientes.
• Permitir que você obtenha as mesmas recompensas que os pools do lado do cliente e muito mais (discutiremos isso com mais detalhes em nossas próximas postagens)!

Contras do Pool de Conexão PostgreSQL

Um pool de conexões é uma parte quase indispensável de uma configuração do PostgreSQL pronta para produção. Embora haja muitos benefícios bem documentados no uso de um pool de conexões, há alguns argumentos a serem feitos contra o uso de um:

• A introdução de um middleware na comunicação inevitavelmente introduz alguma latência. No entanto, quando localizado no mesmo host e considerando a sobrecarga de bifurcar uma conexão, isso é insignificante na prática, como veremos na próxima seção.
• Um middleware se torna um único ponto de falha. Usar um cluster nesse nível pode resolver esse problema, mas isso adiciona complexidade à arquitetura.
  
• Um middleware implica custos extras. Você precisa de um servidor extra (ou 3) ou seus servidores de banco de dados devem ter recursos suficientes para suportar um pool de conexões, além do PostgreSQL.
• Compartilhar conexões entre diferentes módulos pode se tornar uma vulnerabilidade de segurança. É muito importante configurar o pgPool ou o PgBouncer para limpar as conexões antes que elas sejam retornadas ao pool.
• A autenticação muda do DBMS para o pool de conexões. Isso pode nem sempre ser aceitável.
  
• Aumenta a área de superfície para ataque, a menos que o acesso ao banco de dados subjacente seja bloqueado para permitir acesso apenas por meio do pool de conexões.
• Ele cria mais um componente que deve ser mantido, ajustado para sua carga de trabalho, com patches de segurança com frequência e atualizado conforme necessário.

Você deve usar um pool de conexões PostgreSQL?

No entanto, todos esses problemas são bem discutidos na comunidade PostgreSQL, e as estratégias de mitigação garantem que os prós de um pool de conexões superem em muito seus contras. Nossos testes mostram que mesmo um pequeno número de clientes pode se beneficiar significativamente do uso de um pool de conexões. Eles valem a pena o esforço adicional de configuração e manutenção.

Na próxima postagem, discutiremos um dos poolers de conexão mais populares no mundo PostgreSQL – PgBouncer, seguido por Pgpool-II e, por último, uma comparação de teste de desempenho desses dois Poolers de conexão PostgreSQL em nosso post final da série.