grille de données JavaScript pour des millions de lignes [fermé]

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

Question

Je dois présenter un grand nombre de lignes de données (ie. Des millions de lignes) à l'utilisateur dans une grille en utilisant JavaScript.

L'utilisateur ne doit pas voir les pages ou afficher uniquement des quantités limitées de données à la fois.

Au contraire, il apparaît que toutes les données sont disponibles.

Au lieu de télécharger les données à la fois, de petits morceaux sont téléchargés que l'utilisateur vient à eux (ie. En faisant défiler à travers la grille).

Les lignes ne seront pas modifiées par cette extrémité avant, de sorte lecture seule grilles sont acceptables.

Qu'est-ce que les grilles de données, écrit en JavaScript, existent pour ce genre de pagination transparente?

Était-ce utile?

La solution

( Disclaimer: Je suis l'auteur de SlickGrid )

UPDATE Cela a été mis en œuvre dans SlickGrid .

S'il vous plaît voir http://github.com/mleibman/SlickGrid/issues#issue/ 22 pour une discussion en cours sur les travaux faisant SlickGrid avec un plus grand nombre de lignes.

Le problème est que SlickGrid ne virtualise pas la barre de défilement lui-même - la hauteur de la zone de défilement est réglée sur la hauteur totale de toutes les lignes. Les lignes sont toujours ajoutés et supprimés lorsque l'utilisateur défile, mais le défilement s'est fait par le navigateur. Cela lui permet d'être très rapide mais lisse (événements OnScroll sont notoirement lents). La mise en garde est qu'il ya des bugs / limites dans les moteurs CSS des navigateurs qui limitent la hauteur potentielle d'un élément. Pour IE, qui se trouve être 0x123456 ou 1193046 pixels. Pour les autres navigateurs, il est plus élevé.

Il existe une solution de contournement expérimentale dans la branche « largenum-fix » qui soulève cette limite de manière significative la zone en peuplant scrollable avec « pages » mis à 1 M pixels de hauteur, puis en utilisant le positionnement relatif dans ces pages. Étant donné que la limite de la hauteur dans le moteur CSS semble être différent et nettement inférieur à celui du moteur de mise en page réelle, ce qui nous donne une limite supérieure beaucoup plus élevé.

Je cherche toujours un moyen d'arriver à un nombre illimité de lignes sans renoncer à l'avantage de performance que SlickGrid détient actuellement sur d'autres implémentations.

Rudiger, pouvez-vous expliquer comment vous résolu ce problème?

Autres conseils

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

" SlickGrid utilise le rendu virtuel pour vous permettre de travailler facilement avec des centaines de milliers d'articles sans baisse de performance. En fait, il n'y a pas de différence de performance entre le travail avec une grille avec 10 lignes par rapport à une 100' 000 lignes. "

Quelques faits saillants:

  • défilement virtuel adaptatif (gérer des centaines de milliers de lignes)
  • très rapide vitesse de rendu
  • Contexte post-rendu pour les cellules les plus riches
  • Configurable et personnalisable
  • navigation Clavier complet
  • Colonne Resize / Réorganiser / afficher / cacher
  • colonne et redimensionnement automatique-forme la force
  • formatteurs cellulaires Pluggable et éditeurs
  • Support pour l'édition et la création de nouvelles lignes. » par mleibman

Il est libre (licence MIT). Il utilise jQuery.

Les meilleurs Grids à mon avis sont ci-dessous:

Mes 3 meilleures options sont jqGrid, jqxGrid et DataTables. Ils peuvent travailler avec des milliers de lignes et de virtualisation de soutien.

Je ne veux pas commencer une guerre de flamme, mais en supposant que vos chercheurs sont humains, vous ne les connais pas aussi bien que vous le pensez. Tout simplement parce qu'ils Vous pétaoctets de données ne les rend pas capables de voir même des millions d'enregistrements de manière significative. Ils pourraient dire qu'ils veulent pour voir des millions de disques, mais c'est tout simplement ridicule. Demandez à vos plus intelligents chercheurs faire des mathématiques de base: On suppose qu'ils passent 1 seconde visualisation chaque enregistrement. À ce rythme, il faudra 1000000 secondes, ce qui équivaut à plus de six semaines (de semaines de travail de 40 heures, sans interruption pour la nourriture ou les toilettes).

Ont-ils (ou vous) pensent sérieusement une personne (celui regardant la grille) peut rassembler ce genre de concentration? Sont-ils vraiment beaucoup se faire dans ce 1 seconde ou sont-ils (plus probablement) filtrant les choses ne pas veulent? Je soupçonne que après avoir vu un sous-ensemble « taille raisonnable », ils pourraient décrire un filtre pour vous qui filtrera automatiquement les enregistrements.

paxdiablo et Sleeper Smith et Lasse V Karlsen également implicite, vous (et ils) n'ont pas réfléchi aux exigences. Du côté, maintenant que vous avez trouvé SlickGrid, je suis sûr que la nécessité de ces filtres est devenu immédiatement évident.

Je peux dire avec certitude assez bien que vous n'avez pas besoin sérieusement montrer des millions de lignes de données à l'utilisateur.

Il n'y a pas d'utilisateur dans le monde qui sera en mesure de comprendre ou de gérer ce jeu de données même si vous gérez techniquement de le retirer, vous ne résoudra aucun problème connu pour cet utilisateur.

Au lieu de cela, je me concentrerais sur pourquoi l'utilisateur veut voir les données. L'utilisateur ne veut pas voir les données juste pour voir les données, il y a généralement une question posée. Si vous vous concentrez sur répondre à ces questions à la place, vous seriez beaucoup plus proche de quelque chose qui permet de résoudre un problème réel.

Je recommande la Ext JS Grille avec la Buffered Voir fonction.

http://www.extjs.com/deploy/dev/ exemples / grille / buffer.html

dojox.grid.DataGrid offre une abstraction de JS pour les données afin que vous puissiez brancher jusqu'à différents backends avec les magasins dojo.data fournis ou écrire votre propre. Vous aurez évidemment besoin d'un qui prend en charge l'accès aléatoire pour ce nombre de dossiers. DataGrid fournit également l'accessibilité complète.

Modifier ici est donc un lien vers article de Matthew Russell que devrait fournir l'exemple que vous avez besoin, regarder des millions d'enregistrements avec dojox.grid. Notez qu'il utilise l'ancienne version de la grille, mais les concepts sont les mêmes, il n'y avait que quelques améliorations de l'API incompatibles.

Oh, et il est open source totalement gratuit.

(Disclaimer: Je suis l'auteur de w2ui)

Je l'ai récemment écrit un article sur la façon de mettre en œuvre la grille de JavaScript avec 1 million d'enregistrements ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). J'ai découvert que, finalement, il y a 3 restrictions qui empêchent de prendre highter:

  1. Hauteur de la div a une limite (peut être surmontée par le défilement virtuel)
  2. Des opérations telles que le tri et début de recherche étant lent après 1 million d'enregistrements ou donc
  3. RAM est limitée, car les données sont stockées dans le tableau JavaScript

Je l'ai testé la grille avec 1 million d'enregistrements (sauf IE) et il exécute bien. Voir article pour des démonstrations et des exemples.

jQuery Plugin Grille , il était agréable.

Demos

Voici quelques optimisations que vous pouvez vous appliquer à accélérer les choses. Il suffit de penser à voix haute.

Étant donné que le nombre de lignes peut être des millions, vous aurez besoin d'un système de mise en cache juste pour les données JSON du serveur. Je ne peux pas imaginer tous ceux qui veulent télécharger tous les X millions d'articles, mais s'ils le faisaient, ce serait un problème. Cette petit test sur Chrome pour un tableau sur 20M + plantages d'entiers sur ma machine en permanence. 

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

Vous pouvez utiliser ou LRU un autre algorithme de mise en cache et ont lié une partie supérieure sur comment les données que vous êtes prêt à mettre en cache.

Pour les cellules de table elles-mêmes, je pense que la construction / destruction de noeuds DOM peut être coûteux. Au lieu de cela, vous pouvez simplement prédéfinir un nombre X de cellules, et chaque fois que l'utilisateur fait défiler à une nouvelle position, injecter les données JSON dans ces cellules. La barre de défilement ne pratiquement avoir aucun lien direct avec la quantité d'espace (hauteur) est nécessaire pour représenter l'ensemble des données. Vous pouvez fixer arbitrairement la hauteur du conteneur de table, dire 5000px, et que la carte au nombre total de lignes. Par exemple, si la hauteur des conteneurs est 5000px et il y a un total de 10 millions de lignes, puis le starting row ≈ (scroll.top/5000) * 10M où scroll.top représente la distance de défilement de la partie supérieure du récipient. Petite démo .

Pour détecter de demander davantage de données, idéalement un objet doit agir comme un médiateur qui écoute pour faire défiler les événements. Cet objet garde la trace de la vitesse l'utilisateur défile, et quand il semble que l'utilisateur ralentit ou a complètement arrêté, fait une demande de données pour les lignes correspondantes. La récupération des données dans ce mode signifie que vos données va être fragmenté, de sorte que le cache doit être conçu dans cet esprit.

De plus, les limites du navigateur sur les connexions sortantes maximales peuvent jouer un rôle important. Un utilisateur peut faire défiler jusqu'à une certaine position qui déclenche une requête AJAX, mais avant que l'utilisateur termine peut faire défiler à une autre partie. Si le serveur ne suffit pas répondre aux demandes obtiendraient mis en attente et l'application regarderont ne répond pas. Vous pouvez utiliser un gestionnaire de requêtes par lequel toutes les demandes sont acheminées, et il peut annuler les demandes en attente de faire l'espace.

Je sais que c'est une question ancienne mais toujours .. Il y a aussi dhtmlxGrid qui peut gérer des millions de lignes. Il y a une démo avec 50.000 lignes mais le nombre de les lignes qui peuvent être chargés / traitées dans la grille est illimitée.

Disclaimer: Je suis de l'équipe DHTMLX

.

Je vous suggère de lire ce

Disclaimer: i très YUI DataTable sans aucun mal de tête pendant longtemps . Il est puissant et stable. Pour vos besoins, vous pouvez utiliser un ScrollingDataTable Wich Suports

  • x-scrolling
  • y-scrolling
  • xy-scrolling
  • Un puissant mécanisme de l'événement

Pour ce dont vous avez besoin, je pense que vous voulez est un tableScrollEvent . Son API dit

  

Fired lorsqu'un défilement DataTable fixe a un rouleau.

Comme chaque DataTable utilise une source de données, vous pouvez suivre ses données par tableScrollEvent ainsi rendre la taille de la boucle afin de remplir votre ScrollingDataTable en fonction de vos besoins.

Taille de boucle de rendu dit

  

Dans le cas où votre DataTable a besoin pour afficher l'ensemble d'un très grand ensemble de données, la config renderLoopSize peut aider à gérer le rendu DOM du navigateur afin que le thread d'interface utilisateur ne soit pas verrouillé sur les tables très grandes . Toute valeur supérieure à 0, le DOM rendu à exécuter dans les chaînes setTimeout () qui rendent le nombre spécifié de lignes dans chaque boucle. La valeur idéale doit être déterminée par la mise en œuvre car il n'y a pas de règles strictes, que des directives générales:

  • Par renderLoopSize par défaut est 0, donc toutes les lignes sont rendus dans une seule boucle. A renderLoopSize> 0 ajoute dessus de la tête de manière réfléchie.
  • Si votre ensemble de données est assez grand (nombre de lignes X nombre de colonnes X complexité mise en forme) que les utilisateurs connaissent la latence dans le rendu visuel et / ou provoque le script d'accrocher, envisager la création d'un renderLoopSize .
  • Un renderLoopSize moins de 50 ans est sans doute pas la peine. Un renderLoopSize> 100 est sans doute mieux.
  • Un ensemble de données est probablement pas considéré assez grand à moins qu'il ait des centaines et des centaines de lignes.
  • Avoir un renderLoopSize> 0 et

Par exemple 

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

est juste un DataSource. Il peut être un JSON, fonctionJS, XML et même un élément HTML simple

vous pouvez voir un tutoriel simple, fourni par moi. Soyez conscient pas d'autre DATA_TABLE pluglin supporte un clic simple et double en même temps. YUI DataTable vous permet. Et plus, vous pouvez l'utiliser même avec JQuery sans aucun mal de tête

Voici quelques exemples, vous pouvez voir

Ne hésitez pas à poser des questions sur tout ce que vous voulez à propos de YUI DataTable.

Cordialement,

Je ne sorte de voir le point, pour jqGrid vous pouvez utiliser la fonction de défilement virtuel:

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

mais là encore, des millions de lignes avec filtrage peut être fait:

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

Je ne vois vraiment pas le point de « comme s'il n'y a pas de pages » mais, je veux dire ... il n'y a pas moyen d'afficher 1.000.000 lignes à la fois dans le navigateur - c'est de 10 Mo HTML brut, je genre de ne vois pas pourquoi les utilisateurs ne veulent pas voir les pages.

En tout cas ...

meilleure approche que je pourrais penser est en chargeant le bloc de données au format JSON pour chaque rouleau ou une limite avant la fin de défilement. json peut être facilement converti en objets et donc les lignes de la table peut être construit facilement discrètement

Je recommande fortement Ouvrir rico . Il est difficile de mettre en œuvre dans le début, mais une fois que vous prenez, il vous ne serez jamais regarder en arrière.

Je sais que cette question est de quelques années, mais jqGrid prend désormais en charge le défilement virtuel:

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

mais avec désactivé la pagination

Je suggère grille sigma, grille sigma a des fonctionnalités de recherche de personnes imbriquer qui pourraient soutenir des millions de lignes. Et aussi, vous devrez peut-être une pagination à distance pour le faire. voir la démo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details. html

Jetez un oeil à dGrid:

https://dgrid.io/

Je suis d'accord que les utilisateurs ne sera plus jamais besoin de voir des millions de lignes de données à la fois, mais dGrid peut les afficher rapidement (un écran à la fois).

Ne pas faire bouillir l'océan pour faire une tasse de thé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top