Grade de dados JavaScript para milhões de linhas [fechada]

Eu preciso apresentar um grande número de linhas de dados (ou seja, milhões de linhas) ao usuário em uma grade usando JavaScript.

O usuário não deve ver páginas ou exibir apenas quantidades finitas de dados por vez.

Em vez disso, deve parecer que todos os dados estão disponíveis.

Em vez de baixar os dados de uma só vez, pequenos blocos são baixados conforme o usuário os acessa (ou seja, rolando pela grade).

As linhas não serão editadas nesse front end, portanto, as grades somente leitura são aceitáveis.

Quais grades de dados, escritas em JavaScript, existem para esse tipo de paginação direta?

( Isenção de responsabilidade: eu sou o autor do SlickGrid )

ATUALIZAÇÃO Agora isso foi implementado no SlickGrid .

Consulte http://github.com/mleibman/SlickGrid/issues#issue/22 para uma discussão contínua sobre como fazer o SlickGrid funcionar com um número maior de linhas.

O problema é que o SlickGrid não virtualiza a própria barra de rolagem - a altura da área rolável é definida como a altura total de todas as linhas. As linhas ainda estão sendo adicionadas e removidas à medida que o usuário está rolando, mas a rolagem em si é feita pelo navegador. Isso permite que seja muito rápido e suave (os eventos de rolagem são notoriamente lentos). A ressalva é que existem bugs / limites nos mecanismos CSS dos navegadores que limitam a altura potencial de um elemento. Para o IE, é 0x123456 ou 1193046 pixels. Para outros navegadores, é maior.

Há uma solução experimental no ramo "correção de largenum" que aumenta esse limite significativamente ao preencher a área de rolagem com "páginas" definidas para 1M pixels de altura e, em seguida, usar o posicionamento relativo nessas páginas. Como o limite de altura no mecanismo CSS parece ser diferente e significativamente menor do que no mecanismo de layout real, isso nos dá um limite superior muito mais alto.

Ainda estou procurando uma maneira de obter um número ilimitado de linhas sem abrir mão da margem de desempenho que o SlickGrid atualmente possui sobre outras implementações.

Rudiger, você pode elaborar como resolveu isso?

https://github.com/mleibman/SlickGrid/wiki

"O SlickGrid utiliza renderização virtual para permitir que você trabalhe facilmente com centenas de milhares de itens sem diminuir o desempenho. De fato, não há diferença no desempenho entre trabalhar com uma grade com 10 linhas versus 100.000 linhas " .

Alguns destaques:

• Rolagem virtual adaptável (manipule centenas de milhares de linhas)
• Velocidade de renderização extremamente rápida
• Pós-renderização em segundo plano para células mais ricas
• Configurável e personalizável
• Navegação completa pelo teclado
• Redimensionar / reordenar / mostrar / ocultar coluna
• Dimensionamento automático da coluna e ajuste de força
• Formadores e editores de células conectáveis
• Suporte para editar e criar novas linhas. "por mleibman

É grátis (licença MIT). Ele usa jQuery.

As melhores grades na minha opinião estão abaixo:

• Flexigrid: http://flexigrid.info/
• jQuery Grid: http://www.trirand.com/blog/
• jqGridView: http://plugins.jquery.com/project/jqGridView
• jqxGrid: http://www.jqwidgets.com/
• Ingrid: http://reconstrukt.com/ingrid/
• SlickGrid http://github.com/mleibman/SlickGrid
• DataTables http://www.datatables.net/index
• ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows

Minhas 3 melhores opções são jqGrid, jqxGrid e DataTables. Eles podem trabalhar com milhares de linhas e oferecer suporte à virtualização.

Não pretendo iniciar uma guerra de chamas, mas, assumindo que seus pesquisadores são humanos, você não os conhece tão bem quanto pensa. Só porque eles têm petabytes de dados não os torna capazes de visualizar milhões de registros de maneira significativa. Eles podem dizer que querem ver milhões de registros, mas isso é bobagem. Faça com que seus pesquisadores mais inteligentes façam algumas contas básicas: suponha que eles gastem 1 segundo visualizando cada registro. Nesse ritmo, levará 1000000 segundos, o que ocorre por mais de seis semanas (de 40 horas semanais de trabalho sem interrupções para alimentação ou lavatório).

Eles (ou você) pensam seriamente que uma pessoa (a que está olhando para a grade) pode reunir esse tipo de concentração? Eles estão realmente realizando muito nesse primeiro segundo, ou estão (mais provavelmente) filtrando as coisas que não querem? Suspeito que, depois de exibir um subconjunto "de tamanho razoável", eles possam descrever um filtro para você que filtrará automaticamente esses registros.

Como paxdiablo e Sleeper Smith e Lasse V Karlsen também sugeriram, você (e eles) não considerou os requisitos. No lado positivo, agora que você encontrou o SlickGrid, tenho certeza de que a necessidade desses filtros se tornou imediatamente óbvia.

Posso dizer com certeza que você não precisa mostrar milhões de linhas de dados para o usuário.

Não há usuário no mundo capaz de compreender ou gerenciar esse conjunto de dados; mesmo que você consiga executá-lo tecnicamente, não resolverá nenhum problema conhecido para esse usuário.

Em vez disso, eu focaria no motivo pelo qual o usuário deseja ver os dados. O usuário não deseja ver os dados apenas para vê-los; geralmente há uma pergunta sendo feita. Se você se concentrar em responder a essas perguntas, estará muito mais perto de algo que resolva um problema real.

Eu recomendo a grade Ext JS com o recurso Buffered View.

http://www.extjs.com/deploy/dev/examples/grid/buffer.html

(Isenção de responsabilidade: eu sou o autor do w2ui)

Recentemente, escrevi um artigo sobre como implementar a grade JavaScript com 1 milhão de registros ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Descobri que, no final das contas, existem três restrições que impedem o aumento:

1. A altura da div tem um limite (pode ser superada pela rolagem virtual)
2. Operações como classificação e pesquisa começam a ficar lentas depois de 1 milhão de registros
3. A RAM é limitada porque os dados são armazenados na matriz JavaScript

Eu testei a grade com 1 milhão de registros (exceto o IE) e funciona bem. Veja o artigo para demonstrações e exemplos.

O dojox.grid.DataGrid oferece uma abstração JS para dados, para que você possa conectá-lo a vários back-ends com os armazenamentos dojo.data fornecidos ou gravar seus próprios. Obviamente, você precisará de um que suporte acesso aleatório para tantos registros. O DataGrid também fornece acessibilidade total.

Edite, então aqui está um link para o artigo de Matthew Russell, que deve fornecer o exemplo de que você precisa, visualizando milhões de registros com dojox.grid. Observe que ele usa a versão antiga da grade, mas os conceitos são os mesmos, houve apenas algumas melhorias incompatíveis na API.

Ah, e é um código aberto totalmente gratuito.

Eu usei o jQuery Grid Plugin , foi legal.

Demonstrações

Aqui estão algumas otimizações que você pode aplicar para acelerar as coisas. Apenas pensando em voz alta.

Como o número de linhas pode estar na casa dos milhões, você desejará um sistema de armazenamento em cache apenas para os dados JSON do servidor. Não consigo imaginar alguém querendo baixar todos os X milhões de itens, mas se o fizessem, seria um problema. Este pequeno teste no Chrome para uma matriz com mais de 20 milhões de números inteiros trava na minha máquina constantemente.

var data = [];
for(var i = 0; i < 20000000; i++) {
    data.push(i);
}
console.log(data.length);​

Você pode usar LRU ou algum outro algoritmo de cache e ter um limite superior para a quantidade de dados que deseja armazenar em cache.

Para as próprias células da tabela, acho que construir / destruir nós DOM pode ser caro. Em vez disso, você pode predefinir o número X de células e sempre que o usuário rolar para uma nova posição, injetar os dados JSON nessas células. A barra de rolagem praticamente não teria relação direta com a quantidade de espaço (altura) necessária para representar o conjunto de dados inteiro. Você pode definir arbitrariamente a altura do contêiner da tabela, por exemplo, 5000 px e mapear isso para o número total de linhas. Por exemplo, se a altura do contêiner for 5000px e houver um total de 10 milhões de linhas, o starting row ≈ (scroll.top/5000) * 10Mwhere scroll.toprepresenta a distância de rolagem da parte superior do contêiner. Pequena demonstração aqui .

Para detectar quando solicitar mais dados, o ideal é que um objeto atue como um mediador que escute os eventos de rolagem. Esse objeto controla a rapidez com que o usuário está rolando e, quando parece que o usuário está mais lento ou parou completamente, faz uma solicitação de dados para as linhas correspondentes. A recuperação de dados dessa maneira significa que seus dados serão fragmentados; portanto, o cache deve ser projetado com isso em mente.

Além disso, os limites do navegador para o máximo de conexões de saída podem desempenhar um papel importante. Um usuário pode rolar para uma determinada posição que acionará uma solicitação AJAX, mas antes que isso termine, o usuário pode rolar para outra parte. Se o servidor não for responsivo o suficiente, as solicitações serão colocadas na fila e o aplicativo parecerá não responder. Você pode usar um gerenciador de solicitações através do qual todas as solicitações são roteadas e pode cancelar solicitações pendentes para liberar espaço.

Eu sei que é uma pergunta antiga, mas ainda assim. Há também o dhtmlxGrid que pode lidar com milhões de linhas. Há uma demonstração com 50.000 linhas, mas o número de linhas que podem ser carregadas / processadas na grade é ilimitado.

Disclaimer: Eu sou da equipe DHTMLX.

Eu sugiro que você leia isso

http://www.sitepen.com/blog/2008/11/21/effective-use-of-jsonreststore-referencing-lazy-loading-and-more/

Disclaimer: eu uso muito o YUI DataTable sem dor de cabeça por um longo tempo . É poderoso e estável. Para suas necessidades, você pode usar uma ScrollingDataTable que suporta

• rolagem x
• rolagem y
• rolagem xy
• Um poderoso mecanismo de eventos

Para o que você precisa, acho que você quer é um tableScrollEvent . Sua API diz

Disparado quando uma DataTable de rolagem fixa tem uma rolagem.

Como cada DataTable usa um DataSource, você pode monitorar seus dados por meio de tableScrollEvent junto com o tamanho do loop de renderização para preencher seu ScrollingDataTable de acordo com suas necessidades.

O tamanho do loop de renderização diz

Nos casos em que seu DataTable precise exibir a totalidade de um conjunto muito grande de dados, a configuração renderLoopSize pode ajudar a gerenciar a renderização DOM do navegador para que o encadeamento da UI não fique bloqueado em tabelas muito grandes . Qualquer valor maior que 0 fará com que a renderização do DOM seja executada nas cadeias setTimeout () que renderizam o número especificado de linhas em cada loop. O valor ideal deve ser determinado por implementação, uma vez que não existem regras rígidas e rápidas, apenas diretrizes gerais:

• Por padrão, renderLoopSize é 0, portanto, todas as linhas são renderizadas em um único loop. Um renderLoopSize> 0 adiciona sobrecarga, portanto, use com cuidado.
• Se seu conjunto de dados for grande o suficiente (número de linhas X número de complexidade de formatação das Colunas X) para que os usuários experimentem latência na renderização visual e / ou cause a interrupção do script, considere configurar um renderLoopSize .
• Um renderLoopSize abaixo de 50 provavelmente não vale a pena. Um renderLoopSize> 100 provavelmente é melhor.
• Um conjunto de dados provavelmente não é considerado grande o suficiente, a menos que tenha centenas e centenas de linhas.
• Ter um renderLoopSize> 0 e <total de linhas faz com que a tabela seja renderizada em um loop (o mesmo que renderLoopSize = 0), mas também aciona funcionalidades como a faixa de linhas pós-renderização para serem manipuladas a partir de um encadeamento setTimeout separado.

Por exemplo

// Render 100 rows per loop
 var dt = new YAHOO.widget.DataTable(<WHICH_DIV_WILL_STORE_YOUR_DATATABLE>, <HOW YOUR_TABLE_IS STRUCTURED>, <WHERE_DOES_THE_DATA_COME_FROM>, {
     renderLoopSize:100
 });

<WHERE_DOES_THE_DATA_COME_FROM> é apenas um único DataSource . Pode ser um JSON, JSFunction, XML e até um único elemento HTML

Aqui você pode ver um tutorial simples, fornecido por mim. Esteja ciente de que nenhum outro plug-in DATA_TABLE suporta clique único e duplo ao mesmo tempo. YUI DataTable permite que você. E mais, você pode usá-lo mesmo com o JQuery sem dor de cabeça

Alguns exemplos, você pode ver

• Item da lista

Sinta-se à vontade para fazer perguntas sobre qualquer outra coisa que desejar sobre o YUI DataTable.

Saudações,

Eu meio que falho em entender o ponto, para jqGrid você pode usar a funcionalidade de rolagem virtual:

http://www.trirand.net/aspnetmvc/grid/performancevirtualscrolling

mas, novamente, milhões de linhas com filtragem podem ser feitas:

http://www.trirand.net/aspnetmvc/grid/performancelinq

Eu realmente não vejo o ponto de "como se não houvesse páginas", quero dizer ... não há como exibir 1.000.000 de linhas ao mesmo tempo no navegador - são 10 MB de HTML bruto, meio que não consigo ver por que os usuários não gostariam de ver as páginas.

De qualquer forma...

A melhor abordagem que eu poderia pensar é carregando o bloco de dados no formato json para cada rolagem ou algum limite antes que a rolagem termine. O json pode ser facilmente convertido em objetos e, portanto, as linhas da tabela podem ser construídas facilmente e sem obstruções

Eu recomendo o Open rico . É difícil de implementar no começo, mas depois de agarrá-lo, você nunca mais olhará para trás.

Eu sei que essa pergunta tem alguns anos, mas o jqgrid agora suporta rolagem virtual:

http://www.trirand.com/blog/phpjqgrid/examples/paging/scrollbar/default.php

mas com paginação desativada

Sugiro grade sigma, a grade sigma incorpora recursos de paginação que podem suportar milhões de linhas. E também, você pode precisar de uma paginação remota para fazer isso. veja a demonstração http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Dê uma olhada no dGrid:

https://dgrid.io/

Concordo que os usuários NUNCA, NUNCA precisam visualizar milhões de linhas de dados de uma só vez, mas o dGrid pode exibi-los rapidamente (uma tela de cada vez).

Não ferva o oceano para fazer uma xícara de chá.