Griglia dati JavaScript per milioni di righe [chiuso]

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

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

Piuttosto, dovrebbe sembrare che tutti i dati siano disponibili.

Invece di scaricare i dati tutti in una volta, i piccoli pezzi vengono scaricati man mano che l'utente arriva a loro (cioè scorrendo la griglia).

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

Quali griglie di dati, scritte in JavaScript, esistono per questo tipo di paging continuo?

( Dichiarazione di non responsabilità: sono l'autore di SlickGrid )

AGGIORNAMENTO Questo è stato ora implementato in SlickGrid .

Si prega di consultare http://github.com/mleibman/SlickGrid/issues#issue/22 per una discussione in corso su come far funzionare SlickGrid con un numero maggiore di righe.

Il problema è che SlickGrid non virtualizza la barra di scorrimento stessa: l'altezza dell'area scorrevole è impostata sull'altezza totale di tutte le righe. Le righe vengono ancora aggiunte e rimosse mentre l'utente scorre, ma lo scorrimento stesso viene eseguito dal browser. Ciò gli consente di essere molto veloce ma fluido (gli eventi onscroll sono notoriamente lenti). L'avvertenza è che ci sono bug / limiti nei motori CSS del browser che limitano l'altezza potenziale di un elemento. Per IE, sembra che sia 0x123456 o 1193046 pixel. Per altri browser è più alto.

Esiste una soluzione sperimentale nel ramo "largenum-fix" che aumenta significativamente tale limite popolando l'area scorrevole con "pagine" impostate su 1 M di altezza pixel e quindi utilizzando il posizionamento relativo all'interno di tali pagine. Poiché il limite di altezza nel motore CSS sembra essere diverso e significativamente inferiore rispetto al motore di layout effettivo, questo ci dà un limite superiore molto più alto.

Sto ancora cercando un modo per raggiungere un numero illimitato di righe senza rinunciare al vantaggio prestazionale che SlickGrid attualmente detiene su altre implementazioni.

Rudiger, puoi approfondire come l'hai risolto?

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

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

Alcuni punti salienti:

• Scorrimento virtuale adattivo (gestire centinaia di migliaia di righe)
• Velocità di rendering estremamente elevata
• Post-rendering in background per celle più ricche
• Configurabile e personalizzabile
• Navigazione completa della tastiera
• Ridimensionamento colonna / riordina / mostra / nascondi
• Colonna autosizing e force-fit
• Formatter e editor di celle collegabili
• Supporto per la modifica e la creazione di nuove righe. "di mleibman

È gratuito (licenza MIT). Usa jQuery.

Le migliori griglie secondo me sono di seguito:

• Flexigrid: http://flexigrid.info/
• Griglia jQuery: 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

Le mie 3 migliori opzioni sono jqGrid, jqxGrid e DataTables. Possono lavorare con migliaia di righe e supportare la virtualizzazione.

Non intendo iniziare una guerra alla fiamma, ma supponendo che i tuoi ricercatori siano umani, non li conosci bene come pensi. Solo perché hanno petabyte di dati non li rende in grado di visualizzare anche milioni di record in modo significativo. Potrebbero dire di voler vedere milioni di dischi, ma è solo sciocco. Chiedi ai tuoi ricercatori più intelligenti di fare alcuni calcoli di base: supponi che trascorrano 1 secondo a visualizzare ciascun record. A quel ritmo, ci vorranno 1000000 secondi, che dura più di sei settimane (di 40 ore di lavoro settimanali senza interruzioni per cibo o servizi igienici).

Pensano (o tu) seriamente che una persona (quella che guarda la griglia) possa raccogliere quel tipo di concentrazione? Stanno davvero facendo molto in quel 1 secondo o (più probabilmente) filtrano le cose che non vogliono? Sospetto che dopo aver visualizzato un sottoinsieme di "dimensioni ragionevoli", potrebbero descriverti un filtro che filtrerebbe automaticamente quei record.

Come implicano anche paxdiablo e Sleeper Smith e Lasse V Karlsen, voi (e loro) non avete riflettuto sui requisiti. Sul lato positivo, ora che hai trovato SlickGrid, sono sicuro che la necessità di quei filtri è diventata immediatamente ovvia.

Posso affermare con certezza che non è necessario mostrare all'utente milioni di file di dati.

Non esiste nessun utente al mondo in grado di comprendere o gestire quel set di dati, quindi anche se tecnicamente riuscirai a risolverlo, non risolverai alcun problema noto per quell'utente.

Invece mi concentrerei sul 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 viene posta. Se invece ti concentri sulla risposta a queste domande, allora saresti molto più vicino a qualcosa che risolve un problema reale.

Consiglio Ext JS Grid con la funzione Buffered View.

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

(Dichiarazione di non responsabilità: sono l'autore di w2ui)

Di recente ho scritto un articolo su come implementare la griglia JavaScript con 1 milione di record ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Ho scoperto che alla fine ci sono 3 restrizioni che impediscono di prenderlo più in alto:

1. L'altezza del div ha un limite (può essere superata mediante scorrimento virtuale)
2. Operazioni come l'ordinamento e la ricerca iniziano a essere lente dopo circa 1 milione di record
3. La RAM è limitata perché i dati sono memorizzati nell'array JavaScript

Ho testato la griglia con 1 milione di record (tranne IE) e funziona bene. Vedi l'articolo per demo ed esempi.

dojox.grid.DataGrid offre un'astrazione JS per i dati in modo che tu possa collegarlo a vari back-end con negozi dojo.data forniti o scrivere il tuo. Avrai ovviamente bisogno di uno che supporti l'accesso casuale per così tanti record. DataGrid offre anche piena accessibilità.

Modifica quindi ecco un link all'articolo di Matthew Russell che dovrebbe fornire l'esempio di cui hai bisogno, visualizzando milioni di record con dojox.grid. Si noti che utilizza la vecchia versione della griglia, ma i concetti sono gli stessi, c'erano solo alcuni miglioramenti API incompatibili.

Oh, ed è totalmente open source gratuito.

Ho usato jQuery Grid Plugin , è stato bello.

Demos

Ecco un paio di ottimizzazioni che puoi applicare per accelerare le cose. Sto solo pensando ad alta voce.

Poiché il numero di righe può essere in milioni, è necessario un sistema di memorizzazione nella cache solo per i dati JSON dal server. Non riesco a immaginare nessuno che voglia scaricare tutti gli X milioni di articoli, ma se lo facessero, sarebbe un problema. Questo piccolo test su Chrome per un array su 20M + numeri interi si blocca costantemente sulla mia macchina.

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

È possibile utilizzare LRU o qualche altro algoritmo di memorizzazione nella cache e avere un limite superiore alla quantità di dati che si desidera memorizzare nella cache.

Per le stesse celle di tabella, penso che costruire / distruggere nodi DOM possa essere costoso. Invece, potresti semplicemente pre-definire il numero X di celle e ogni volta che l'utente scorre in una nuova posizione, iniettare i dati JSON in queste celle. La barra di scorrimento non avrebbe praticamente alcuna relazione diretta con la quantità di spazio (altezza) necessaria per rappresentare l'intero set di dati. È possibile impostare arbitrariamente l'altezza del contenitore della tabella, ad esempio 5000px, e mapparla sul numero totale di righe. Ad esempio, se l'altezza contenitori è 5000px e ci sono un totale di righe 10M, quindi il starting row ≈ (scroll.top/5000) * 10Mquale scroll.toprappresenta la distanza di scorrimento dalla parte superiore del contenitore. Piccola demo qui .

Per rilevare quando richiedere più dati, idealmente un oggetto dovrebbe fungere da mediatore che ascolta gli eventi di scorrimento. Questo oggetto tiene traccia della velocità con cui l'utente scorre, e quando sembra che l'utente stia rallentando o si sia completamente arrestato, effettua una richiesta di dati per le righe corrispondenti. Recuperare i dati in questo modo significa che i tuoi dati saranno frammentati, quindi la cache dovrebbe essere progettata tenendo presente questo aspetto.

Anche i limiti del browser per le connessioni in uscita massime possono svolgere un ruolo importante. Un utente può scorrere fino a una determinata posizione che genererà una richiesta AJAX, ma prima che ciò finisca l'utente può scorrere fino a qualche altra porzione. Se il server non è abbastanza reattivo, le richieste verrebbero messe in coda e l'applicazione non risponderà. È possibile utilizzare un gestore richieste attraverso il quale vengono instradate tutte le richieste e può annullare le richieste in sospeso per fare spazio.

So che è una vecchia domanda, ma comunque ... C'è anche dhtmlxGrid che può gestire milioni di righe. Esiste una demo con 50.000 righe ma il numero di righe che è possibile caricare / elaborare nella griglia è illimitato.

Disclaimer: vengo dal team DHTMLX.

Ti suggerisco di leggere questo

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

Disclaimer: io pesantemente uso YUI DataTable senza alcun mal di testa per un lungo periodo di tempo . È potente e stabile. Per le tue esigenze, puoi utilizzare una tabella ScrollingData che supporta

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

Per quello che ti serve, penso che tu voglia sia un tableScrollEvent . La sua API dice

Attivato quando una DataTable a scorrimento fisso ha uno scorrimento.

Poiché ogni DataTable utilizza una DataSource, è possibile monitorare i suoi dati tramite tableScrollEvent insieme alle dimensioni del loop di rendering al fine di popolare la ScrollingDataTable in base alle proprie esigenze.

Indica la dimensione del loop di rendering

Nei casi in cui DataTable deve visualizzare l'insieme di un 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 farà eseguire il rendering DOM in catene setTimeout () che eseguono il rendering del numero specificato di righe in ciascun ciclo. Il valore ideale dovrebbe essere determinato per implementazione poiché non esistono regole rigide e veloci, ma solo linee guida generali:

• Per impostazione predefinita, renderLoopSize è 0, quindi tutte le righe sono visualizzate in un singolo ciclo. Un renderLoopSize> 0 aggiunge un sovraccarico, quindi usalo attentamente.
• Se il tuo set di dati è abbastanza grande (numero di righe X numero di complessità di formattazione Colonne X) che gli utenti sperimentano la latenza nel rendering visivo e / o causa il blocco dello script, considera l'impostazione di renderLoopSize .
• Un renderLoopSize sotto 50 probabilmente non ne vale la pena. Un renderLoopSize> 100 è probabilmente migliore.
• Un set di dati probabilmente non è considerato abbastanza grande a meno che non abbia centinaia e centinaia di righe.
• Avere renderLoopSize> 0 e <righe totali fa sì che la tabella sia renderizzata in un ciclo (uguale a renderLoopSize = 0) ma innesca anche funzionalità come lo striping di righe post-rendering da gestire da un thread setTimeout separato.

Per 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 una singola origine dati . Può essere un JSON, JSFunction, XML e persino un singolo elemento HTML

Qui puoi vedere un semplice tutorial, fornito da me. Essere consapevoli senza altri supporti DATA_TABLE pluglin singolo e doppio click allo stesso tempo. YUI DataTable ti consente. Inoltre, puoi usarlo anche con JQuery senza mal di testa

Alcuni esempi, puoi vedere

• Voce di elenco

Sentiti libero di fare domande su tutto ciò che desideri su YUI DataTable.

Saluti,

Non riesco a vedere il punto, per jqGrid puoi usare la funzionalità di scorrimento virtuale:

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

ma poi di nuovo, è possibile eseguire milioni di righe con filtro:

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

Non riesco davvero a vedere il punto di "come se non ci fossero pagine" però, intendo ... non c'è modo di visualizzare 1.000.000 di righe contemporaneamente nel browser - si tratta di 10 MB di HTML grezzo, non riesco a vedere perché gli utenti non vorrebbero vedere le pagine.

Comunque...

il miglior approccio che mi viene in mente è quello di caricare il blocco di dati in formato json per ogni scorrimento o qualche limite prima che lo scorrimento termini. json può essere facilmente convertito in oggetti e quindi le righe della tabella possono essere costruite facilmente in modo discreto

Consiglio vivamente Open rico . È difficile da implementare all'inizio, ma una volta che lo afferrerai non tornerai mai indietro.

So che questa domanda ha alcuni anni, ma jqgrid ora supporta lo scorrimento virtuale:

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

ma con l'impaginazione disabilitata

Suggerisco sigma grid, sigma grid ha incorporato funzionalità di paging che potrebbero supportare milioni di righe. Inoltre, potrebbe essere necessario un paging remoto per farlo. vedi la demo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Dai un'occhiata a dGrid:

https://dgrid.io/

Concordo sul fatto che gli utenti non dovranno MAI, MAI visualizzare milioni di righe di dati contemporaneamente, ma dGrid può visualizzarle rapidamente (uno schermo alla volta).

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