Siatka danych JavaScript dla milionów wierszy [zamknięte]

Muszę przedstawić dużą liczbę wierszy danych (tj. Miliony wierszy) użytkownikowi w siatce za pomocą JavaScript.

Użytkownik nie powinien widzieć stron ani przeglądać tylko skończonych ilości danych naraz.

Powinno się raczej wydawać, że wszystkie dane są dostępne.

Zamiast pobierać dane naraz, pobierane są małe fragmenty, gdy użytkownik do nich podchodzi (np. Przewijając siatkę).

Wiersze nie będą edytowane przez ten interfejs, więc siatki tylko do odczytu są dopuszczalne.

Jakie siatki danych napisane w JavaScript istnieją dla tego rodzaju bezproblemowego stronicowania?

( Uwaga: Jestem autorem SlickGrid )

AKTUALIZACJA To zostało zaimplementowane w SlickGrid .

Zapoznaj się z http://github.com/mleibman/SlickGrid/issues#issue/22, aby uzyskać ciągłą dyskusję na temat usprawnienia pracy SlickGrid z większą liczbą wierszy.

Problem polega na tym, że SlickGrid nie wirtualizuje samego paska przewijania - wysokość obszaru przewijanego jest ustawiona na całkowitą wysokość wszystkich wierszy. Wiersze są nadal dodawane i usuwane, gdy użytkownik przewija, ale samo przewijanie jest wykonywane przez przeglądarkę. Dzięki temu może być bardzo szybki, ale płynny (zdarzenia onscroll są notorycznie wolne). Zastrzeżenie polega na tym, że w silnikach CSS przeglądarki występują błędy / ograniczenia, które ograniczają potencjalną wysokość elementu. W przypadku IE jest to 0x123456 lub 1193046 pikseli. W przypadku innych przeglądarek jest on wyższy.

W gałęzi „largenum-fix” występuje eksperymentalne obejście, które znacznie podnosi ten limit, wypełniając obszar przewijalny „stronami” ustawionymi na wysokość 1M pikseli, a następnie stosując względne pozycjonowanie na tych stronach. Ponieważ limit wysokości w silniku CSS wydaje się inny i znacznie niższy niż w silniku rzeczywistego układu, daje nam to znacznie wyższy górny limit.

Wciąż szukam sposobu na uzyskanie nieograniczonej liczby wierszy bez rezygnacji z przewagi wydajności, jaką SlickGrid obecnie ma nad innymi implementacjami.

Rudiger, czy możesz wyjaśnić, w jaki sposób to rozwiązałeś?

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

„ SlickGrid wykorzystuje wirtualny rendering, aby umożliwić ci łatwą pracę z setkami tysięcy elementów bez spadku wydajności. W rzeczywistości nie ma różnicy w wydajności pomiędzy pracą z siatką z 10 rzędami w porównaniu do 100'000 wierszy ”.

Niektóre najważniejsze:

• Adaptacyjne wirtualne przewijanie (obsługuje setki tysięcy wierszy)
• Niezwykle duża prędkość renderowania
• Tło po renderowaniu dla bogatszych komórek
• Konfigurowalny i konfigurowalny
• Pełna nawigacja za pomocą klawiatury
• Zmień rozmiar kolumny / zmień kolejność / pokaż / ukryj
• Automatyczne dopasowywanie kolumn i dopasowanie siłą
• Wtykowe formatery i edytory komórek
• Obsługa edycji i tworzenia nowych wierszy. „przez mleibman

To nic nie kosztuje (licencja MIT). Korzysta z jQuery.

Najlepsze siatki według mnie są poniżej:

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

Moje najlepsze 3 opcje to jqGrid, jqxGrid i DataTables. Mogą pracować z tysiącami wierszy i obsługiwać wirtualizację.

Nie chcę rozpętać wojny z płomieniem, ale zakładając, że twoi badacze są ludźmi, nie znasz ich tak dobrze, jak myślisz. Tylko dlatego, że mają petabajty danych, nie są w stanie wyświetlić nawet milionów rekordów w jakikolwiek znaczący sposób. Mogą powiedzieć, że chcą zobaczyć miliony płyt, ale to po prostu głupie. Poproś najmądrzejszych badaczy o wykonanie podstawowej matematyki: Załóż, że spędzają 1 sekundę na oglądaniu każdego rekordu. Przy takim tempie zajmie to 1000000 sekund, co wydłuży się do ponad sześciu tygodni (40 godzin tygodni pracy bez przerw na jedzenie lub toaletę).

Czy oni (lub ty) poważnie sądzicie, że jedna osoba (ta, która patrzy na siatkę) może zmobilizować tego rodzaju koncentrację? Czy naprawdę robią dużo w ciągu 1 sekundy, czy też (bardziej prawdopodobne) odfiltrowują rzeczy, których nie chcą? Podejrzewam, że po obejrzeniu podzbioru „rozsądnej wielkości” mogą opisać filtr, który automatycznie odfiltruje te rekordy.

Jak sugerowali również paxdiablo, Sleeper Smith i Lasse V Karlsen, ty (i oni) nie przemyślałeś wymagań. Z drugiej strony, odkąd znalazłeś SlickGrid, jestem pewien, że potrzeba tych filtrów stała się natychmiast oczywista.

Mogę powiedzieć z całkiem dobrą pewnością, że naprawdę nie musisz pokazywać użytkownikowi milionów wierszy danych.

Nie ma na świecie użytkownika, który byłby w stanie zrozumieć ten zestaw danych lub nim zarządzać, więc nawet jeśli uda ci się go technicznie usunąć, nie rozwiążesz żadnego znanego problemu dla tego użytkownika.

Zamiast tego skupiłbym się na tym, dlaczego użytkownik chce zobaczyć dane. Użytkownik nie chce widzieć danych tylko po to, aby zobaczyć dane, zwykle zadawane jest pytanie. Jeśli zamiast tego skoncentrujesz się na udzieleniu odpowiedzi na te pytania, będziesz znacznie bliżej rozwiązania rzeczywistego problemu.

Polecam Ext JS Grid z funkcją Buffered View.

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

(Uwaga: Jestem autorem w2ui)

Niedawno napisałem artykuł o implementacji siatki JavaScript z 1 milionem rekordów ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Odkryłem, że ostatecznie istnieją 3 ograniczenia, które uniemożliwiają podniesienie go:

1. Wysokość div ma limit (można pokonać przez wirtualne przewijanie)
2. Operacje takie jak sortowanie i wyszukiwanie zaczynają być powolne po około 1 milionie rekordów
3. Pamięć RAM jest ograniczona, ponieważ dane są przechowywane w tablicy JavaScript

Testowałem siatkę z 1 milionem rekordów (oprócz IE) i działa ona dobrze. Zobacz artykuł na dema i przykłady.

dojox.grid.DataGrid oferuje abstrakcję JS dla danych, dzięki czemu można podłączyć ją do różnych backendów za pomocą udostępnionych sklepów dojo.data lub napisać własny. Będziesz oczywiście potrzebował takiego, który obsługuje losowy dostęp do tak wielu rekordów. DataGrid zapewnia również pełną dostępność.

Edytuj, więc oto link do artykułu Matthew Russella który powinien zapewnić potrzebny przykład, przeglądając miliony rekordów za pomocą dojox.grid. Zauważ, że używa starej wersji siatki, ale koncepcje są takie same, wprowadzono tylko kilka niekompatybilnych ulepszeń API.

Aha, i to całkowicie darmowe oprogramowanie typu open source.

użyłem wtyczki jQuery Grid , było miło.

Dema

Oto kilka optymalizacji, które możesz zastosować, aby przyspieszyć działanie. Po prostu myślę głośno.

Ponieważ liczba wierszy może być w milionach, potrzebny będzie system buforowania tylko dla danych JSON z serwera. Nie wyobrażam sobie, że ktoś chciałby pobrać wszystkie X milionów elementów, ale gdyby to zrobił, byłby to problem. Ten mały test w Chrome dla tablicy na liczbach całkowitych 20 M + stale się zawiesza na moim komputerze.

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

Możesz użyć LRU lub innego algorytmu buforowania i mieć górną granicę ilości danych, które chcesz buforować.

Myślę, że w przypadku samych komórek tabeli budowanie / niszczenie węzłów DOM może być kosztowne. Zamiast tego możesz po prostu wstępnie zdefiniować liczbę komórek X i za każdym razem, gdy użytkownik przewinie do nowej pozycji, wstrzyknij dane JSON do tych komórek. Pasek przewijania nie miałby praktycznie żadnego bezpośredniego związku z ilością miejsca (wysokości) wymaganego do przedstawienia całego zestawu danych. Możesz dowolnie ustawić wysokość kontenera tabeli, powiedzmy 5000px, i odwzorować ją na całkowitą liczbę wierszy. Na przykład, jeśli wysokość kontenerów wynosi 5000 pikseli, a w sumie jest 10 mln wierszy, to starting row ≈ (scroll.top/5000) * 10Mgdzie scroll.topoznacza odległość przewijania od góry kontenera. Małe demo tutaj .

Aby wykryć, kiedy zażądać więcej danych, najlepiej obiekt powinien działać jako mediator, który nasłuchuje przewijanych zdarzeń. Ten obiekt śledzi szybkość przewijania przez użytkownika, a gdy wygląda na to, że użytkownik zwalnia lub całkowicie się zatrzymał, wysyła żądanie danych dla odpowiednich wierszy. Odzyskiwanie danych w ten sposób oznacza, że ​​dane zostaną pofragmentowane, dlatego pamięć podręczna powinna być zaprojektowana z myślą o tym.

Ważną rolę mogą również odgrywać ograniczenia przeglądarki dotyczące maksymalnej liczby połączeń wychodzących. Użytkownik może przewinąć do określonej pozycji, która uruchomi żądanie AJAX, ale zanim to się skończy, użytkownik może przewinąć do innej części. Jeśli serwer nie reaguje wystarczająco, żądania zostaną umieszczone w kolejce, a aplikacja nie będzie odpowiadać. Możesz użyć menedżera żądań, przez który wszystkie żądania są kierowane, i może anulować oczekujące żądania, aby zwolnić miejsce.

Wiem, że to stare pytanie, ale wciąż… Istnieje również dhtmlxGrid, który może obsłużyć miliony wierszy. Istnieje demo z 50 000 wierszy, ale liczba wierszy, które można załadować / przetworzyć w siatce, jest nieograniczona.

Oświadczenie: Jestem z zespołu DHTMLX.

Sugeruję przeczytanie tego

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

Oświadczenie: intensywnie używam YUI DataTable przez długi czas bez bólu głowy . Jest mocny i stabilny. Do swoich potrzeb możesz użyć ScrollingDataTable, który obsługuje

• przewijanie x
• przewijanie y
• przewijanie xy
• Potężny mechanizm zdarzeń

Myślę, że tym, czego potrzebujesz, jest tableScrollEvent . Jego interfejs API mówi

Uruchamiany, gdy ustalony przewijany DataTable ma przewijany.

Ponieważ każdy DataTable korzysta z DataSource, możesz monitorować jego dane poprzez tableScrollEvent wraz z wielkością pętli renderowania , aby wypełnić ScrollingDataTable zgodnie z Twoimi potrzebami.

Rozmiar pętli renderowania mówi

W przypadkach, gdy DataTable musi wyświetlać całość bardzo dużego zestawu danych, konfiguracja renderLoopSize może pomóc w zarządzaniu renderowaniem DOM przeglądarki, dzięki czemu wątek interfejsu użytkownika nie zostanie zablokowany na bardzo dużych tabelach . Każda wartość większa od 0 spowoduje, że renderowanie DOM zostanie wykonane w łańcuchach setTimeout (), które wyświetlają określoną liczbę wierszy w każdej pętli. Idealną wartość należy ustalić na wdrożenie, ponieważ nie ma twardych i szybkich reguł, a jedynie ogólne wytyczne:

• Domyślnie renderLoopSize ma wartość 0, więc wszystkie wiersze są renderowane w jednej pętli. RenderujLoopSize> 0 dodaje narzut, więc używaj z rozwagą.
• Jeśli zestaw danych jest wystarczająco duży (liczba wierszy X liczba złożoności formatowania Kolumny X), że użytkownicy doświadczają opóźnień w renderowaniu wizualnym i / lub powoduje zawieszenie się skryptu, rozważ ustawienie renderLoopSize .
• RenderLoopSize poniżej 50 prawdopodobnie nie jest tego wart. RenderLoopSize> 100 jest prawdopodobnie lepszy.
• Zestaw danych prawdopodobnie nie jest uważany za wystarczająco duży, chyba że ma setki wierszy.
• Posiadanie renderLoopSize> 0 i <suma wierszy powoduje, że tabela jest renderowana w jednej pętli (tak samo jak renderLoopSize = 0), ale także uruchamia funkcje, takie jak paski renderowania wiersza po renderowaniu z osobnego wątku setTimeout.

Na przykład

// 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> to tylko jedno źródło danych . Może to być JSON, JSFunction, XML, a nawet pojedynczy element HTML

Tutaj możesz zobaczyć Prosty samouczek, dostarczony przeze mnie. Pamiętaj, że żadna inna wtyczka DATA_TABLE nie obsługuje pojedynczego i podwójnego kliknięcia jednocześnie. YUI DataTable pozwala. Co więcej, możesz go używać nawet z JQuery bez bólu głowy

Niektóre przykłady, możesz zobaczyć

• Element listy

Nie wahaj się pytać o wszystko, co chcesz o YUI DataTable.

pozdrowienia,

W pewnym sensie nie widzę sensu, w przypadku jqGrid możesz użyć funkcji wirtualnego przewijania:

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

ale z drugiej strony można wykonać miliony wierszy z filtrowaniem:

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

Naprawdę nie rozumiem sensu „tak jakby nie było stron”, to znaczy… nie ma sposobu na wyświetlenie 1 000 000 wierszy w przeglądarce - to jest 10 MB surowego kodu HTML, w pewnym sensie nie widzę dlaczego użytkownicy nie chcą widzieć stron.

Tak czy siak...

najlepszym podejściem, jakie mogłem wymyślić, jest ładowanie fragmentu danych w formacie json dla każdego przewijania lub pewnego limitu przed zakończeniem przewijania. json można łatwo przekonwertować na obiekty, dzięki czemu wiersze tabeli można łatwo i dyskretnie konstruować

Gorąco polecam Open rico . Na początku trudno go wdrożyć, ale kiedy go złapiesz, nigdy nie będziesz oglądać się za siebie.

Wiem, że to pytanie ma kilka lat, ale jqgrid obsługuje teraz wirtualne przewijanie:

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

ale z wyłączoną paginacją

Sugeruję sigma grid, sigma grid ma wbudowane funkcje stronicowania, które mogłyby obsługiwać miliony wierszy. Aby to zrobić, możesz potrzebować zdalnego stronicowania. zobacz wersję demonstracyjną http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Spójrz na dGrid:

https://dgrid.io/

Zgadzam się, że użytkownicy NIGDY, KIEDYKOLWIEK nie będą musieli przeglądać milionów wierszy danych naraz, ale dGrid może je wyświetlić szybko (ekranowo za jednym razem).

Nie gotuj oceanu, aby zrobić filiżankę herbaty.