Lưới dữ liệu JavaScript cho hàng triệu hàng [đã đóng]

Tôi cần trình bày một số lượng lớn các hàng dữ liệu (ví dụ: hàng triệu hàng) cho người dùng trong lưới bằng JavaScript.

Người dùng không nên xem các trang hoặc chỉ xem số lượng dữ liệu hữu hạn tại một thời điểm.

Thay vào đó, nó sẽ xuất hiện rằng tất cả các dữ liệu có sẵn.

Thay vì tải xuống tất cả dữ liệu cùng một lúc, các đoạn nhỏ được tải xuống khi người dùng đến với chúng (tức là bằng cách cuộn qua lưới).

Các hàng sẽ không được chỉnh sửa thông qua giao diện người dùng này, vì vậy các lưới chỉ đọc được chấp nhận.

Những lưới dữ liệu nào, được viết bằng JavaScript, tồn tại cho loại phân trang liền mạch này?

( Tuyên bố miễn trừ trách nhiệm: Tôi là tác giả của SlickGrid )

CẬP NHẬT Điều này hiện đã được thực hiện trong SlickGrid .

Vui lòng xem http://github.com/mleibman/SlickGrid/issues#su/22 để biết cuộc thảo luận liên tục về việc làm cho SlickGrid hoạt động với số lượng hàng lớn hơn.

Vấn đề là SlickGrid không ảo hóa chính thanh cuộn - chiều cao của vùng cuộn được đặt thành tổng chiều cao của tất cả các hàng. Các hàng vẫn đang được thêm và xóa khi người dùng đang cuộn, nhưng việc cuộn chính nó được thực hiện bởi trình duyệt. Điều đó cho phép nó rất nhanh nhưng vẫn mượt mà (các sự kiện onscroll nổi tiếng là chậm). Thông báo trước là có các lỗi / giới hạn trong các công cụ CSS của trình duyệt giới hạn chiều cao tiềm năng của một phần tử. Đối với IE, điều đó xảy ra là 0x123456 hoặc 1193046 pixel. Đối với các trình duyệt khác, nó cao hơn.

Có một cách giải quyết thử nghiệm trong nhánh "sửa lỗi lớn" tăng giới hạn đáng kể bằng cách điền vào vùng có thể cuộn với "trang" được đặt thành chiều cao 1M pixel và sau đó sử dụng định vị tương đối trong các trang đó. Vì giới hạn chiều cao trong công cụ CSS dường như khác và thấp hơn đáng kể so với công cụ bố cục thực tế, điều này mang lại cho chúng tôi giới hạn trên cao hơn nhiều.

Tôi vẫn đang tìm cách để có được số lượng hàng không giới hạn mà không từ bỏ cạnh hiệu suất mà SlickGrid hiện đang nắm giữ so với các triển khai khác.

Rudiger, bạn có thể giải thích về cách bạn giải quyết điều này?

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

" SlickGrid sử dụng kết xuất ảo để cho phép bạn dễ dàng làm việc với hàng trăm nghìn mục mà không làm giảm hiệu suất. Trên thực tế, không có sự khác biệt nào về hiệu suất giữa làm việc với lưới có 10 hàng so với 100.000 hàng. "

Một số điểm nổi bật:

• Cuộn ảo thích ứng (xử lý hàng trăm ngàn hàng)
• Tốc độ kết xuất cực nhanh
• Kết xuất nền cho các ô phong phú hơn
• Cấu hình và tùy chỉnh
• Điều hướng bàn phím đầy đủ
• Thay đổi kích thước cột / sắp xếp lại / hiển thị / ẩn
• Cột tự động & phù hợp với lực
• Trình định dạng và trình soạn thảo tế bào có thể cắm
• Hỗ trợ chỉnh sửa và tạo hàng mới. "bởi mleibman

Nó miễn phí (giấy phép MIT). Nó sử dụng jQuery.

Các lưới tốt nhất theo ý kiến ​​của tôi là dưới đây:

• Linh hoạt: http://flexigrid.info/
• Lưới 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
• Dữ liệu dữ liệu http://www.datatables.net/index
• ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows

3 tùy chọn tốt nhất của tôi là jqGrid, jqxGrid và DataTables. Họ có thể làm việc với hàng ngàn hàng và hỗ trợ ảo hóa.

Tôi không có ý bắt đầu một cuộc chiến rực lửa, nhưng giả sử các nhà nghiên cứu của bạn là con người, bạn không biết họ cũng như bạn nghĩ. Chỉ vì họ có hàng petabyte dữ liệu không khiến họ có khả năng xem hàng triệu bản ghi theo bất kỳ cách có ý nghĩa nào. Họ có thể nói rằng họ muốn xem hàng triệu hồ sơ, nhưng điều đó thật ngớ ngẩn. Yêu cầu các nhà nghiên cứu thông minh nhất của bạn thực hiện một số phép toán cơ bản: Giả sử họ dành 1 giây để xem mỗi bản ghi. Với tốc độ đó, sẽ mất 1000000 giây, hoạt động trong hơn sáu tuần (trong 40 giờ làm việc - tuần không có giờ nghỉ cho thức ăn hoặc nhà vệ sinh).

Họ (hoặc bạn) nghiêm túc nghĩ rằng một người (người nhìn vào lưới điện) có thể tập trung được loại sự tập trung đó không? Họ có thực sự làm được nhiều việc trong 1 giây đó không, hay họ (nhiều khả năng) đang lọc ra những thứ không muốn? Tôi nghi ngờ rằng sau khi xem một tập hợp con "có kích thước hợp lý", họ có thể mô tả một bộ lọc cho bạn để tự động lọc ra các bản ghi đó.

Như paxdiablo và Sleeper Smith và Lasse V Karlsen cũng ngụ ý, bạn (và họ) đã không nghĩ đến các yêu cầu. Về phía trước, bây giờ bạn đã tìm thấy SlickGrid, tôi chắc chắn rằng nhu cầu về các bộ lọc đó đã trở nên rõ ràng ngay lập tức.

Tôi có thể nói với một sự chắc chắn khá tốt rằng bạn thực sự không cần phải hiển thị hàng triệu hàng dữ liệu cho người dùng.

Trên thế giới không có người dùng nào có thể hiểu hoặc quản lý tập dữ liệu đó, ngay cả khi bạn quản lý kỹ thuật để loại bỏ nó, bạn sẽ không giải quyết bất kỳ vấn đề nào đã biết cho người dùng đó.

Thay vào đó tôi sẽ tập trung vào lý do tại sao người dùng muốn xem dữ liệu. Người dùng không muốn xem dữ liệu chỉ để xem dữ liệu, thường có một câu hỏi được đặt ra. Nếu bạn tập trung vào việc trả lời những câu hỏi đó, thì bạn sẽ gần gũi hơn với một vấn đề giải quyết vấn đề thực tế.

Tôi khuyên dùng Ext JS Grid với tính năng Buffered View.

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

(Tuyên bố miễn trừ trách nhiệm: Tôi là tác giả của w2ui)

Gần đây tôi đã viết một bài viết về cách triển khai lưới JavaScript với 1 triệu bản ghi ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Tôi phát hiện ra rằng cuối cùng có 3 hạn chế ngăn không cho nó cao hơn:

1. Chiều cao của div có giới hạn (có thể khắc phục bằng cách cuộn ảo)
2. Các hoạt động như sắp xếp và tìm kiếm bắt đầu chậm sau 1 triệu bản ghi hoặc hơn
3. RAM bị giới hạn vì dữ liệu được lưu trữ trong mảng JavaScript

Tôi đã kiểm tra lưới với 1 triệu bản ghi (trừ IE) và nó hoạt động tốt. Xem bài viết cho các bản demo và ví dụ.

dojox.grid.DataGrid cung cấp một bản tóm tắt JS cho dữ liệu để bạn có thể kết nối nó với nhiều phụ trợ khác nhau với các cửa hàng dojo.data được cung cấp hoặc tự viết. Rõ ràng bạn sẽ cần một cái hỗ trợ truy cập ngẫu nhiên cho nhiều hồ sơ này. DataGrid cũng cung cấp khả năng truy cập đầy đủ.

Chỉnh sửa để đây là một liên kết đến bài viết của Matthew Russell sẽ cung cấp ví dụ bạn cần, xem hàng triệu bản ghi với dojox.grid. Lưu ý rằng nó sử dụng phiên bản cũ của lưới, nhưng các khái niệm là như nhau, chỉ có một số cải tiến API không tương thích.

Ồ, và đó là nguồn mở hoàn toàn miễn phí.

Tôi đã sử dụng Plugin jQuery Grid , nó rất tuyệt.

Trình diễn

Dưới đây là một vài tối ưu hóa bạn có thể áp dụng để tăng tốc mọi thứ. Chỉ cần suy nghĩ thành tiếng.

Vì số lượng hàng có thể lên tới hàng triệu, bạn sẽ muốn có một hệ thống lưu trữ chỉ dành cho dữ liệu JSON từ máy chủ. Tôi không thể tưởng tượng bất cứ ai muốn tải xuống tất cả X triệu mặt hàng, nhưng nếu họ làm vậy, đó sẽ là một vấn đề. Thử nghiệm nhỏ này trên Chrome cho một mảng trên 20M + số nguyên liên tục gặp sự cố trên máy của tôi.

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

Bạn có thể sử dụng LRU hoặc một số thuật toán bộ đệm khác và có giới hạn trên về số lượng dữ liệu bạn muốn lưu vào bộ đệm.

Đối với chính các ô của bảng, tôi nghĩ rằng việc xây dựng / hủy các nút DOM có thể tốn kém. Thay vào đó, bạn chỉ có thể xác định trước số lượng ô X và bất cứ khi nào người dùng cuộn đến một vị trí mới, hãy tiêm dữ liệu JSON vào các ô này. Thanh cuộn hầu như không có mối quan hệ trực tiếp với bao nhiêu không gian (chiều cao) được yêu cầu để thể hiện toàn bộ tập dữ liệu. Bạn có thể tùy ý đặt chiều cao của bảng chứa, giả sử 5000px và ánh xạ tới tổng số hàng. Ví dụ: nếu chiều cao vùng chứa là 5000px và có tổng số 10M hàng, thì vị starting row ≈ (scroll.top/5000) * 10Mtrí scroll.topđại diện cho khoảng cách cuộn từ đỉnh của container. Bản demo nhỏ ở đây .

Để phát hiện khi nào cần yêu cầu nhiều dữ liệu hơn, lý tưởng nhất là một đối tượng nên đóng vai trò trung gian lắng nghe các sự kiện cuộn. Đối tượng này theo dõi tốc độ cuộn của người dùng và khi có vẻ như người dùng đang chậm lại hoặc đã dừng hoàn toàn, hãy đưa ra yêu cầu dữ liệu cho các hàng tương ứng. Lấy dữ liệu theo cách này có nghĩa là dữ liệu của bạn sẽ bị phân mảnh, do đó, bộ nhớ cache nên được thiết kế theo ý đó.

Ngoài ra, giới hạn trình duyệt trên các kết nối gửi tối đa có thể đóng một phần quan trọng. Người dùng có thể cuộn đến một vị trí nhất định sẽ thực hiện yêu cầu AJAX, nhưng trước khi kết thúc, người dùng có thể cuộn đến một số phần khác. Nếu máy chủ không đủ đáp ứng, các yêu cầu sẽ được xếp hàng và ứng dụng sẽ không phản hồi. Bạn có thể sử dụng trình quản lý yêu cầu thông qua đó tất cả các yêu cầu được định tuyến và nó có thể hủy các yêu cầu đang chờ xử lý để tạo khoảng trống.

Tôi biết đó là một câu hỏi cũ nhưng vẫn còn .. Ngoài ra còn có dhtmlxGrid có thể xử lý hàng triệu hàng. Có một bản demo với 50.000 hàng nhưng số lượng hàng có thể được tải / xử lý trong lưới là không giới hạn.

Tuyên bố miễn trừ trách nhiệm: Tôi đến từ nhóm DHTMLX.

Tôi đề nghị bạn đọc cái này

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

Disclaimer: tôi sử dụng YUI DataTable rất nhiều mà không phải đau đầu trong một thời gian dài . Nó mạnh mẽ và ổn định. Đối với nhu cầu của bạn, bạn có thể sử dụng một suports ScrollingDataTable

• cuộn x
• cuộn y
• xy-cuộn
• Một cơ chế tổ chức sự kiện mạnh mẽ

Đối với những gì bạn cần, tôi nghĩ rằng bạn muốn là một bảngScrollEvent . API của nó nói

Được kích hoạt khi DataTable cuộn cố định có cuộn.

Vì mỗi DataTable sử dụng DataSource, bạn có thể theo dõi dữ liệu của nó thông qua bảngScrollEvent cùng với kích thước vòng lặp kết xuất để đưa vào ScrollingDataTable của bạn theo nhu cầu của bạn.

Kết xuất kích thước vòng lặp cho biết

Trong trường hợp DataTable của bạn cần hiển thị toàn bộ một tập hợp dữ liệu rất lớn, cấu hình renderLoopSize có thể giúp quản lý kết xuất DOM của trình duyệt để luồng UI không bị khóa trên các bảng rất lớn . Bất kỳ giá trị nào lớn hơn 0 sẽ khiến kết xuất DOM được thực thi trong chuỗi setTimeout () hiển thị số lượng hàng được chỉ định trong mỗi vòng lặp. Giá trị lý tưởng nên được xác định cho mỗi lần thực hiện vì không có quy tắc cứng và nhanh, chỉ có hướng dẫn chung:

• Theo mặc định renderLoopSize là 0, vì vậy tất cả các hàng được hiển thị trong một vòng lặp. Một renderLoopSize> 0 thêm chi phí để sử dụng chu đáo.
• Nếu bộ dữ liệu của bạn đủ lớn (số lượng hàng X số độ phức tạp định dạng của Cột X) mà người dùng gặp phải độ trễ trong kết xuất trực quan và / hoặc nó khiến tập lệnh bị treo, hãy xem xét cài đặt renderLoopSize .
• Một renderLoopSize dưới 50 có lẽ không đáng. Một renderLoopSize> 100 có lẽ tốt hơn.
• Một tập dữ liệu có thể không được coi là đủ lớn trừ khi nó có hàng trăm và hàng trăm hàng.
• Việc có renderLoopSize> 0 và <tổng số hàng sẽ khiến bảng được hiển thị trong một vòng lặp (giống như renderLoopSize = 0) nhưng nó cũng kích hoạt chức năng như phân loại hàng sau kết xuất được xử lý từ một luồng setTimeout riêng biệt.

Ví dụ

// 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> chỉ là một Nguồn dữ liệu duy nhất . Nó có thể là một JSON, JSFunction, XML và thậm chí là một phần tử HTML duy nhất

Ở đây bạn có thể thấy một hướng dẫn đơn giản, được cung cấp bởi tôi. Xin lưu ý rằng không có trình cắm DATA_TABLE nào khác hỗ trợ nhấp chuột đơn và kép cùng một lúc. YUI DataTable cho phép bạn. Và hơn nữa, bạn có thể sử dụng nó ngay cả với JQuery mà không phải đau đầu

Một số ví dụ, bạn có thể thấy

• Danh sách mục

Hãy hỏi về bất cứ điều gì khác mà bạn muốn về YUI DataTable.

Trân trọng,

Tôi không thể thấy được điểm này, vì jqGrid bạn có thể sử dụng chức năng cuộn ảo:

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

nhưng sau đó, một lần nữa, hàng triệu hàng với tính năng lọc có thể được thực hiện:

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

Tôi thực sự không thấy quan điểm "như thể không có trang", ý tôi là ... không có cách nào để hiển thị 1.000.000 hàng cùng một lúc trong trình duyệt - đây là 10 MB HTML thô, tôi không thể thấy tại sao người dùng không muốn xem các trang.

Dù sao...

Cách tiếp cận tốt nhất tôi có thể nghĩ đến là bằng cách tải khối dữ liệu ở định dạng json cho mỗi cuộn hoặc một số giới hạn trước khi cuộn kết thúc. json có thể dễ dàng chuyển đổi thành các đối tượng và do đó các hàng của bảng có thể được xây dựng dễ dàng một cách dễ dàng

Tôi rất muốn giới thiệu Open rico . Thật khó để thực hiện ngay từ đầu, nhưng một khi bạn lấy nó, bạn sẽ không bao giờ nhìn lại.

Tôi biết câu hỏi này đã được vài năm tuổi, nhưng jqgrid hiện hỗ trợ cuộn ảo:

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

nhưng bị vô hiệu hóa phân trang

Tôi đề nghị lưới sigma, lưới sigma có các tính năng phân trang nhúng có thể hỗ trợ hàng triệu hàng. Và ngoài ra, bạn có thể cần một phân trang từ xa để làm điều đó. xem bản demo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Hãy xem dGrid:

https://dgrid.io/

Tôi đồng ý rằng người dùng sẽ KHÔNG BAO GIỜ, EVER cần phải xem hàng triệu hàng dữ liệu cùng một lúc, nhưng dGrid có thể hiển thị chúng nhanh chóng (một màn hình tại một thời điểm).

Đừng đun sôi đại dương để pha một tách trà.