Tendemos a confiar em soluções de cache para melhorar o desempenho do banco de dados. O cache de consultas frequentemente acessadas na memória ou através de um banco de dados pode otimizar o desempenho de gravação/leitura e reduzir a latência da rede, especialmente para aplicativos de carga de trabalho pesada, como serviços de jogos e portais de Perguntas e Respostas. Mas você pode melhorar ainda mais o desempenho, juntando as conexões dos usuários a um banco de dados.

Os usuários do cliente precisam criar uma conexão com um serviço web antes de poderem executar operações CRUD. A maioria dos serviços web são apoiados por servidores de banco de dados relacionais, como Postgres ou MySQL. Com o PostgreSQL, cada nova conexão pode levar até 1,3MB de memória. Em um ambiente de produção onde esperamos receber milhares ou milhões de conexões simultâneas ao serviço backend, isso pode exceder rapidamente seus recursos de memória (ou se você tiver uma nuvem escalável, pode ficar muito caro muito rapidamente).

Porque cada vez que um cliente tenta acessar um serviço backend, ele requer recursos do SISTEMA para criar, manter e fechar conexões com o datastore. Isso cria uma grande quantidade de sobrecarga fazendo com que o desempenho do banco de dados se deteriore.

Os consumidores do seu serviço esperam tempos de resposta rápidos. Se esse desempenho se deteriorar, pode levar a experiências de usuários ruins, perdas de receita e até mesmo tempo de inatividade não programado. Se você expor seu serviço backend como uma API, repetidas lentidão e falhas podem causar problemas em cascata e perder seus clientes.

Em vez de abrir e fechar conexões para cada solicitação, o pooling de conexão usa um cache de conexões de banco de dados que podem ser reutilizadas quando solicitações futuras ao banco de dados são necessárias. Ele permite que seu banco de dados dimensione efetivamente à medida que os dados armazenados lá e o número de clientes que o acessam crescem. O trânsito nunca é constante, por isso a junção pode gerenciar melhor os picos de tráfego sem causar paralisações. Seu banco de dados de produção não deve ser seu gargalo.

Neste artigo, vamos explorar como podemos usar o middleware de pooling de conexão como pgpool e pgbouncer para reduzir a sobrecarga e a latência da rede. Para fins de ilustração, usarei pgpool-II e pgbouncer para explicar conceitos de pooling de conexão e comparar qual é mais eficaz em conexões de pooling, pois alguns poolers de conexão podem até afetar o desempenho do banco de dados.

Analisaremos como usar o pgbench para fazer benchmark de bancos de dados postgres, uma vez que é a ferramenta padrão fornecida pelo PostgreSQL.

Diferentes hardwares fornecem diferentes resultados de benchmarking com base no plano que você definiu. Para os testes abaixo, estou usando essas especificações.

Especificações da minha máquina de teste:

Servidor Linode: Ubuntu 16 – 64 bits (Máquina Virtual)

Postgres versão 9.5

Memória: 2GBDestabase tamanho: 800MB

Armazenamento: 2GB

Também é importante isolar o servidor de banco de dados Postgres de outras frameworks, como o carregador logstash e outros servidores para coletar métricas de desempenho, pois a maioria desses componentes consomem mais memória e afetarão os resultados do teste.

Criando uma conexão em conjunto  

Conectar-se a um serviço backend é uma operação cara, pois consiste nas seguintes etapas:

Abra uma conexão com o banco de dados usando o driver do banco de dados.

Abra um soquete TCP para operações CRUD

Realize as operações CRUD sobre a tomada.

Feche a conexão.

Feche a tomada.

Em um ambiente de produção onde esperamos milhares de conexões simultâneas abertas e próximas dos clientes, fazer as etapas acima para cada conexão pode fazer com que o banco de dados teve um desempenho ruim.

Podemos resolver esse problema reunindo conexões de clientes. Em vez de criar uma nova conexão com cada solicitação, os poolers de conexão reutilizam algumas conexões existentes. Assim, não há necessidade de realizar várias viagens de banco de dados completas caras, abrindo e fechando conexões para o serviço backend. Ele impede a sobrecarga de criar uma nova conexão com o banco de dados toda vez que houver uma solicitação de conexão de banco de dados com as mesmas propriedades (nome, banco de dados, versão de protocolo).

Agrupar middleware como pgbouncer vem com um gerente de piscina. Normalmente, o gerenciador de pools de conexões mantém um pool de conexões abertas de banco de dados. Você não pode juntar conexões sem um gerente de piscina.

Uma piscina contém dois tipos de conexões:

Conexão ativa: Em uso pelo aplicativo.

Conexão ociosa: Disponível para uso pelo aplicativo.

Quando uma nova solicitação para acessar dados do serviço backend entra, o gerenciador do pool verifica se o pool contém alguma conexão não uso e retorna um se estiver disponível. Se todas as conexões na piscina estiverem ativas, então uma nova conexão será criada e adicionada ao pool pelo gerente do pool. Quando a piscina atinge seu tamanho máximo, todas as novas conexões são enfileidas até que uma conexão na piscina esteja disponível.

Embora a maioria dos bancos de dados não tenha um sistema de pooling de conexões embutido, existem soluções de middleware que podemos usar para reunir conexões de clientes.

Para um servidor de banco de dados PostgreSQL, tanto o pgbouncer quanto o pgpool-II podem servir como uma interface de pooling entre um serviço web e um banco de dados Postgres. Ambas as concessionárias usam a mesma lógica para agrupar conexões de clientes.

o pgpool-II oferece mais recursos além do pooling de conexões, como replicação, balanceamento de carga e recursos de consulta paralela.

Como você adiciona pooling de conexão? É tão simples quanto instalar os utilitários?

Duas maneiras de integrar um pooler de conexão

Existem duas maneiras de implementar o pooling de conexão para o aplicativo PostgreSQL:

 Como um serviço externo ou middleware, como pgbouncer

Poolers de conexão como pgbouncer e pgpool-II podem ser usados para pool de conexões de clientes para um banco de dados PostgreSQL. O pooler de conexão fica entre o aplicativo e o servidor de banco de dados. Pgbouncer ou pgpool-II podem ser configurados de forma a transmitir solicitações do aplicativo para o servidor de banco de dados.

Bibliotecas do lado do cliente, como c3p0

Existem bibliotecas como c3p0 que ampliam a funcionalidade do driver de banco de dados para incluir suporte de pooling de conexão.

No entanto, a melhor maneira de implementar o pooling de conexão para aplicativos é fazer uso de um serviço externo ou middleware, uma vez que é mais fácil configurar e gerenciar. Além disso, middleware externo como pgpool2 fornece outros recursos, como balanceamento de carga, além de conexões de pooling.

Agora vamos dar uma olhada mais profunda no que acontece quando um serviço backend se conecta a um banco de dados postgres, com e sem pooling.

Dimensionamento do desempenho do banco de dados sem pooling de conexão

Não precisamos de um pooler de conexão para conectar a um serviço backend. Podemos nos conectar diretamente a um banco de dados postgres. Para examinar quanto tempo leva para executar conexões simultâneas a um banco de dados sem um pooler de conexão, usaremos o pgbench para fazer conexões de benchmark ao banco de dados Postgres.

O Pgbench é baseado no TPC-B. O TPC-B mede o throughput em termos de quantas transações por segundo um sistema pode realizar. O Pgbench executa cinco comandos SELECT, INSERTe UPDATE por transação.

Com base em transações semelhantes ao TPC-B, o pgbench executa a mesma sequência de comandos SQL repetidamente em várias sessões simultâneas de banco de dados e calcula a taxa média de transação.

Antes de executarmos o pgbench, precisamos inicializá-lo com o seguinte comando para criar as tabelas pgbench_history, pgbench_branches pgbench_tellerse pgbench_accounts O Pgbench usa as tabelas a seguir para executar transações para benchmarking.

pgbench -i -s 50 database_name

Depois, executei o comando abaixo para testar o banco de dados com 150 clientes

pgbench -c 10 -j 2 -t 10000 database_name

Como você vê, em nosso teste inicial de linha de base, eu instruí pgbench para executar com dez sessões de clientes diferentes. Cada sessão do cliente executará 10.000 transações.

A partir desses resultados, parece que nosso teste inicial de linha de base é de 486 transações por segundo.

Vamos ver como podemos fazer uso de poolers de conexão como pgbouncer e pgpool para aumentar o throughput de transações e evitar um erro 'Desculpe!, muitos clientes já'

Dimensionamento do desempenho do banco de dados com pgbouncer

Vamos ver como podemos usar o pgbouncer para aumentar o throughput da transação.

O Pgbouncer pode ser instalado em quase todas as distribuições Linux. Você pode verificar aqui como configurar pgbouncer. Alternativamente, você pode instalar pgbouncer usando gerentes de pacotes como apt-get ou yum .

Se você acha difícil autenticar clientes com pgbouncer, você pode verificar o GitHub sobre como fazê-lo.

Pgbouncer vem com três tipos de pooling:

Pooling desessão : Uma das conexões na piscina é atribuída a um cliente até que o tempo limite seja atingido.

Pooling de transações: Semelhante à votação da sessão, ele obtém uma conexão do pool. Ele o mantém até que a transação seja feita. Se o mesmo cliente quiser executar outra transação, ele tem que esperar até receber outra transação atribuída a ela.

Pooling de declarações: A conexão é devolvida ao pool assim que a primeira consulta for concluída.

Faremos uso do modo de pooling de transações. Dentro do arquivo pgbouncer.ini modifiquei o seguinte parâmetro:

max_client_conn = 100

O max_client_conn define quantas conexões de clientes com pgbouncer (em vez de Postgres) são permitidas.

default_pool_size = 25 

O default_pool_size define quantas conexões de servidor permitem por par de usuário/banco de dados.

reserve_pool_size = 5    

O reserve_pool_size define quantas conexões adicionais são permitidas à piscina.

Como no teste anterior, executei o pgbench com dez sessões de clientes diferentes. Cada cliente executa 1000 transações como mostrado abaixo.

pgbench -c 10 -p -j 2 -t 1000 database_name

Como você vê, o throughput de transações aumentou de 486 transações por segundo para 566 transações por segundo. Com a ajuda do pgbouncer, o throughput da transação melhorou em aproximadamente 60%.

Agora vamos ver como podemos aumentar o throughput de transações com o pgpool-II, uma vez que ele vem com recursos de pooling de conexão.

Ao contrário do pgbouncer, o pgpool-II oferece recursos além do pooling de conexão. A documentação fornece informações detalhadas sobre os recursos pgpool-II e como configurá-lo a partir da origem ou através de um gerenciador de pacotes

Alterei os seguintes parâmetros no arquivo pgpool.conf para fazê-lo encaminhar as conexões dos clientes de pgpool2 para o servidor de banco de dados Postgres.

connection_cache = on  

listen_addresses = ‘postgres_database_name’’  

port = 5432 

Definir o connection_cache para on ativa o recurso de agrupamento pgpool2.

Como no teste anterior, o pgbench executou dez sessões de clientes diferentes. Cada cliente executa 1000 transações no servidor de banco de dados Postgres. Assim, esperamos um total de 10.000 transações de todos os clientes.

gbench -p 9999 -c 10 -C -t 1000 postgres_database

Da mesma forma que aumentamos o throughput de transação com pgbouncer, parece que o pgpool2 também aumentou o throughput da transação em 75% em comparação com o teste inicial.

O Pgbouncer implementa a junção de conexão 'fora da caixa' sem a necessidade de ajustar parâmetros, enquanto o pgpool2 permite ajustar parâmetros para melhorar o pooling de conexão.

Escolhendo um pooler de conexão: pgpool-II ou pgbouncer?

Existem vários fatores a considerar ao escolher um pooler de conexão para usar. Embora pgbouncer e pgpool-II sejam ótimas soluções para pooling de conexão, cada ferramenta tem seus pontos fortes e fracos.

Consumo de memória/recursos

Se você está interessado em um pooler de conexão leve para o seu serviço backend, então pgbouncer é a ferramenta certa para você. Ao contrário do pgpool-II, que por padrão permite que 32 processos infantis sejam bifurcados, o pgbouncer usa apenas um processo. Assim, pgbouncer consome menos memória do que pgpool2. 

Replicação de streaming

Além de juntar conexões, você também pode gerenciar seu cluster Postgres com replicação de streaming usando pgpool-II. O streaming de replicação copia dados de um nó primário para um nó secundário. O Pgpool-II suporta a replicação de streaming postgres, enquanto o pgbouncer não. É a melhor maneira de alcançar alta disponibilidade e prevenir a perda de dados.

Gerenciamento centralizado de senhas

Em um ambiente de produção onde você espera que muitos clientes/aplicativos se conectem ao banco de dados através de um pooler de conexão simultaneamente, é necessário usar um sistema centralizado de gerenciamento de senhas para gerenciar as credenciais dos clientes.

Você pode fazer uso de auth_query em pgbouncer para carregar as credenciais dos clientes do banco de dados em vez de armazenar as credenciais dos clientes em uma lista de userlist.txt arquivo e comparar credenciais da sequência de conexão com o arquivo userlist.txt

Balanceamento de carga e alta disponibilidade

Finalmente, se você quiser adicionar balanceamento de carga e alta disponibilidade às suas conexões agrupadas, então pgpool2 é a ferramenta certa para usar. pgpool2 suporta postgres de alta disponibilidade através dos processos de cão de guarda embutidos. Este subprocesso pgpool2 monitora a saúde dos nós pgpool2 participantes do cluster watchdog, bem como coordena entre vários nós pgpool2.

Conclusão  

O desempenho do banco de dados pode ser melhorado além do pooling de conexão. A replicação, o balanceamento de carga e o cache na memória podem contribuir para um desempenho eficiente do banco de dados.

Se um serviço web foi projetado para fazer muitas consultas de leitura e gravação em um banco de dados, então você tem várias instâncias de um banco de dados Postgres no local para cuidar de consultas de gravação de clientes através de um balanceador de carga, como pgpool-II, enquanto o cache na memória pode ser usado para otimizar consultas de leitura.

Apesar da capacidade pgpool-II de funcionar como um balanceador de carregador e pooler de conexão, pgbouncer é a solução de middleware preferida para pooling de conexão porque é fácil de configurar, não muito difícil de gerenciar, e serve principalmente como um pooler de conexão sem quaisquer outras funções.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.