Otimizando o PostgreSQL ODBC Driver

Olá Pessoal!

Dentre as diversas fontes de dados envolvidas em cargas ETL através do SSIS, conexões com o PostgreSQL são bem comuns. Na maioria das vezes apenas tenho que buscar poucos dados de forma incremental, com alguns tratamentos durante a inserção no SQL Server. O problema é quanto ocorrem as cargas Full e milhões de linhas são lidas em grandes tabelas e o throughput de rede ainda não ajuda.

Bom…inicialmente para efetuarmos uma conexão com o PostgreSQL é necessário instalar o driver ODBC (psqlODBC) para o Windows na máquina que utiliza a solução do Integration Services. Uma vez instado, sua configuração no ODBC do Windows é bem simples, uma vez que, não existam problemas de rota e nenhuma restrição no pg_hba.conf, é possível utilizar o ODBC Connection Manager no Visual Studio para realizar o acesso ao PostgreSQL.

Uma vez que os passos acima tenham sido feitos é possível criar um ODBC Connection Manager no Visual Studio e conectar na instância do PostgreSQL. Conforme comentei no inicio, a medida que a quantidade de dados lidos for aumentando e a query no PostgreSQL for ficando mais complexa, as cargas começaram a ficar mais longas e exigir mais recursos do driver para tentar colocar os registros em memória. Chegou ao ponto de erros relacionados a alocação de memória no Visual Studio ocorrerem ao tentar executar um simples preview no Data Flow Source Component, isso devido as restrições do driver relacionado a memória.

Ao perceber este comportamento, em um primeiro momento pensei nas possibilidades de melhorias que deveriam ser feitas para otimizar a carga, a maior parte delas no lado do PostgreSQL, mas ao mesmo tempo fiquei procurando dicas, inclusive devido aos erros apresentados no Visual Studio durante o preview dos dados. No meio dessa pesquisa encontrei a documentação de configurações especificas do driver ODBC do PostgreSQL, uma delas sendo o “Use Declare/Fetch”.

“If true, the driver automatically uses declare cursor/fetch to handle SELECT statements and keeps 100 rows in a cache. This is mostly a great advantage, especially if you are only interested in reading and not updating. It results in the driver not sucking down lots of memory to buffer the entire result set. If set to false, cursors will not be used and the driver will retrieve the entire result set. For very large tables, this is very inefficient and may use up all the Windows memory/resources. However, it may handle updates better since the tables are not kept open, as they are when using cursors. This was the style of the old podbc32 driver. However, the behavior of the memory allocation is much improved so even when not using cursors, performance should at least be better than the old podbc32.”

Esse simples checkbox caiu como uma luva para o meu cenário, no qual estou fazendo apenas leituras de uma massa grande de dados. Com apenas um clique nessa configuração a consulta que buscava os dados de origem não apresentou mais problemas no preview do componente, além de ter ficado extremamente rápida, o que também se refletiu no processo de carga com uma melhora considerável no desempenho.

Não deixem de fazer o teste, mesmo que não estejam passando por problemas de performance agora, essa é a uma otimização que vale a pena aplicar no seu driver ODBC do PostgreSQL.

Até a próxima!

Anúncios

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s