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

Je dois présenter un grand nombre de lignes de données (c'est-à-dire 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.

Il devrait plutôt apparaître que toutes les données sont disponibles.

Au lieu de télécharger les données en une seule fois, de petits morceaux sont téléchargés au fur et à mesure que l'utilisateur les rencontre (c'est-à-dire en faisant défiler la grille).

Les lignes ne seront pas modifiées via ce frontal, les grilles en lecture seule sont donc acceptables.

Quelles grilles de données, écrites en JavaScript, existent pour ce type de pagination transparente?

( Avertissement: je suis l'auteur de SlickGrid )

MISE À JOUR Ceci a maintenant été implémenté dans SlickGrid .

Veuillez consulter http://github.com/mleibman/SlickGrid/issues#issue/22 pour une discussion en cours sur le fonctionnement de SlickGrid avec un plus grand nombre de lignes.

Le problème est que SlickGrid ne virtualise pas la barre de défilement elle-même - la hauteur de la zone de défilement est définie sur la hauteur totale de toutes les lignes. Les lignes sont toujours ajoutées et supprimées lorsque l'utilisateur fait défiler, mais le défilement lui-même est effectué par le navigateur. Cela lui permet d'être très rapide mais fluide (les événements de défilement sont notoirement lents). La mise en garde est qu'il existe des bogues / limites dans les moteurs CSS des navigateurs qui limitent la hauteur potentielle d'un élément. Pour IE, cela 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 augmente cette limite de manière significative en remplissant la zone de défilement avec des «pages» définies à une hauteur de 1 M pixels, puis en utilisant un positionnement relatif dans ces pages. Étant donné que la limite de hauteur dans le moteur CSS semble être différente et nettement inférieure à celle du moteur de disposition réel, cela nous donne une limite supérieure beaucoup plus élevée.

Je cherche toujours un moyen d'accéder à un nombre illimité de lignes sans renoncer à l'avantage de performance que SlickGrid détient actuellement par rapport aux autres implémentations.

Rudiger, pouvez-vous expliquer comment vous avez résolu cela?

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

" SlickGrid utilise le rendu virtuel pour vous permettre de travailler facilement avec des centaines de milliers d'éléments sans aucune baisse de performances. En fait, il n'y a pas de différence de performances entre travailler avec une grille de 10 lignes et 100'000 lignes. "

Quelques faits saillants:

• Défilement virtuel adaptatif (gérer des centaines de milliers de lignes)
• Vitesse de rendu extrêmement rapide
• Post-rendu en arrière-plan pour les cellules plus riches
• Configurable et personnalisable
• Navigation clavier complète
• Redimensionner / réorganiser / afficher / masquer la colonne
• Dimensionnement automatique et ajustement forcé de la colonne
• Formateurs et éditeurs de cellules enfichables
• Prise en charge de l'édition et de la création de nouvelles lignes. "par mleibman

C'est gratuit (licence MIT). Il utilise jQuery.

Les meilleures grilles à mon avis sont ci-dessous:

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

Mes 3 meilleures options sont jqGrid, jqxGrid et DataTables. Ils peuvent fonctionner avec des milliers de lignes et prendre en charge la virtualisation.

Je ne veux pas déclencher une guerre des flammes, mais en supposant que vos chercheurs sont humains, vous ne les connaissez pas aussi bien que vous le pensez. Ce n'est pas parce qu'ils ont des pétaoctets de données qu'ils sont capables de visualiser même des millions d'enregistrements de manière significative. Ils pourraient dire qu'ils veulent voir des millions de disques, mais c'est tout simplement stupide. Demandez à vos chercheurs les plus intelligents de faire quelques calculs de base: Supposons qu'ils passent 1 seconde à regarder chaque enregistrement. À ce rythme, cela prendra 1000000 secondes, ce qui correspond à plus de six semaines (de 40 heures de travail sans interruption pour la nourriture ou les toilettes).

Pensent-ils (ou vous) sérieusement qu'une seule personne (celle qui regarde la grille) peut rassembler ce genre de concentration? Sont-ils vraiment en train de faire beaucoup de choses au cours de cette seconde, ou filtrent-ils (plus probablement) les trucs qu'ils ne font pas veulent ? Je soupçonne qu'après avoir visionné un sous-ensemble "de taille raisonnable", ils pourraient vous décrire un filtre qui filtrerait automatiquement ces enregistrements.

Comme paxdiablo et Sleeper Smith et Lasse V Karlsen l'ont également laissé entendre, vous (et eux) n'avez pas réfléchi aux exigences. Du côté positif, maintenant que vous avez trouvé SlickGrid, je suis sûr que le besoin de ces filtres est devenu immédiatement évident.

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

Aucun utilisateur au monde ne pourra comprendre ou gérer cet ensemble de données, donc même si vous réussissez techniquement à le retirer, vous ne résoudrez aucun problème connu pour cet utilisateur.

Au lieu de cela, je me concentrerais sur la raison pour laquelle l'utilisateur souhaite 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 plutôt sur la réponse à ces questions, vous serez alors beaucoup plus proche de quelque chose qui résout un problème réel.

Je recommande l'Ext JS Grid avec la fonction Buffered View.

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

(Avertissement: je suis l'auteur de w2ui)

J'ai récemment écrit un article sur la façon d'implémenter une grille JavaScript avec 1 million d'enregistrements ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). J'ai découvert qu'en fin de compte il y a 3 restrictions qui empêchent de le prendre plus haut:

1. La hauteur du div a une limite (peut être surmontée par un défilement virtuel)
2. Les opérations telles que le tri et la recherche commencent à être lentes après environ un million d'enregistrements
3. La RAM est limitée car les données sont stockées dans un tableau JavaScript

J'ai testé la grille avec 1 million d'enregistrements (sauf IE) et elle fonctionne bien. Voir l'article pour des démos et des exemples.

dojox.grid.DataGrid propose une abstraction JS pour les données afin que vous puissiez les connecter à divers backends avec les magasins dojo.data fournis ou écrire les vôtres. Vous en aurez évidemment besoin d'un qui prend en charge l'accès aléatoire pour ces nombreux enregistrements. DataGrid fournit également une accessibilité complète.

Modifiez donc voici un lien vers l'article de Matthew Russell qui devrait fournir l'exemple dont vous avez besoin, en affichant 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 y avait juste quelques améliorations d'API incompatibles.

Oh, et c'est open source totalement gratuit.

J'ai utilisé le plugin jQuery Grid , c'était sympa.

Démos

Voici quelques optimisations que vous pouvez appliquer pour accélérer les choses. Je pense juste à haute voix.

Étant donné que le nombre de lignes peut être de plusieurs millions, vous souhaiterez un système de mise en cache uniquement pour les données JSON du serveur. Je ne peux pas imaginer que quelqu'un veuille télécharger tous les X millions d'articles, mais s'ils le faisaient, ce serait un problème. Ce petit test sur Chrome pour un tableau sur 20M + entiers plante en permanence sur ma machine.

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

Vous pouvez utiliser LRU ou un autre algorithme de mise en cache et avoir une limite supérieure sur la quantité de données que vous êtes prêt à mettre en cache.

Pour les cellules du tableau elles-mêmes, je pense que la construction / destruction de nœuds DOM peut être coûteuse. Au lieu de cela, vous pouvez simplement prédéfinir le nombre X de cellules, et chaque fois que l'utilisateur fait défiler vers une nouvelle position, injectez les données JSON dans ces cellules. La barre de défilement n'aurait pratiquement aucune relation directe avec l'espace (hauteur) requis pour représenter l'ensemble de données entier. Vous pouvez définir arbitrairement la hauteur du conteneur de table, disons 5000 px, et la mapper au nombre total de lignes. Par exemple, si la hauteur des conteneurs est de 5000 pixels et qu'il y a un total de 10 millions de lignes, alors starting row ≈ (scroll.top/5000) * 10Moù scroll.topreprésente la distance de défilement à partir du haut du conteneur. Petite démo ici .

Pour détecter quand demander plus de données, idéalement, un objet doit agir comme un médiateur qui écoute les événements de défilement. Cet objet garde une trace de la vitesse de défilement de l'utilisateur, et lorsqu'il semble que l'utilisateur ralentit ou s'est complètement arrêté, effectue une demande de données pour les lignes correspondantes. La récupération de données de cette manière signifie que vos données vont être fragmentées, donc le cache doit être conçu dans cet esprit.

Les limites du navigateur sur le nombre maximal de connexions sortantes peuvent également jouer un rôle important. Un utilisateur peut faire défiler jusqu'à une certaine position qui déclenchera une demande AJAX, mais avant cela, l'utilisateur peut faire défiler jusqu'à une autre partie. Si le serveur ne répond pas suffisamment, les demandes seront mises en file d'attente et l'application ne répondra pas. Vous pouvez utiliser un gestionnaire de demandes par lequel toutes les demandes sont acheminées et il peut annuler les demandes en attente pour libérer de l'espace.

Je sais que c'est une vieille question mais quand même. 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 lignes qui peuvent être chargées / traitées dans la grille est illimité.

Avertissement: je suis de l'équipe DHTMLX.

Je vous suggère de lire ceci

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

Avertissement: j'utilise fortement YUI DataTable sans aucun mal de tête pendant une longue période . Il est puissant et stable. Pour vos besoins, vous pouvez utiliser un ScrollingDataTable qui prend en charge

• défilement x
• défilement y
• défilement xy
• Un puissant mécanisme d'événement

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

Déclenché lorsqu'un DataTable à défilement fixe a un défilement.

Comme chaque DataTable utilise un DataSource, vous pouvez surveiller ses données via tableScrollEvent avec la taille de la boucle de rendu afin de remplir votre ScrollingDataTable selon vos besoins.

La taille de la boucle de rendu indique

Dans les cas où votre DataTable doit afficher l'intégralité d'un très grand ensemble de données, la configuration renderLoopSize peut aider à gérer le rendu DOM du navigateur afin que le thread d'interface utilisateur ne soit pas verrouillé sur de très grandes tables . Toute valeur supérieure à 0 entraînera l'exécution du rendu DOM 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 implémentation car il n'y a pas de règles strictes et rapides, seulement des directives générales:

• Par défaut, renderLoopSize est 0, donc toutes les lignes sont rendues dans une seule boucle. Un renderLoopSize> 0 ajoute des frais généraux, donc utilisez-le soigneusement.
• Si votre ensemble de données est suffisamment volumineux (nombre de lignes X nombre de colonnes X complexité de formatage) que les utilisateurs subissent une latence dans le rendu visuel et / ou si le script se bloque , envisagez de définir un renderLoopSize .
• Un renderLoopSize de moins de 50 ans n'en vaut probablement pas la peine. Un renderLoopSize> 100 est probablement mieux.
• Un ensemble de données n'est probablement pas considéré comme suffisamment volumineux à moins qu'il ne comporte des centaines et des centaines de lignes.
• Le fait d'avoir un renderLoopSize> 0 et <total des lignes entraîne le rendu de la table dans une boucle (identique à renderLoopSize = 0) mais il déclenche également des fonctionnalités telles que l'entrelacement des lignes après le rendu à gérer à partir d'un thread setTimeout distinct.

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

<WHERE_DOES_THE_DATA_COME_FROM> n'est qu'une seule DataSource . Il peut s'agir d'un élément JSON, JSFunction, XML et même d'un seul élément HTML

Ici vous pouvez voir un tutoriel simple, fourni par moi. Sachez qu'aucun autre pluglin DATA_TABLE ne prend en charge les clics simple et double en même temps. YUI DataTable vous le permet. Et en plus, vous pouvez l'utiliser même avec JQuery sans aucun mal de tête

Quelques exemples, vous pouvez voir

• Élément de liste

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

Cordialement,

Je ne parviens pas à voir le point, pour jqGrid, vous pouvez utiliser la fonctionnalité de défilement virtuel:

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

mais là encore, des millions de lignes avec filtrage peuvent être effectuées:

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

Je ne vois vraiment pas l'intérêt de "comme s'il n'y avait pas de pages", je veux dire ... il n'y a aucun moyen d'afficher 1 000 000 de lignes à la fois dans le navigateur - c'est 10 Mo de HTML brut, je ne parviens pas à voir pourquoi les utilisateurs ne voudraient pas voir les pages.

En tous cas...

la meilleure approche à laquelle je pourrais penser est de charger le bloc de données au format json pour chaque défilement ou une limite avant la fin du défilement. json peut être facilement converti en objets et, par conséquent, les lignes de table peuvent être construites facilement et discrètement

Je recommanderais vivement Open rico . Il est difficile à mettre en œuvre au début, mais une fois que vous l'aurez saisi, vous ne regarderez jamais en arrière.

Je sais que cette question remonte à 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 pagination désactivée

Je suggère la grille sigma, la grille sigma a intégré des fonctionnalités de pagination qui pourraient prendre en charge des millions de lignes. Et aussi, vous aurez peut-être besoin d'une pagination à distance pour le faire. voir la démo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Jetez un œil à dGrid:

https://dgrid.io/

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

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