grade de dados JavaScript para milhões de linhas [fechado]

StackOverflow https://stackoverflow.com/questions/2402953

Pergunta

Eu preciso apresentar um grande número de linhas de dados (ie. Milhões de linhas) para o usuário em uma grade usando JavaScript.

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

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

Em vez de baixar os dados de uma só vez, pequenos pedaços são baixadas como o usuário vem a eles (ie., Percorrendo a rede).

As linhas não serão editadas através desta extremidade dianteira, de modo somente leitura grades são aceitáveis.

O que grades de dados, escritos em JavaScript, existem para este tipo de paginação perfeita?

Foi útil?

Solução

( Disclaimer: Eu sou o autor de SlickGrid )

Atualizar Isto já foi implementado em SlickGrid .

Por favor, veja http://github.com/mleibman/SlickGrid/issues#issue/ 22 para uma discussão em curso sobre como fazer o trabalho SlickGrid com maior número de linhas.

O problema é que SlickGrid não virtualizar a própria barra de rolagem - altura da área de rolagem é definida como a altura total de todas as linhas. As linhas ainda estão sendo adicionados e removidos como o usuário está em movimento, mas o próprio deslocamento é feito pelo navegador. Isso permite que ele seja muito rápido ainda suavizar (eventos OnScroll são notoriamente lenta). A ressalva é que existem erros / limites nos motores de CSS dos browsers que limitam a altura potencial de um elemento. Para o IE, que passa a ser 0x123456 ou 1193046 pixels. Para outros navegadores é mais elevado.

Há uma solução experimental no ramo "largenum-fix", que eleva esse limite significativamente preenchendo a área de rolagem com "páginas" conjunto de 1M pixels de altura e, em seguida, usando posicionamento relativo dentro dessas páginas. Uma vez que o limite de altura no motor CSS parece ser diferente e significativamente menor do que no motor de layout real, isso nos dá um limite muito mais elevado superior.

Eu ainda estou procurando uma maneira de chegar a um número ilimitado de linhas sem abrir mão da vantagem de desempenho que SlickGrid detém actualmente mais de outras implementações.

Rudiger, você pode elaborar sobre como você resolveu isso?

Outras dicas

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

" SlickGrid utiliza renderização virtual para que você possa facilmente trabalhar com centenas de milhares de itens, sem qualquer queda no desempenho. Na verdade, não há nenhuma diferença no desempenho entre trabalhar com uma grade com 10 linhas em comparação com um 100' 000 linhas. "

Alguns destaques:

  • rolagem virtual Adaptive (centenas alça de milhares de linhas)
  • extremamente rápida a velocidade de renderização
  • Fundo de pós-processamento para as células mais ricos
  • configurável e personalizável
  • navegação pelo teclado completa
  • Coluna de redimensionamento / reordenar / show / hide
  • Coluna autosizing & força-fit
  • formatadores e editores plugáveis ??celulares
  • O suporte para edição e criação de novas linhas. " por mleibman

É livre (licença MIT). Ele usa jQuery.

Os melhores Grids em minha opinião estão abaixo:

As minhas 3 melhores opções são jqGrid, jqxGrid e tabelas de dados. Eles podem trabalhar com milhares de linhas e virtualização de apoio.

Eu não quero iniciar uma guerra, mas assumindo seus pesquisadores são humanos, você não conhecê-los, assim como você pensa. Só porque eles Have petabytes de dados não torná-los capazes de ver até mesmo milhões de registros de qualquer maneira significativa. Eles poderiam dizer que eles deseja para ver milhões de registros, mas isso é bobagem. Ter seus pesquisadores mais inteligentes fazer alguma matemática básica: Suponha que eles passam um segundo visualização de cada registro. Nesse ritmo, vai demorar 1000000 segundos, que funciona a mais de seis semanas (de 40 horas de trabalho semanas sem pausas para comida ou banheiro).

Será que eles (ou você) pensar seriamente uma pessoa (o olhar para a grade) pode reunir esse tipo de concentração? Eles estão realmente ficando muito feito em que 1 segundo, ou são (mais provável) filtrar o material do não quer? Eu suspeito que depois de ver um subconjunto "de tamanho razoável", que poderia descrever um filtro para você que filtrar automaticamente os registros.

Como paxdiablo e Sleeper Smith e Lasse V Karlsen também implicou, você (e eles) não ter pensado os requisitos. No lado do para cima, agora que você encontrou SlickGrid, tenho certeza que a necessidade de esses filtros tornou-se imediatamente óbvio.

eu posso dizer com certeza bom bonito que você seriamente não precisa mostrar a milhões de linhas de dados para o usuário.

Não existe nenhum utilizador no mundo que será capaz de compreender ou gerir esse conjunto de dados assim mesmo se você gerenciar tecnicamente para retirá-lo, você não vai resolver qualquer problema conhecido para esse usuário.

Em vez disso eu iria incidir sobre por o usuário deseja ver os dados. O usuário não quiser ver os dados apenas para ver os dados, geralmente há uma questão que se coloca. Se você se concentrar em responder a estas questões em vez disso, então você estaria muito mais perto de algo que resolve um problema real.

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

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

dojox.grid.DataGrid oferece uma abstração JS para dados para que você possa ligá-lo a vários backends com lojas dojo.data prestados ou escrever a sua própria. obviamente você vai precisar de um que suporta acesso aleatório para isso muitos registros. DataGrid também fornece acessibilidade plena.

Editar então aqui está um link para a Matthew Russell artigo que deve fornecer o exemplo que você precisa, vendo milhões de registros com dojox.grid. Note que ele usa a versão antiga do grid, mas os conceitos são os mesmos, havia apenas algumas melhorias incompatível API.

Oh, e é open source totalmente gratuito.

(Disclaimer: Eu sou o autor de w2ui)

Eu escrevi recentemente um artigo sobre como implementar grade JavaScript com 1 milhão de registros ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Descobri que, em última análise, há 3 restrições que impedem de tomá-lo highter:

  1. Altura da div tem um limite (pode ser superado pela rolagem virtual)
  2. As operações como classificar e pesquisar começar a ser lenta após 1 milhão de registros ou menos
  3. RAM é limitada porque os dados são armazenados na matriz JavaScript

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

Aqui estão algumas das otimizações que você pode aplicar a acelerar as coisas. Só de pensar em voz alta.

Uma vez que o número de linhas pode ser na casa dos milhões, você vai querer um sistema de cache apenas para os dados JSON a partir do servidor. Eu não posso imaginar qualquer pessoa que queira baixar todas X milhão de itens, mas se o fizessem, seria um problema. Este pouco teste no Chrome para um array de inteiros 20M + cai 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 têm um limite superior na a quantidade de dados que você está disposto a cache.

Para os próprios células da tabela, eu acho que a construção / destruição de nós DOM pode ser caro. Em vez disso, você poderia apenas pré-definir um número X de células, e sempre que o usuário rola para uma nova posição, injetar os dados JSON para estas células. A barra de rolagem que praticamente não têm relação direta com a quantidade de espaço (altura) é necessário para representar todo o conjunto de dados. Você poderia arbitrariamente definir a altura do recipiente mesa, dizer 5000px, e mapear isso para o número total de linhas. Por exemplo, se a altura de recipientes é 5000px e existem um total de 10 milhões de linhas, em seguida, o starting row ≈ (scroll.top/5000) * 10M onde scroll.top representa a distância de deslocamento a partir do topo do recipiente. pequena demonstração aqui .

Para detectar quando a pedir mais dados, o ideal é um objeto deve agir como um mediador que escuta eventos de rolagem. Este objeto mantém o controle de quão rápido o usuário está em movimento, e quando parece que o utilizador está a abrandar ou parou completamente, faz uma solicitação de dados para as linhas correspondentes. Recuperando dados desta forma significa que seus dados vai ser fragmentado, então o cache deve ser projetado com isso em mente.

Além disso, os limites do navegador no máximo de conexões de saída podem desempenhar um papel importante. Um usuário pode rolar para uma determinada posição que irá disparar uma solicitação AJAX, mas antes que termina o usuário pode rolar para alguma outra parte. Se o servidor não é suficiente sensível as solicitações iria ficar na fila e a aplicação ficará sem resposta. Você poderia usar um gerenciador de pedido através do qual todas as solicitações são encaminhadas, e pode cancelar pedidos ao espaço make pendente.

Eu sei que é uma questão antiga, mas ainda .. Há também 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 carregados / processados ??na rede é ilimitado.

Disclaimer:. Eu sou da equipe DHTMLX

Disclaimer: i muito YUI DataTable sem nenhuma dor de cabeça por um longo tempo . Ele é forte e estável. Para as suas necessidades, você pode usar um ScrollingDataTable wich suports

  • x-scrolling
  • -y scrolling
  • -xy rolagem
  • Um mecanismo poderoso evento

Por que você precisa, eu acho que você quer é uma tableScrollEvent . Sua API diz

Fired quando um DataTable rolagem fixo tem um pergaminho.

Como cada DataTable usa uma fonte de dados, você pode monitorar seus dados através tableScrollEvent juntamente com prestar tamanho do loop , a fim de preencher o seu ScrollingDataTable acordo com suas necessidades.

Render tamanho do loop diz

Nos casos em que as suas necessidades de DataTable para exibir a totalidade de um conjunto muito grande de dados, a configuração renderLoopSize pode ajudar a gerenciar renderização para que o segmento de interface do usuário não fique trancado em tabelas muito grandes . Qualquer valor superior a 0 fará com que a renderização DOM a ser executado em setTimeout () cadeias que tornam o número especificado de linhas em cada loop. O valor ideal deve ser determinada por aplicação, pois não existem regras rígidas e rápidas, apenas orientações gerais:

  • Por renderLoopSize padrão é 0, portanto, todas as linhas são processadas em um único laço. A renderLoopSize> 0 adiciona sobrecarga então use pensativo.
  • Se o seu conjunto de dados é grande o suficiente (número de linhas X número de colunas X complexidade formatação) que os usuários experimentam latência no processamento visual e / ou faz com que o script para pendurar, considerar a criação de um renderLoopSize .
  • A renderLoopSize menos de 50 anos provavelmente não vale a pena. A renderLoopSize> 100 é provavelmente melhor.
  • Um conjunto de dados provavelmente não é considerado grande o suficiente a menos que tenha centenas e centenas de linhas.
  • Tendo um renderLoopSize> 0 e

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
 });

é apenas um único DataSource . Pode ser JSON, JsFunction, um XML e até mesmo um único elemento HTML

Aqui você pode ver um tutorial simples, desde que por mim. Esteja ciente de nenhuma outra suportes pluglin DATA_TABLE simples e dupla clique ao mesmo tempo. YUI DataTable permite. E mais, você pode usá-lo mesmo com JQuery, sem nenhuma dor de cabeça

Alguns exemplos, você pode ver

Sinta-se livre para pergunta sobre qualquer outra coisa que quiser sobre YUI DataTable.

Atenciosamente,

Eu meio que não conseguem ver 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 a filtragem pode ser feito:

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

Eu realmente não vejo o ponto de "como se não existem páginas", embora, quero dizer ... não há nenhuma maneira de exibir 1.000.000 linhas de uma vez no navegador - este é 10MB de HTML cru, I tipo de não conseguem ver por que os usuários não gostaria de ver as páginas.

De qualquer forma ...

melhor abordagem que eu poderia pensar é por carregar o bloco de dados no formato JSON para cada rolagem ou algum limite antes de terminar a rolagem. json podem ser facilmente convertidos em objetos e, portanto, as linhas da tabela podem ser construídos facilmente discretamente

Eu recomendo Abrir rico . É difícil de implementar no início, mas uma vez que você pegá-lo você nunca vai olhar para trás.

Eu sei que esta questão é de alguns anos, mas jqgrid agora suporta rolagem virtual:

http://www.trirand.com/blog/ phpjqgrid / examples / paginação / barra de rolagem / default.php

mas com a paginação desativada

Eu sugiro grade sigma, grade sigma tem incorporar recursos de paginação que poderia suportar milhões de linhas. E também, você pode precisar de uma paginação remoto para fazê-lo. veja a demo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details. html

Dê uma olhada dGrid:

https://dgrid.io/

Eu concordo que os usuários nunca, nunca precisa ver milhões de linhas de dados de uma só vez, mas dGrid pode exibi-los rapidamente (uma tela cheia de cada vez).

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

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top