Domanda

Devo presentare un gran numero di righe di dati (es.milioni di righe) all'utente in una griglia utilizzando JavaScript.

L'utente non dovrebbe vedere pagine o visualizzare solo quantità limitate di dati alla volta.

Piuttosto, dovrebbe sembrare che tutti i dati siano disponibili.

Invece di scaricare i dati tutti in una volta, vengono scaricati piccoli blocchi man mano che l'utente li accede (ad es.scorrendo la griglia).

Le righe non verranno modificate tramite questo front-end, quindi sono accettabili griglie di sola lettura.

Quali griglie di dati, scritte in JavaScript, esistono per questo tipo di paginazione senza soluzione di continuità?

È stato utile?

Soluzione

( Disclaimer: io sono l'autore di SlickGrid )

Aggiorna Questo ora è stato implementato in SlickGrid .

Si prega di consultare http://github.com/mleibman/SlickGrid/issues#issue/ 22 per una discussione in corso sul rendere il lavoro SlickGrid con un maggior numero di righe.

Il problema è che SlickGrid non virtualizza la barra di scorrimento in sé - l'altezza della zona scorrevole è impostato per l'altezza totale di tutte le righe. Le righe vengono ancora aggiunti e rimossi come l'utente scorre, ma lo scorrimento si è fatto dal browser. Che gli permette di essere molto veloce ma liscia (eventi onscroll sono notoriamente lento). L'avvertenza è che ci sono bug / limiti nei motori di CSS browser che limitano l'altezza potenziale di un elemento. Per IE, che sembra essere 0x123456 o 1193046 pixel. Per altri browser è più alto.

C'è un soluzione sperimentale nel ramo "largenum-fix" che genera tale limite significativamente compilando dell'area scorrevole con "pagine" impostato 1M altezza pixel e quindi utilizzando posizionamento relativo all'interno di quelle pagine. Dal momento che il limite di altezza nel motore CSS sembra essere diverso e significativamente inferiore rispetto al motore di layout attuale, questo ci dà un limite superiore molto più elevato.

Sono ancora alla ricerca di un modo per arrivare a un numero illimitato di righe senza rinunciare al vantaggio di prestazioni che SlickGrid attualmente detiene oltre altre implementazioni.

Rudiger, si può elaborare su come avete risolto questo?

Altri suggerimenti

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

"SlickGrid utilizza il rendering virtuale per consentirti di lavorare facilmente con centinaia di migliaia di elementi senza alcun calo delle prestazioni.In effetti, non vi è alcuna differenza di prestazioni tra lavorare con una griglia con 10 righe rispetto a una con 100.000 righe."

Alcuni punti salienti:

  • Scorrimento virtuale adattivo (gestire centinaia di migliaia di righe)
  • Velocità di rendering estremamente elevata
  • Post-rendering dello sfondo per celle più ricche
  • Configurabile e personalizzabile
  • Navigazione completa tramite tastiera
  • Ridimensionare/riordinare/mostrare/nascondere le colonne
  • Dimensionamento automatico e adattamento forzato della colonna
  • Formattatori ed editor di celle collegabili
  • Supporto per la modifica e la creazione di nuove righe." di mleibman

È gratuito (licenza MIT).Utilizza jQuery.

Le migliori Griglie a mio parere sono al di sotto:

I miei migliori 3 opzioni sono jqGrid, jqxGrid e DataTable. Possono lavorare con migliaia di righe e di virtualizzazione di supporto.

Non intendo iniziare una guerra di fiamma, ma assumendo i vostri ricercatori sono umani, non li conosco così come si pensa. Solo perché sono petabyte di dati non li rende in grado di visualizzare anche milioni di record in modo significativo. Potrebbero dire che vogliono per vedere milioni di record, ma questo è solo stupido. Le tue ricercatori più brillanti fare un po 'di matematica di base: Si supponga che spendono 1 secondo la visualizzazione di ogni record. Di questo passo, ci vorranno 1000000 secondi, che funziona a più di sei settimane (di 40 ore di lavoro settimane senza interruzioni per il cibo o WC).

Non hanno (o voi) seriamente pensare una persona (l'uno guardando la griglia) riesce a raccogliere questo tipo di concentrazione? Sono davvero sempre molto fatto in quel 1 secondo, o sono (più probabilmente) filtrare la roba non vuole? Ho il sospetto che dopo aver visto un sottoinsieme "di dimensioni ragionevoli", si potrebbe descrivere un filtro a voi che sarebbe filtrare automaticamente i record.

Come paxdiablo e Sleeper Smith e Lasse V Karlsen anche implicita, voi (e loro) non hanno pensato attraverso i requisiti. D'altro canto, ora che avete trovato SlickGrid, sono sicuro che la necessità di questi filtri è diventato subito evidente.

posso dire con abbastanza buona certezza che sul serio non c'è bisogno di mostrare a milioni di righe di dati per l'utente.

Non c'è nessun utente al mondo che sarà in grado di comprendere o il gestore di quel set di dati in modo anche se si riesce tecnicamente per tirarlo fuori, non sarà possibile risolvere qualsiasi problema noto per l'utente.

Invece mi concentrerò su perché l'utente vuole vedere i dati. L'utente non vuole vedere i dati solo per vedere i dati, di solito c'è una domanda che si pone. Se ti concentri sulla risolvere tali questioni, invece, allora si sarebbe molto più vicino a qualcosa che risolve un problema reale.

Vi consiglio l'Ext JS griglia con la funzione Buffered View.

http://www.extjs.com/deploy/dev/ esempi / griglia / buffer.html

dojox.grid.DataGrid offre un'astrazione JS per i dati in modo da poter collegare fino a che vari backend con negozi di dojo.data forniti o lascia la tua. Avrete ovviamente bisogno di uno che supporta l'accesso casuale per questo molti record. DataGrid prevede anche la piena accessibilità.

Modifica quindi ecco un link di Matthew Russell articolo che dovrebbe fornire l'esempio è necessario, la visualizzazione di milioni di dischi con dojox.grid. Si noti che utilizza la versione della griglia, ma i concetti sono gli stessi, c'erano solo alcuni miglioramenti API incompatibili.

Oh, ed è completamente gratuito open source.

(Disclaimer: io sono l'autore di w2ui)

Di recente ho scritto un articolo su come implementare griglia JavaScript con 1 milione di record ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Ho scoperto che in ultima analisi, ci sono 3 le restrizioni che impediscono di prenderlo highter:

  1. Altezza del div ha un limite (può essere superato da scrolling virtuale)
  2. Operazioni come ordinare e cercare iniziano ad essere lenta dopo 1 milione di record o giù di lì
  3. RAM è limitato perché i dati sono memorizzati in array JavaScript

Ho testato la griglia con 1 milione di record (ad eccezione di IE) e si comporta bene. Vedi articolo per demo ed esempi.

Ecco un paio di ottimizzazioni che si possono applicare a velocizzare le cose. Basta pensare ad alta voce.

Dal momento che il numero di righe può essere in milioni, si vuole un sistema di caching solo per i dati JSON dal server. Non riesco a immaginare chiunque voglia scaricare tutta X milioni di pezzi, ma se lo facessero, sarebbe un problema. Questo po prova su Chrome per una serie su 20M + interi crash sulla mia macchina costantemente.

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

Si potrebbe utilizzare LRU o qualche altro algoritmo di caching e hanno un limite superiore la quantità di dati che si è disposti a cache.

Per le celle della tabella stessi, credo che la costruzione / distruzione di nodi DOM può essere costoso. Invece, si può solo predefinire un numero X di cellule, e ogni volta che l'utente scorre ad una nuova posizione, iniettare i dati JSON in queste cellule. La barra di scorrimento avrebbe praticamente non hanno alcuna relazione diretta con la quantità di spazio (altezza) è necessario per rappresentare l'intero set di dati. Si potrebbe arbitrariamente impostare l'altezza del contenitore da tavolo, dire 5000px, e mappare che al numero totale di righe. Ad esempio, se l'altezza contenitori è 5000px e ci sono un totale di 10M righe, allora il starting row ≈ (scroll.top/5000) * 10M dove scroll.top rappresenta la distanza di scorrimento dalla parte superiore del contenitore. piccola demo qui .

Per rilevare quando per richiedere più dati, idealmente un oggetto dovrebbe agire come un mediatore che ascolta per scorrere gli eventi. Questo oggetto tiene traccia di quanto velocemente l'utente sta scorrendo, e quando sembra che l'utente sta rallentando o sia completamente arrestato, effettua una richiesta di dati per righe corrispondenti. Il recupero dei dati in questo modo significa che i dati sta per essere frammentato, per cui la cache deve essere progettato con questo in mente.

Anche i limiti del browser sul numero massimo di connessioni in uscita possono svolgere un ruolo importante. Un utente può scorrere fino a una certa posizione che sparare una richiesta AJAX, ma prima che finisce l'utente può scorrere a qualche altra parte. Se il server non è abbastanza reattivo alle richieste otterrebbe in coda e l'applicazione avrà un aspetto non risponde. Si potrebbe utilizzare un gestore di richiesta attraverso il quale vengono instradati tutte le richieste, ed è possibile annullare le richieste in attesa per fare spazio.

Lo so che è una vecchia questione, ma ancora .. C'è anche dhtmlxGrid in grado di gestire milioni di righe. C'è un rel="nofollow"> demo ma il numero di righe che possono essere caricati / trasformati in griglia è illimitata.

Disclaimer: io sono di squadra DHTMLX

.

Disclaimer:io pesantemente utilizzo Tabella dati YUI senza mal di testa per molto tempo.È potente e stabile.Per le tue esigenze, puoi utilizzare a ScrollingDataTable che sostiene

  • scorrimento x
  • scorrimento y
  • scorrimento xy
  • Un potente meccanismo di eventi

Per quello che ti serve, penso che tu voglia è a tableScrollEvent.La sua API dice

Attivato quando un DataTable a scorrimento fisso ha uno scorrimento.

Poiché ogni DataTable utilizza un DataSource, puoi monitorare i suoi dati tramite tableScrollEvent insieme alla dimensione del ciclo di rendering per popolare la tua ScrollingDataTable in base alle tue esigenze.

Dice la dimensione del loop di rendering

Nei casi in cui DataTable deve visualizzare l'intero set di dati molto ampio, la configurazione renderLoopSize può aiutare a gestire il rendering DOM del browser in modo che il thread dell'interfaccia utente non venga bloccato su tabelle molto grandi.Qualsiasi valore maggiore di 0 causerà l'esecuzione del rendering DOM nelle catene setTimeout() che eseguono il rendering del numero specificato di righe in ogni ciclo.Il valore ideale dovrebbe essere determinato per implementazione poiché non esistono regole rigide e veloci, solo linee guida generali:

  • Per impostazione predefinita renderLoopSize è 0, quindi tutte le righe vengono renderizzate in un singolo ciclo.Un renderLoopSize > 0 aggiunge un sovraccarico, quindi usalo con attenzione.
  • Se il tuo set di dati è abbastanza grande (numero di righe X numero di colonne X complessità di formattazione) che gli utenti riscontrano latenza nel rendering visivo e/o causano il blocco dello script, considera l'impostazione di renderLoopSize.
  • Un renderLoopSize inferiore a 50 probabilmente non ne vale la pena.Un renderLoopSize > 100 è probabilmente migliore.
  • Un set di dati probabilmente non è considerato sufficientemente grande a meno che non contenga centinaia e centinaia di righe.
  • Avere un renderLoopSize > 0 e < righe totali fa sì che la tabella venga renderizzata in un ciclo (come renderLoopSize = 0) ma attiva anche funzionalità come lo striping delle righe post-rendering da gestire da un thread setTimeout separato.

Ad esempio

// 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> è solo un singolo Fonte di dati.Può essere un JSON, JSFunction, XML e persino un singolo elemento HTML

Qui puoi vedere un semplice tutorial, fornito da me.Sii consapevole nessun altro Il plug-in DATA_TABLE supporta il clic singolo e doppio contemporaneamente.YUI DataTable ti consente.E altro ancora, puoi usarlo anche con JQuery senza problemi

Alcuni esempi, potete vederli

Sentiti libero di fare domande su qualsiasi altra cosa desideri su YUI DataTable.

saluti,

I tipi di riesco a vedere il punto, per jqGrid è possibile utilizzare la funzionalità di scrolling virtuale:

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

ma poi di nuovo, milioni di righe con il filtraggio può essere fatto:

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

Io davvero non riesco a vedere il punto di "come se non ci sono pagine", però, voglio dire ... non c'è modo di visualizzare 1.000.000 file in una sola volta nel browser - questo è di 10 MB di HTML grezzo, io tipo di non riescono a capire perché gli utenti non vogliono vedere le pagine.

In ogni caso ...

approccio migliore che potrei pensare è caricando il blocco di dati in formato JSON per ogni libro e di un limite prima della fine di scorrimento. json può essere facilmente convertito in oggetti e quindi le righe della tabella può essere costruita facilmente discretamente

Mi raccomando Aprire rico . E 'difficile da attuare nel principio, ma una volta che si afferra che non si sarà mai guardare indietro.

So che questa domanda è vecchia di qualche anno, ma jqGrid ora supporta lo scorrimento virtuale:

http://www.trirand.com/blog/ phpjqgrid / examples / paging / barra di scorrimento / default.php

ma con impaginazione disabilitato

Suggerisco funzioni di paging griglia Sigma, Sigma griglia ha incorporare, che potrebbero sostenere milioni di righe. E inoltre, potrebbe essere necessario un pagina remota per farlo. vedere la demo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details. html

Date un'occhiata a dGrid:

https://dgrid.io/

Sono d'accordo che gli utenti non sarà mai, mai bisogno di visualizzare milioni di righe di dati tutti in una volta, ma dGrid posso visualizzare rapidamente (una schermata alla volta).

Non bollire l'oceano per fare una tazza di tè.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top