Esqueci de dizer no outro post que o problema está na funcionalidade em si. Como saoj já falou. Não faz sentido nenhum o usuário pesquisar tantos dados.
O problema pode ser resolvido aplicando mais filtros ou apresentando a funcionalidades de outra forma ( não uma lista).
Se o cara quer encontrar coisas especificas na lista, um filtro deve ajudar. Para a exportação, ele pode acontecer diretamente no servidor e já devolver ao desktop o produto final em formato binário.
É que vc não identificou porque precisa trazer tantos registros assim. Mas me paree que o caminho seria modificar a funcioanlidade. Isso seria bom o usuário porque não teria que catar milho, e para o sistema que ficaria mais leve.
[quote=sergiotaborda][quote=jmmenezes]
Vou fazer algumas tentativas a mais… vamos ver se consigo fazer a paginacao no banco mesmo, caso contrario, nao estou conseguindo enxergar outra solucao…
[/quote]
Esqueci de dizer no outro post que o problema está na funcionalidade em si. Como saoj já falou. Não faz sentido nenhum o usuário pesquisar tantos dados.
O problema pode ser resolvido aplicando mais filtros ou apresentando a funcionalidades de outra forma ( não uma lista).
Se o cara quer encontrar coisas especificas na lista, um filtro deve ajudar. Para a exportação, ele pode acontecer diretamente no servidor e já devolver ao desktop o produto final em formato binário.
É que vc não identificou porque precisa trazer tantos registros assim. Mas me paree que o caminho seria modificar a funcioanlidade. Isso seria bom o usuário porque não teria que catar milho, e para o sistema que ficaria mais leve.[/quote]
Sérgio, acredito que não tenha ficado muito claro nas minhas mensagens… mas a necessidade da funcionalidade é essa mesmo.
Já existem diversas telas no sistema para o usuário encontrar o registro especifico, sem dizer na grande quantidade de relatórios.
Essa tela especifica é usada para extração de dados e não para localizar registros… Ele possui em torno de 30 filtros… 250 colunas de diferentes tabelas… o sistema monta a query dinâmica com os joins e faz a extração.
As regras destas extrações são as mais malucas possiveis. O resultado disso é utilizado para diversos fins, em um banco de dados gigante.
Sei que o ideal para isto seria utilizar um banco de dados réplica com alguma ferramenta de BI ou relatórios dinâmicos. Mas o pq foi feito uma ferramenta “caseira” envolve uma série de fatores, até mesmo, lidar com um usuário que tem dificuldade de usar em Access e Excel. No final agente brinca aqui que tem de fazer limonada com pedra, e ainda colocar pra rodar em celeron com 512mb de ram! Sem falar no SQL 2000…
Se o objetivo fosse localizar registros com certeza seria questão de mudar a funcinalidade, mas o objetivo para extração, atende muito bem o usuário. Agora é mais uma questão técnica e a alternativa que achamos foi fazer essa serialização…
Quando eu vi o cara falando que SQLServer 2000 não tem pagination eu achei que era orelhada. Fui pesquisar e realmente não tem algo como limit do MySQL! Mas pelo que vi o SQLServer 2012 tem esse recurso de forma bem simplificada. Vale a pena ver se não da pra migrar para uma versão mais nova do SQLServer, usar uma ferramenta de mais de 10 anos atrás é bem complicado…
Bom, sei que o tópico é velho mas deixo aqui minha contribuição pro caso de alguém um dia precisar. Eu passei por esse problema e todos os tutoriais e exemplos que eu achava na net carregavam a tabela inteira na memória do servidor pra depois mostrar a paginação pra inglês ver, o meu caso era um pouquinho pior, em vez de 500 mil, eram mais de 10 milhões de registros, ou seja sem chance, a solução que eu encontrei foi a seguinte, um procedure;
CREATE PROCEDURE RASTRPAGINACAO
@IDVEICULO INT,
@TAMANHOPAGINA INT,
@NUMEROPAGINA INT,
@DATAINI DATETIME,
@DATAFIM DATETIME
AS
BEGIN
WITH PAGINADO AS (SELECT ROW_NUMBER() OVER(ORDER BY DATAHORA DESC) AS INDICE, *
FROM VWATUALIZACOES WITH (NOLOCK) WHERE IDVEICULO = @IDVEICULO
AND DATAHORA >= @DATAINI AND DATAHORA <= @DATAFIM)
SELECT TOP (@TAMANHOPAGINA) *
FROM PAGINADO P
WHERE INDICE > @TAMANHOPAGINA * (@NUMEROPAGINA - 1);
END
Pra executar é fácil, basta chamar ela com EXEC mesmo passando os parâmetros que ela retorna o recordset como se estivesse dando um SELECT normal. Onde parâmetro @TAMANHOPAGINA recebe a quantidade de registros /página, e @NUMEROPAGINA recebe o número da página, os outros parâmetros eu usei pra minha necessidade aqui mas basta cada um alterar de acordo com a sua necessidade. Ex;
Feito dessa maneira, a paginação vem direto do banco e a consulta fica um TIRO de rápida até hoje e a tabela hoje tem quase 40 milhões de registros.
Não entendi suas reticências não ô MR BEAN.[/quote]
Cara na verdade foi um post equivocado, eu não tinha me atentado sobre a versão do SQL Server que é o 2000, sobre uma
alternativa ao LIMIT nas versões mais recentes do SQL Server tem a função ROW_NUMBER() OVER () que por sinal
se não me engano o hibernate usa ela.
Não entendi suas reticências não ô MR BEAN.[/quote]
Cara na verdade foi um post equivocado, eu não tinha me atentado sobre a versão do SQL Server que é o 2000, sobre uma
alternativa ao LIMIT nas versões mais recentes do SQL Server tem a função ROW_NUMBER() OVER () que por sinal
se não me engano o hibernate usa ela.[/quote]
Pois é esse exemplo que eu postei aí tá testado no 2008 e eu tô usando as duas funções.
[quote=Alexandre Saudate]Já que já ressuscitaram o tópico, vou dar meu pitaco…
Me parece que você tem em mãos aquilo que é o caso de uso perfeito para Hadoop e Map/Reduce.
[]'s[/quote]
Me desculpa a ignorância Alexandre, final ninguém sabe tudo. O que é exatamente e pra que serve isso. Pode explicar com mais detalhes o que é MapReduce? Eu dei uma pesquisada aqui no Google mas não entendi bem o objetivo, do que se trata.
[quote=Alexandre Saudate]Já que já ressuscitaram o tópico, vou dar meu pitaco…
Me parece que você tem em mãos aquilo que é o caso de uso perfeito para Hadoop e Map/Reduce.
[]'s[/quote]
Alexandre… mas é possível usar uma solução assim tendo uma dependência do banco de dados relacional SQL Server 2000 ? Não teria que ter uma réplica do banco de dados que causaria um atraso das informações ? Não conheço quase nada de NOSQL, bancos OO, etc… tudo que sei é praticamente o que tenho lido em revistas, forums, etc… mas nesse caso especifico como que a solução funcionaria ?
[quote=leogazio][quote=Alexandre Saudate]Já que já ressuscitaram o tópico, vou dar meu pitaco…
Me parece que você tem em mãos aquilo que é o caso de uso perfeito para Hadoop e Map/Reduce.
[]'s[/quote]
Me desculpa a ignorância Alexandre, final ninguém sabe tudo. O que é exatamente e pra que serve isso. Pode explicar com mais detalhes o que é MapReduce? Eu dei uma pesquisada aqui no Google mas não entendi bem o objetivo, do que se trata.
Abraços.[/quote]
O Map Reduce, em sí, é uma técnica para processamento massivo de dados. Ele funciona com vários nós de mapeamento dos dados (os Mappers) e depois mais vários de tratamento destes dados mapeados (os Reducers). Tudo isso é feito de forma paralela.
O Hadoop, em sí, é mais como um ecossistema que conta com uma engine MapReduce mais um sistema de arquivos próprio, o HDFS. O HDFS, por ter essa natureza de filesystem próprio, conta com várias facilidades específicas para tratar um volume muito grande, como distribuição dos dados em vários nós e tamanho do bloco maior - 64 MB.
Pelo que tenho visto, é a solução de facto para Big Data.
[quote=jmmenezes][quote=Alexandre Saudate]Já que já ressuscitaram o tópico, vou dar meu pitaco…
Me parece que você tem em mãos aquilo que é o caso de uso perfeito para Hadoop e Map/Reduce.
[]'s[/quote]
Alexandre… mas é possível usar uma solução assim tendo uma dependência do banco de dados relacional SQL Server 2000 ? Não teria que ter uma réplica do banco de dados que causaria um atraso das informações ? Não conheço quase nada de NOSQL, bancos OO, etc… tudo que sei é praticamente o que tenho lido em revistas, forums, etc… mas nesse caso especifico como que a solução funcionaria ?[/quote]
Teria que ter uma réplica, sim, que seja monitorada pelo Hadoop. De qualquer maneira, se você for parar pra pensar, é praticamente impossível você exibir dados online com essa massa de dados, já que, no momento em que esses dados estiverem sendo visualizados, eles estarão sofrendo alterações (afinal de contas, com 500 mil registros, acho praticamente impossível não ter ninguém mexendo em nenhum desses).
Se você mantiver o Hadoop sincronizando estes dados de tempos em tempos com seu banco de dados, não deve ser um problema. Ele funcionaria mais ou menos como a sua tabela intermediária, mas com uma capacidade de processamento maior (já que o Map/Reduce funciona bem em clusters).
Quando precisei fazer isso com o sql 2000, utilizei uma solução parecida com a sua, porém deixava o usuário ter apenas uma tabela temporária. Em uma outra tabela, amarrava o usuário com a tabela temporária. Assim, quando ele tentava fazer alguma consulta, eu verificava se o mesmo já possuia alguma tabela. Se já existisse, deletava e criava outra. Tinha no máximo 5 usuário utilizando esta funcionalidade, então, nunca tive problemas de espaço em disco. Claro, hoje existem soluções bem melhores.
