none
Teste de Performance - MERGE RRS feed

  • Pergunta

  • Alguém já realizou testes de performance do MERGE x INSERT/UPDATE em grandes massas de dados (+ de 2 milhões de registro?).

    Alguém indica algum estudo?

    segunda-feira, 29 de janeiro de 2018 18:21

Respostas

  • Deleted
    segunda-feira, 29 de janeiro de 2018 19:13
  • Deleted
    quinta-feira, 1 de fevereiro de 2018 15:05
  • Thiago,

    Ok, entendo, mas então se fizermos uma simples análise, temos que verificar que quanto trabalhamos com o comando Merge todos o processamento esta sendo feito e uma única transação ou melhor dizendo bloco de execução.

    Ao utilizar Insert/Update ou Update/Insert se trabalharmos da maneira padrão o SQL Server vai dividir este processamento em blocos de execução por partes, ou seja, ele vai respeitar a ordem de declaração dos códigos para fazer sua devida e respectiva análise e processamento, sendo assim, os comandos tradicionais tendem a serem mais eficientes no que diz respeito ao tempo de processamento, leitura, escrita e uso de CPU.

    Já o Merge ele poderá sofrer de forma considerável ainda mais se estivermos trabalhando com fontes de dados distribuídas, ou seja, bancos de dados distintos ao invés de somente um único banco, isso não é uma regra mas sim um comportamento que poderá acontecer devido a concorrência de acesso aos dados e até mesmo a concorrência em disco, pois o Merge por padrão poderá gerar uma necessidade maior de escrita e leitura em disco para os arquivos de log, ao contrário dos comandos tradicionais.

    Antes de fazer uma comparação somente dos comandos, talvez devemos também analisar cenários como modelo de recuperação de banco de dados, alocação dos arquivos em disco para arquivos de dados e log e principalmente a questão de índices que podem gerar comportamentos diferentes.

    Você tem alguma análise realizada em relação a isso?


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    • Marcado como Resposta Thiago Serra sexta-feira, 2 de fevereiro de 2018 19:35
    sexta-feira, 2 de fevereiro de 2018 10:48

Todas as Respostas

  • Deleted
    segunda-feira, 29 de janeiro de 2018 19:13
  • Tiago,

    Já trabalhei com volumes próximos a 1 milhão de registros por tabela!!!

    O que exatamente você esta querendo fazer? Estamos falando de processamento local ou seria em servidores distribuídos?


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    terça-feira, 30 de janeiro de 2018 11:36
  • Trabalhamos com mais de 120 milhões de registros sendo atualizados por MERGE.

    A atualização dos registros tem sido meio demorada por causa das diferentes bases.

    Já implementamos assim e, não testamos o UPDATE.

    Como as consultas são complexas, antes de mudar, gostaria de ver se alguém chegou a fazer testes para ver se há realmente diferença sensível.

    O Cluster tem poder para processar tanto uma forma como outra, estou querendo reduzir o tempo das consultas...

    Achei um teste também http://www.sqlservercentral.com/articles/MERGE/103127/

    Usando aqui a versão 2012.

    quinta-feira, 1 de fevereiro de 2018 13:57
  • Caro Junior,

    minha ideia é apenas verificar se o merge é a melhor opção para + de 120 milhões de registros.

    não encontrei literatura com testes específicos para essa massa e, nas atuais condições, não tenho como implementar no ambiente atual com essa massa de dados.

    o teste que encontrei (http://www.sqlservercentral.com/articles/MERGE/103127/ ) deu resultados semelhantes comigo no ambiente de produção para até 5 milhões de linhas (MERGE se sai melhor).

    Agradeço o interesse.

    quinta-feira, 1 de fevereiro de 2018 14:02
  • Deleted
    quinta-feira, 1 de fevereiro de 2018 15:05
  • Thiago,

    Ok, entendo, mas então se fizermos uma simples análise, temos que verificar que quanto trabalhamos com o comando Merge todos o processamento esta sendo feito e uma única transação ou melhor dizendo bloco de execução.

    Ao utilizar Insert/Update ou Update/Insert se trabalharmos da maneira padrão o SQL Server vai dividir este processamento em blocos de execução por partes, ou seja, ele vai respeitar a ordem de declaração dos códigos para fazer sua devida e respectiva análise e processamento, sendo assim, os comandos tradicionais tendem a serem mais eficientes no que diz respeito ao tempo de processamento, leitura, escrita e uso de CPU.

    Já o Merge ele poderá sofrer de forma considerável ainda mais se estivermos trabalhando com fontes de dados distribuídas, ou seja, bancos de dados distintos ao invés de somente um único banco, isso não é uma regra mas sim um comportamento que poderá acontecer devido a concorrência de acesso aos dados e até mesmo a concorrência em disco, pois o Merge por padrão poderá gerar uma necessidade maior de escrita e leitura em disco para os arquivos de log, ao contrário dos comandos tradicionais.

    Antes de fazer uma comparação somente dos comandos, talvez devemos também analisar cenários como modelo de recuperação de banco de dados, alocação dos arquivos em disco para arquivos de dados e log e principalmente a questão de índices que podem gerar comportamentos diferentes.

    Você tem alguma análise realizada em relação a isso?


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    • Marcado como Resposta Thiago Serra sexta-feira, 2 de fevereiro de 2018 19:35
    sexta-feira, 2 de fevereiro de 2018 10:48
  • José,

    utilizo tanto para update como para insert.

    Do link sugerido eu pude ver que já usamos algumas idéias (índices ok, joins mínimos, e um plano de execução analisado).

    Quando disse que não testamos o update foi em relação a usar a instrução update ao invés do MERGE.

    O que fiz esses dias para teste e, me rendeu algumas horas de espera a menos foi usar lotes com o Ntile divindo em lotes de 20 milhões de linhas para atualizar/checar os INSERT.

    Assim que puder irei fazer plano de execução do INSERT/UPDATE para analisar se tenho ganho ou não mudando a solução atual.

    Mas, agradeço mais uma vez ajuda!

    sexta-feira, 2 de fevereiro de 2018 19:41
  • caro Junior,

    Ao utilizar Insert/Update ou Update/Insert se trabalharmos da maneira padrão o SQL Server vai dividir este processamento em blocos de execução por partes, ou seja, ele vai respeitar a ordem de declaração dos códigos para fazer sua devida e respectiva análise e processamento, sendo assim, os comandos tradicionais tendem a serem mais eficientes no que diz respeito ao tempo de processamento, leitura, escrita e uso de CPU.

    foi exatamente esse o raciocínio que tive quando postei a dúvida, justamente para ver se alguém mais teve a mesma situação.

    Acredito que tem tudo para ser mais rápido... o artigo que citei me deixou na dúvida uma vez que, parece, na análise feita pelo cidadão ele obteve resultado melhores com o MERGE para mais dados.

    Você tem alguma análise realizada em relação a isso?

    Então... ainda não. Otimizei o máximo que pude o MERGE para não ter que reescrever tudo.

    Mas, estou finalizando uma procedure para fazer os testes e respectivos planos de execução.

    Tendo resultados, eu aviso.

    Obrigado pela reposta!

    sexta-feira, 2 de fevereiro de 2018 19:46