수백만 행에 대한 JavaScript 데이터 그리드 [닫기]

JavaScript를 사용하여 그리드에 사용자에게 많은 수의 데이터 행 (예 : 수백만 행)을 제시해야합니다.

사용자는 한 번에 페이지를 보거나 유한 한 양의 데이터 만 보지 않아야합니다.

오히려 모든 데이터를 사용할 수있는 것으로 보입니다.

데이터를 한 번에 모두 다운로드하는 대신 작은 청크는 사용자가 올 때 (즉, 그리드를 스크롤하여) 다운로드됩니다.

이 프런트 엔드를 통해 행을 편집 할 수 없으므로 읽기 전용 그리드를 사용할 수 있습니다.

이러한 원활한 페이징을 위해 JavaScript로 작성된 데이터 그리드는 무엇입니까?

( 면책 조항 : 저는 SlickGrid의 저자입니다 )

업데이트 이제 SlickGrid 에서 구현되었습니다 .

SlickGrid가 더 많은 행에서 작동하도록하는 방법에 대한 지속적인 논의는 http://github.com/mleibman/SlickGrid/issues#issue/22 를 참조하십시오 .

문제는 SlickGrid가 스크롤 막대 자체를 가상화하지 않는다는 것입니다. 스크롤 가능 영역의 높이는 모든 행의 총 높이로 설정됩니다. 사용자가 스크롤 할 때 행이 계속 추가되고 제거되지만 스크롤 자체는 브라우저에서 수행됩니다. 그것은 매우 빠르지 만 매끄 럽습니다 (onsroll 이벤트는 악명 높음). 주의 사항은 브라우저의 CSS 엔진에 요소의 잠재적 높이를 제한하는 버그 / 제한이 있다는 것입니다. IE의 경우 0x123456 또는 1193046 픽셀입니다. 다른 브라우저의 경우 더 높습니다.

"largenum-fix"브랜치에는 "페이지"를 1M 픽셀 높이로 설정 한 상태에서 스크롤 가능 영역을 채우고 해당 페이지 내에서 상대 위치를 사용하여 한계를 크게 높이는 실험적인 해결 방법이 있습니다. CSS 엔진의 높이 제한은 실제 레이아웃 엔진과는 다르고 상당히 낮은 것으로 보이므로 상한이 훨씬 더 높습니다.

SlickGrid가 현재 다른 구현보다 우수한 성능을 포기하지 않으면 서 행을 무제한으로 늘릴 수있는 방법을 찾고 있습니다.

Rudiger,이 문제를 어떻게 해결했는지 자세히 설명해 주시겠습니까?

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

" SlickGrid는 가상 렌더링을 사용하여 성능 저하없이 수십만 개의 항목으로 쉽게 작업 할 수 있습니다. 실제로 10 행이있는 그리드 작업과 100'000 행의 작업 사이에는 성능 차이가 없습니다. "

일부 주요 특징 :

• 적응 형 가상 스크롤 (수십만 행 처리)
• 매우 빠른 렌더링 속도
• 더 풍부한 셀을위한 백그라운드 포스트 렌더링
• 구성 및 사용자 정의 가능
• 전체 키보드 탐색
• 열 크기 조정 / 재주문 / 표시 / 숨기기
• 컬럼 자동 크기 조정 및 강제 맞춤
• 플러그 형 셀 포맷터 및 편집기
• 새 행 편집 및 작성을 지원합니다. "by mleibman

무료입니다 (MIT 라이센스). jQuery를 사용합니다.

내 의견으로는 최고의 그리드는 다음과 같습니다.

• Flexigrid : http://flexigrid.info/
• jQuery 그리드 : http://www.trirand.com/blog/
• jqGridView : http://plugins.jquery.com/project/jqGridView
• jqxGrid : http://www.jqwidgets.com/
• 잉그리드 : 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

가장 좋은 3 가지 옵션은 jqGrid, jqxGrid 및 DataTables입니다. 수천 개의 행으로 작업하고 가상화를 지원할 수 있습니다.

나는 화염 전쟁을 시작한다는 의미는 아니지만, 연구자들이 인간이라고 가정하면, 당신은 그들이 생각하는 것만 큼 잘 모른다. 그들은 그냥 있기 때문에 이 페타 바이트의 데이터를 의미있는 방식으로 기록의 수백만을 보는 그들이 할 수하지 않습니다. 그들은 수백만 개의 레코드를보고 싶다고 말할 수도 있지만 그것은 어리석은 일입니다. 가장 현명한 연구원이 기본적인 수학을하도록하십시오. 각 기록을 1 초씩 보는 것으로 가정하십시오. 이 속도에서 1000000 초가 걸리고 6 주 이상 (음식 또는 화장실에 휴식을 취하지 않는 주당 40 시간의 노동 시간)까지 진행됩니다.

그들이 (또는 당신) 진심으로 한 사람 (그리드를보고있는 사람)이 그런 종류의 집중력을 발휘할 수 있다고 생각합니까? 그들은 실제로 1 초 안에 많은 일을 하고 있습니까, 아니면 원하지 않는 것들을 걸러 낼 가능성 이 있습니까? "합리적인 크기의"하위 집합을 본 후 해당 레코드를 자동으로 필터링하는 필터를 설명 할 수 있다고 생각합니다.

paxdiablo와 Sleeper Smith 및 Lasse V Karlsen도 암시했듯이 귀하 (및 그들)는 요구 사항을 고려하지 않았습니다. 위쪽에서 SlickGrid를 찾았으므로 해당 필터의 필요성이 즉시 명백해졌습니다.

나는 당신에게 심각하게 사용자에게 수백만 행의 데이터를 보여줄 필요가 없다고 확실히 말할 수 있습니다.

전 세계에 해당 데이터 세트를 이해하거나 관리 할 수있는 사용자가 없으므로 기술적으로 데이터를 가져 오더라도 해당 사용자에 대해 알려진 문제는 해결되지 않습니다.

대신 사용자가 왜 데이터를보고 싶어 하는지에 초점을 맞출 것 입니다. 사용자는 단지 데이터를보기 위해 데이터를보고 싶지 않으며, 일반적으로 질문이 있습니다. 그 질문에 대답하는 데 집중한다면 실제 문제를 해결하는 것에 훨씬 더 가까워 질 것입니다.

버퍼링 뷰 기능이있는 Ext JS Grid를 권장합니다.

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

(면책 조항 : 나는 w2ui의 저자입니다)

최근에 100 만 개의 레코드를 가진 JavaScript 그리드를 구현하는 방법에 대한 기사를 작성했습니다 ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). 나는 궁극적으로 그것을 더 높이 가져 가지 못하게하는 3 가지 제한 사항이 있음을 발견했습니다.

1. div의 높이에는 한계가 있습니다 (가상 스크롤로 극복 가능)
2. 1 백만 레코드 정도 후에 정렬 및 검색과 같은 작업이 느리게 시작됩니다.
3. 데이터가 JavaScript 배열에 저장되므로 RAM이 제한됩니다

IE를 제외하고 1 백만 개의 레코드로 그리드를 테스트했으며 제대로 수행합니다. 데모 및 예제는 기사를 참조하십시오.

dojox.grid.DataGrid 는 데이터에 대한 JS 추상화를 제공하므로 제공된 dojo.data 저장소를 사용하여 다양한 백엔드에 연결하거나 직접 작성할 수 있습니다. 이 많은 레코드에 대해 임의 액세스를 지원하는 것이 분명히 필요합니다. DataGrid는 완벽한 접근성을 제공합니다.

여기 에 dojox.grid를 사용하여 수백만 건의 레코드를보고 필요한 예제를 제공해야하는 Matthew Russell의 기사 링크가 있습니다. 이전 버전의 그리드를 사용하지만 개념은 동일하지만 호환되지 않는 API 개선 사항이 있습니다.

아, 그리고 그것은 완전 무료 오픈 소스입니다.

jQuery Grid Plugin을 사용 했는데 좋았습니다.

시민

다음은 적용 속도를 높일 수있는 몇 가지 최적화입니다. 그냥 큰소리로 생각해

행 수는 수백만 개에이를 수 있으므로 서버의 JSON 데이터에 대해서만 캐싱 시스템을 원할 것입니다. X 백만 항목을 모두 다운로드하려고하는 사람은 상상할 수 없지만, 그렇게한다면 문제가됩니다. 20M + 정수 배열에 대한 Chrome 의이 작은 테스트 는 내 컴퓨터에서 지속적으로 충돌합니다.

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

당신이 사용할 수있는 LRU 또는 다른 캐싱 알고리즘을하고는 상단이 캐시하고자하는 금액 데이터 바인딩이있다.

테이블 셀 자체의 경우 DOM 노드를 생성 / 파기하는 것이 비용이 많이들 수 있다고 생각합니다. 대신 X 개의 셀 수를 미리 정의 할 수 있으며 사용자가 새로운 위치로 스크롤 할 때마다 JSON 데이터를이 셀에 주입 할 수 있습니다. 스크롤바는 사실상 전체 데이터 세트를 나타내는 데 필요한 공간 (높이)의 양과 직접적인 관계가 없습니다. 테이블 컨테이너의 높이 (예 : 5000px)를 임의로 설정하고 총 행 수에 매핑 할 수 있습니다. 예를 들어, 컨테이너 높이가 5000px이고 총 10M 개의 행이 starting row ≈ (scroll.top/5000) * 10M있는 경우 where scroll.top는 컨테이너 상단에서 스크롤 거리를 나타냅니다. 여기에 작은 데모가 있습니다 .

더 많은 데이터를 요청하는시기를 감지하려면 개체가 스크롤 이벤트를 수신하는 중개자 역할을하는 것이 이상적입니다. 이 객체는 사용자가 스크롤하는 속도를 추적하고 사용자가 느려지거나 완전히 중지 된 것처럼 보이면 해당 행에 대한 데이터 요청을합니다. 이러한 방식으로 데이터를 검색하면 데이터가 조각화되므로 캐시를 염두에두고 설계해야합니다.

또한 최대 발신 연결에 대한 브라우저 제한이 중요한 역할을 할 수 있습니다. 사용자는 AJAX 요청을 발생시키는 특정 위치로 스크롤 할 수 있지만, 그 전에 사용자는 다른 부분으로 스크롤 할 수 있습니다. 서버가 충분히 응답하지 않으면 요청이 대기되고 응용 프로그램이 응답하지 않는 것처럼 보입니다. 모든 요청이 라우트되는 요청 관리자를 사용할 수 있으며 보류중인 요청을 취소하여 공간을 확보 할 수 있습니다.

나는 그것이 오래된 질문이지만 여전히 알고 있습니다. 수백만 행을 처리 할 수있는 dhtmlxGrid 도 있습니다. 행이 50,000 개인 데모 가 있지만 그리드에서로드 / 처리 할 수있는 행 수는 무제한입니다.

면책 조항 : 저는 DHTMLX 팀 출신입니다.

나는 당신이 이것을 읽는 것이 좋습니다

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

면책 조항 : 나는 오랫동안 두통없이 YUI DataTable 을 많이 사용 합니다 . 강력하고 안정적입니다. 사용자의 요구를 들어, 당신은 사용할 수 있습니다 ScrollingDataTable의 느릅 나무의 suports을

• x 스크롤
• y 스크롤
• xy 스크롤
• 강력한 이벤트 메커니즘

당신이 필요로하는 것을 원한다면 tableScrollEvent 입니다. API는 말합니다

고정 스크롤 DataTable에 스크롤이 있으면 시작됩니다.

각 DataTable은 DataSource를 사용하므로 필요에 따라 ScrollingDataTable을 채우기 위해 렌더링 루프 크기와 함께 tableScrollEvent 를 통해 데이터 를 모니터링 할 수 있습니다 .

렌더 루프 크기

DataTable이 매우 큰 데이터 집합을 모두 표시 해야하는 경우 renderLoopSize 구성은 브라우저 DOM 렌더링을 관리하여 UI 스레드가 매우 큰 테이블에 고정되지 않도록 도와 줍니다. 0보다 큰 값은 DOM 렌더링이 setTimeout () 체인에서 실행되어 각 루프에서 지정된 수의 행을 렌더링합니다. 딱딱하고 빠른 규칙이없고 일반적인 지침 만 있으므로 구현마다 이상적인 값을 결정해야합니다.

• 기본적으로 renderLoopSize는 0이므로 모든 행이 단일 루프로 렌더링됩니다. renderLoopSize> 0은 오버 헤드를 추가하므로 신중하게 사용하십시오.
• 데이터 집합 이 사용자가 시각적 렌더링에서 지연 시간을 경험하거나 스크립트가 중단되도록 충분히 큰 경우 (행 수 X 열 수 X 형식 복잡성) renderLoopSize 설정을 고려하십시오 .
• 50 미만의 renderLoopSize는 그만한 가치가 없을 것입니다. renderLoopSize> 100이 더 좋습니다.
• 데이터 세트는 수백 행과 수백 행이없는 한 충분히 큰 것으로 간주되지 않습니다.
• renderLoopSize> 0 및 <total rows를 사용하면 테이블이 하나의 루프 (렌더링 루프 크기 = 0과 동일)로 렌더링되지만 렌더링 후 행 스트라이핑과 같은 기능이 별도의 setTimeout 스레드에서 처리되도록 트리거합니다.

예를 들어

// 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>은 단일 DataSource 입니다. JSON, JSFunction, XML 및 단일 HTML 요소 일 수 있습니다.

여기 에서 내가 제공 한 간단한 튜토리얼을 볼 수 있습니다. 주의 다른 동시에 DATA_TABLE pluglin 지원 단일 및 이중 클릭. YUI DataTable을 사용하면 가능합니다. 또한 JQuery에서도 두통없이 사용할 수 있습니다.

몇 가지 예를 볼 수 있습니다

• 아이템 목록

YUI DataTable에 대한 다른 사항에 대해서는 언제든지 문의하십시오.

문안 인사,

jqGrid의 경우 가상 스크롤 기능을 사용할 수 있습니다.

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

그러나 다시 필터링으로 수백만 행을 수행 할 수 있습니다.

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

나는 "페이지가없는 것처럼"의 요점을 실제로 보지 못합니다. 브라우저에서 1,000,000 개의 행을 한 번에 표시 할 수있는 방법이 없습니다. 이것은 10MB의 HTML raw입니다. 사용자가 페이지를보고 싶지 않은 이유

어쨌든...

내가 생각할 수있는 가장 좋은 방법은 스크롤이 끝나기 전에 모든 스크롤 또는 일부 제한에 대해 데이터 청크를 json 형식으로로드하는 것입니다. json을 쉽게 객체로 변환 할 수 있으므로 테이블 행을 눈에 잘 띄지 않게 만들 수 있습니다

나는 Open rico를 강력히 추천한다 . 처음에는 구현하기가 어렵지만 일단 그것을 잡으면 결코 뒤를 돌아 보지 않을 것입니다.

나는이 질문이 몇 살이라는 것을 알고 있지만 jqgrid는 이제 가상 스크롤을 지원합니다.

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

그러나 페이지 매김이 비활성화 된 상태

시그마 그리드를 제안합니다. 시그마 그리드에는 수백만 행을 지원할 수있는 페이징 기능이 포함되어 있습니다. 또한 원격 페이징이 필요할 수 있습니다. 데모를 참조하십시오 http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

dGrid를 살펴보십시오.

https://dgrid.io/

사용자가 한 번에 수백만 행의 데이터를 볼 필요는 없지만 dGrid는 빠르게 한 번에 한 화면 씩 표시 할 수 있다는 데 동의합니다.

차를 만들기 위해 바다를 끓이지 마십시오.