Tive uma idéia brilhante ontem (que com certeza não é minha).
Quando precisamos atualizar um banco de dados muito grande, passamos por um problema: tempo. Rodamos um update e esperamos uma vida pra obter resposta. Fora quando o banco não cai, ou tinha problema e corrompe, etc. Os ossos quebrados do ofício.
Mas será que é possível atualizar de poucos em poucos registros, aumentando assim a velocidade e diminuindo o perigo de inconsistência?
Há algum tempo atrás desenvolvi uma classe de pool de thread (p.s: thread é um processo do programa que roda em paralelo com ele. Pool de thread é um conjunto de threads) que permite que eu passe um procedimento e ela cria uma série de threads, dividindo a tarefa, e executando mais rápido.
Essa classe foi pensada pra ser utilizada com relatórios muito pesados, e faria o seguinte: numa das threads retorna os registros, por exemplo, de 1 a 100. Em outra thread, do 101 a 200. E assim por diante. No final, todos os registros seriam juntados na máquina do usuário e o relatório seria montado.
Acredite, é muito mais rápido para o banco executar pequenos selects ou updates do que um monstro de uma vez.
Mas queria algumas idéias, de como começar, ou se é útil. Além disso, outras aplicações para o pool de threads.
Não vou postar aqui o código, mas quem quiser, só me dá um toque que eu mando.
E se tiver alguma correção, ai é legal postar aqui.
Até
Assinar:
Postar comentários (Atom)
2 comentários:
A idéia é interessante, Alexandre. Porém, para nossos casos aqui na Softland, não sei se será necessário, mesmo porque são raros os casos que temos que fazer um update "gigante" na base de dados. Um exemplo, que ocorreu há alguns dias foi a execução de um update inútil na tabela itemped para atualizar a reserva dos produtos via trigger (creio que tenha sido isso que instigou sua idéia... eheh), nesse caso ficaria legal. Mas ainda assim não vejo tanta necessidade. E também, dividir um processo em vários para um mesmo processador acessando um periférico (dados do Banco de dados que estão no HD) é realmente útil? A atualização não pode ser atômica, ou seja, se alguma informação não for atualizada não vai pode fazer diferença... esses são alguns pontos para pensar...
E ae walter. Então, mesmo que vários processos estejam acessando um periférico, é mais rápido mandar os processos para o schedule do SO do que usar um processo só. A grande vantagem é a de não sobrecarregar o sistema inteiro, porque o SO toma conta de dividir o tempo direitinho entre as tarefas.
Postar um comentário