数百万行のJavaScriptデータグリッド[終了]

JavaScriptを使用して、グリッド内の多数のデータ行（つまり、数百万行）をユーザーに提示する必要があります。

ユーザーは、一度にページを表示したり、有限量のデータのみを表示したりすることはできません。

むしろ、すべてのデータが利用可能であるように見えるはずです。

データを一度にダウンロードする代わりに、ユーザーがグリッドにスクロールすることにより、小さなチャンクがダウンロードされます。

このフロントエンドでは行は編集されないため、読み取り専用グリッドを使用できます。

この種のシームレスなページングのために、JavaScriptで記述されたどのデータグリッドが存在しますか？

（免責事項：私はSlickGridの作者です）

UPDATE これはSlickGridに実装されました。

より多くの行でSlickGridを機能させることに関する進行中の議論については、http：//github.com/mleibman/SlickGrid/issues#issue/22を参照してください。

問題は、SlickGridがスクロールバー自体を仮想化しないことです。スクロール可能な領域の高さは、すべての行の合計の高さに設定されます。ユーザーがスクロールしている間、行は引き続き追加および削除されますが、スクロール自体はブラウザーによって行われます。これにより、非常に高速でスムーズになります（オンスクロールイベントは非常に低速です）。要素の潜在的な高さを制限するブラウザのCSSエンジンにはバグ/制限があるという警告があります。IEの場合、これはたまたま0x123456または1193046ピクセルです。他のブラウザの場合、それはより高いです。

「largenum-fix」ブランチには実験的な回避策があり、スクロール可能領域に「ページ」を高さ1Mピクセルに設定し、それらのページ内での相対位置を使用することで、制限を大幅に引き上げています。CSSエンジンの高さ制限は実際のレイアウトエンジンとは異なり、かなり低いように見えるため、これによりはるかに高い上限が得られます。

SlickGridが現在他の実装よりも優れているパフォーマンスエッジを放棄することなく、無制限の行数に到達する方法を探しています。

ルディガー、これをどのように解決したか詳しく説明できますか？

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

「SlickGridは仮想レンダリングを使用して、パフォーマンスを低下させることなく数十万のアイテムを簡単に操作できるようにします。実際、10行のグリッドと100,000行のグリッドを操作してもパフォーマンスに違いはありません。」

いくつかのハイライト：

• 適応仮想スクロール（数十万行を処理）
• 非常に速いレンダリング速度
• よりリッチなセルのバックグラウンドポストレンダリング
• 構成可能でカスタマイズ可能
• 完全なキーボードナビゲーション
• 列のサイズ変更/並べ替え/表示/非表示
• 列の自動サイズ調整と強制フィット
• プラグイン可能なセルフォーマッターとエディター
• 新しい行の編集と作成のサポート。" 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人（グリッドを見ている人）がそのような集中力を発揮できると真剣に考えていますか？彼らは本当に1秒間で多くのことを成し遂げているのでしょうか、それとも、（おそらく）不要なものをフィルターで除外していますか？「適度なサイズ」のサブセットを表示した後、それらはそれらのレコードを自動的にフィルターで除外するフィルターを説明できると思います。

paxdiablo、Sleeper Smith、Lasse V Karlsenもほのめかしたように、あなた（そして彼ら）は要件を熟考していません。良い面としては、SlickGridを見つけたので、これらのフィルターの必要性がすぐに明らかになったと思います。

何百万ものデータ行をユーザーに真剣に示す必要がないことは確かです。

そのデータセットを理解または管理できるユーザーは世界中にいないため、技術的に管理できても、そのユーザーの既知の問題を解決することはできません。

代わりに、ユーザーがデータを見たい理由に焦点を当てます。ユーザーはデータを見るためだけにデータを見たいわけではありません。通常、質問されます。代わりにこれらの質問への回答に焦点を合わせると、実際の問題を解決する何かにはるかに近くなります。

バッファービュー機能を備えたExt JSグリッドをお勧めします。

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. 並べ替えや検索などの操作が100万件ほどのレコードの後に​​遅くなる
3. データはJavaScript配列に格納されるため、RAMは制限されています

100万レコード（IEを除く）でグリッドをテストしましたが、うまく機能します。デモと例については、記事を参照してください。

dojox.grid.DataGridは、データのJS抽象化を提供するため、提供されたdojo.dataストアを使用してさまざまなバックエンドにフックしたり、独自のストアを記述したりできます。この数のレコードのランダムアクセスをサポートするものが明らかに必要です。DataGridは完全なアクセシビリティも提供します。

編集して、dojox.gridで何百万ものレコードを表示し、必要な例を提供するMatthew Russellの記事へのリンクを示します。グリッドの古いバージョンを使用していますが、概念は同じで、互換性のないAPIの改善がいくつかあったことに注意してください。

ああ、それは完全に無料のオープンソースです。

私はjQueryグリッドプラグインを使用しました。

デモ

ここでは、スピードアップのために適用できるいくつかの最適化を示します。大声で考えてください。

行の数は数百万になる可能性があるため、サーバーからの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) * 10Mwhere 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および<合計行があると、テーブルは1つのループでレンダリングされます（renderLoopSize = 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プラグインがシングルクリックとデュアルクリックを同時にサポートしていないことに注意してください。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なので、見落とします。ユーザーがページを見たくない理由。

とにかく...

私が考えることができる最良のアプローチは、スクロールが終了する前に、すべてのスクロールまたはいくつかの制限について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はそれらをすばやく（一度に1画面ずつ）表示できます。

お茶を作るために海を沸騰させないでください。