Qual é a melhor maneira de trabalhar com grandes bancos de dados em Java, dependendo do contexto?

5

Estamos tentando descobrir a melhor prática para trabalhar com grandes bancos de dados em Java.

O que fazemos é um tipo de BI (business intelligence), ou seja, analisar bancos de dados muito grandes e usá-los para criar bancos de dados intermediários que representam conhecimento inteligente dos bancos de dados.

No momento, estamos usando o JDBC e apenas pré-formando consultas usando um ResultSet.

Conforme mais e mais dados estão sendo criados, estamos nos perguntando se existem maneiras mais apropriadas de analisar e manipular esses grandes bancos de dados:

  1. Precisamos dar suporte à manipulação de 'chunk' e não a um banco de dados inteiro de uma só vez (por exemplo, limite no JDBC, desempenho muito ruim)
  2. Não precisamos estar constantemente conectados, pois estamos apenas obtendo resultados e criando novas tabelas.
  3. Queremos entender as alternativas do JDBC, com relação às vantagens e desvantagens.
  4. Se você acha que o JDBC é o caminho certo ou não, quais são as práticas recomendadas dependendo do contexto (por exemplo, para grandes bancos de dados consultados em blocos)?
por gnat 02.03.2011 / 12:33
fonte

4 respostas

1

Não faça isso. Se você está analisando muitos dados, faça isso no banco de dados.

Procedimentos armazenados, tabelas temporárias, etc.

São dados, e é nisso que um banco de dados é bom. Use java para enviar as solicitações e ler os resultados. Deixe o SGBD gerenciar os dados, já que é um Sistema de Gerenciamento de Banco de Dados.

    
por 05.03.2011 / 10:36
fonte
1

Ok. Eu vou elaborar.

Deixe-me adivinhar que você extrai dados do banco de dados, cole-os em objetos java, edite os objetos java e salve de volta no banco de dados? Isto é certo até certo ponto ... mas para grandes quantidades de dados não é. Vamos dizer que você deseja desativar todos os usuários que vivem no estado de Maryland. Você pode extrair TODAS as informações que não são usadas no objeto java (nome, data de nascimento, etc.) e atualizar TODOS os campos desse usuário, mesmo que ele não tenha sido editado. Isso é aceitável para edições de registro único, não para processamento em lote de milhões de linhas. Em vez disso, considere [atualizar status do conjunto de funcionários = 'desativado', onde estado = 'maryland'].

crie uma tabela de amostra, preencha-a com 10 milhões de linhas de dados falsos. Compare o desempenho de carregamento de material em objetos java versus atualizações SQL simples baseadas em conjuntos.

    
por 06.03.2011 / 00:27
fonte
1

Sim, se a sua base de dados for grande, você poderá usar o particionamento para armazenar esses dados. E, como dito acima, não ative uma única consulta para buscar dados em pequenas operações de comparação ou análise.

Divida sua lógica de modo que os critérios de filtragem fáceis sejam manipulados por procedimentos armazenados e consulte-se, e somente algoritmo complexo que não seja suportado por consulta sql ou procedimento suportado deve ser feito com java após a obtenção de registros.

    
por 21.03.2014 / 13:07
fonte
0

Ferramentas corporativas como o IBM InfoSphere fazem exatamente o que você fez com a conexão JDBC. Eu toquei em seu estúdio IBM DataStage por um tempo, eu vi isso.

Meu conselho para você é projetar o esquema dos grandes dados de origem para que, quando você fizer a transformação de dados intermediários, anote o progresso (usando alguma coluna), para que a grande tarefa possa ser dividida em tarefas menores valores da coluna de progresso. Digamos que a busca busque 20000 linhas, marcando o offset para as buscas 2, etc ...

Eu faria o máximo possível em java por causa da infinidade de maneiras em que você pode registrar, depurar quando algo dá errado. Se você confiar demais no banco de dados, não acho que a depuração e a leitura de registros sejam tão confortáveis.

    
por 04.06.2014 / 20:29
fonte

Tags