Dicas sobre Acelerar JDBC escreve?

votos
13

Estou escrevendo um programa que faz um monte de gravações para um banco de dados Postgres. Em um cenário típico que eu estaria escrevendo dizer 100.000 linhas a uma tabela que está bem normalizada (três chaves inteiras estrangeira, a combinação de que é a chave primária e o índice da tabela). Eu estou usando PreparedStatements e executeBatch (), mas eu só consegue empurrar dizer 100k linhas em cerca de 70 segundos no meu laptop, quando o banco de dados integrado que estamos substituindo (que tem as mesmas restrições de chaves estrangeiras e índices) fá-lo em 10.

Eu sou novo JDBC e eu não esperava que bater um DB incorporado costume, mas eu estava esperando para ser apenas 2-3x mais lento, não 7x. Qualquer coisa óbvia que eu talvez faltando? se a ordem das gravações importa? (Isto é dizer, se não é a ordem do índice?). Coisas para olhar para espremer uma velocidade de pouco mais?

Publicado 15/12/2008 em 16:39
fonte usuário
Em outras línguas...                            


4 respostas

votos
1

Você pode, obviamente, tentar mudar o tamanho de seu lote para encontrar o melhor tamanho para a sua configuração, mas eu duvido que você vai ganhar um fator de 3.

Você também pode tentar ajustar a sua estrutura de banco de dados. Você pode ter um melhor desempenho quando se utiliza um único campo como uma chave primária do que usar uma PK composta. Dependendo do nível de integridade que você precisa, você pode salvar algum tempo desativando verificações de integridade em seu DB.

Você também pode alterar o banco de dados você está usando. MySQL é suposto ser muito bom em alta velocidade inserções simples ... e eu sei que é um fork do MySQL em torno que tenta cortar funcionalidades para obter performances muito elevadas no acesso altamente concorrente.

Boa sorte !

Respondeu 15/12/2008 em 17:05
fonte usuário

votos
1

tente desabilitar índices e reativando-los após a inserção. Também, envolva todo o processo em uma transação

Respondeu 15/12/2008 em 17:16
fonte usuário

votos
8

Esta é uma questão que eu tive que lidar com muitas vezes no meu projeto atual. Para a nossa aplicação, a velocidade de inserção é um ponto crítico. No entanto, descobrimos para a grande maioria dos usuários de banco de dados, a velocidade de seleção como seu chefe gargalo assim que você vai descobrir que existem mais recursos que lidam com essa questão.

Então, aqui estão algumas soluções que vêm-se com:

Em primeiro lugar, todas as soluções envolvem usando os postgres COPY comando . Usando COPY para importar dados para postgres é de longe o método mais rápido disponível. No entanto, o driver JDBC por padrão não suporta actualmente COPY accross tomada da rede. Então, se você quiser usá-lo você terá que fazer uma de duas soluções alternativas:

  1. Um driver JDBC remendado para apoiar COPY, como este um .
  2. Se os dados que você está inserindo eo banco de dados estão na mesma máquina física, você pode escrever os dados para um arquivo no sistema de arquivos e, em seguida, use o comando COPY para importar os dados em massa.

Outras opções para aumentar a velocidade estiver usando JNI para bater a api postgres para que você possa falar sobre o soquete do unix, remoção de índices e o projeto pg_bulkload . No entanto, no final, se você não implementar COPY você vai sempre encontrar desempenho decepcionante.

Respondeu 16/12/2008 em 01:19
fonte usuário

votos
2

Verifique se sua conexão está definido para autoCommit. Se autoCommit é verdade, então se você tem 100 itens no lote quando você chamar executeBatch, que vai emitir 100 indivíduo comete. Isso pode ser muito mais lento do que chamar executingBatch () seguido por um único consolidação explícita ().

Gostaria de evitar a tentação de cair índices ou chaves estrangeiras durante a inserção. Ela coloca a mesa em um estado inutilizável enquanto a carga estiver em execução, já que ninguém pode consultar a tabela, enquanto os índices são ido. Além disso, ele parece bastante inofensivo, mas o que você faz quando você tenta reativar a restrição e ele falha porque algo que você não espera que aconteça que aconteceu? Um RDBMS tem restrições de integridade por uma razão, e desativá-los até mesmo "por um tempo" é perigoso.

Respondeu 16/12/2008 em 03:01
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more