数百万行のJavaScriptデータグリッド
JavaScriptを使用してグリッドでユーザーに多数のデータ行（つまり、数百万行）を提示する必要があります。
ユーザーは、一度にページを表示したり、有限量のデータのみを表示したりしないでください。
むしろ、すべてのデータが利用可能であるように見えるはずです。
データを一度にすべてダウンロードするのではなく、ユーザーがデータにアクセスすると（つまり、グリッドをスクロールして）小さなチャンクがダウンロードされます。
行はこのフロントエンドでは編集されないため、読み取り専用のグリッドを使用できます。
この種のシームレスなページングには、JavaScriptで記述されたデータグリッドが存在しますか？
（免責事項：私はSlickGridの著者です）
UPDATEこれは SlickGrid で実装されました。
http://github.com/mleibman/SlickGrid/issues#issue/22 をご覧ください。SlickGridをより多くの行で動作させるための継続的な議論について。
問題は、SlickGridがスクロールバー自体を仮想化しないことです。スクロール可能な領域の高さは、すべての行の合計の高さに設定されます。ユーザーがスクロールしているときに行は引き続き追加および削除されますが、スクロール自体はブラウザーによって行われます。これにより、非常に高速でありながらスムーズになります（オンスクロールイベントは非常に遅いことで有名です）。警告は、要素の潜在的な高さを制限するブラウザのCSSエンジンにバグ/制限があるということです。 IEの場合、0x123456または1193046ピクセルです。他のブラウザの場合、それは高くなります。
「largenum-fix」ブランチには、スクロール可能な領域に高さ1Mピクセルに設定された「ページ」を設定し、それらのページ内で相対的な位置を使用することにより、その制限を大幅に高める実験的な回避策があります。 CSSエンジンの高さ制限は実際のレイアウトエンジンとは異なり、大幅に低いように見えるため、これによりはるかに高い上限が与えられます。
SlickGridが現在他の実装よりも優れているパフォーマンスEdgeをあきらめることなく、無制限の行数に到達する方法を探しています。
Rudiger、これをどのように解決したか詳しく説明していただけますか？
http://wiki.github.com/mleibman/SlickGrid/
「SlickGridは仮想レンダリングを使用して、パフォーマンスを低下させることなく数十万のアイテムを簡単に操作できるようにします。実際、10行のグリッドと100行のグリッドでのパフォーマンスの違いはありません'000行。 "
いくつかのハイライト：
- 適応型仮想スクロール（数十万行を処理）
- 非常に速いレンダリング速度
- より豊かなセルの背景ポストレンダリング
- 構成可能およびカスタマイズ可能
- フルキーボードナビゲーション
- 列のサイズ変更/並べ替え/表示/非表示
- 列の自動サイズ調整と強制適合
- プラグイン可能なセルフォーマッタおよびエディタ
- 新しい行の編集および作成のサポート。）by mleibman
無料です（MITライセンス）。 jQueryを使用します。
私の意見で最高のグリッドは以下のとおりです。
- Flexigrid：http://flexigrid.info/
- jQuery Grid：http://www.trirand.com/blog/
- jqGridView：http://plugins.jquery.com/project/jqGridView
- jqxGrid：http://www.jqwidgets.com/
- イングリッド：http://reconstrukt.com/ingrid/
- SlickGridhttp://github.com/mleibman/SlickGrid
- DataTableshttp://www.datatables.net/index
- ShieldUIhttp://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows
私の最高の3つのオプションは、jqGrid、jqxGrid、およびDataTablesです。彼らは数千の行で動作し、仮想化をサポートできます。
私は火炎戦争を開始するつもりはありませんが、あなたの研究者が人間であると仮定すると、あなたは彼らをあなたが思うほど知りません。それらがhaveペタバイトのデータだからといって、何百万ものレコードでさえ意味のある方法で表示することはできません。彼らはwantと言って何百万ものレコードを見たいと思うかもしれませんが、それは馬鹿げています。最も優秀な研究者にいくつかの基本的な計算を行わせます。各レコードを1秒で見ると仮定します。そのレートでは、1000000秒かかり、これは6週間以上になります（40週間の労働時間のうち、食事やトイレの休憩はありません）。
彼ら（またはあなた）は、1人の人（グリッドを見ている人）がその種の集中力を高めることができると真剣に考えていますか？彼らはその1秒で本当に多くのことを成し遂げましたか、それともしないが望むものをフィルタリングする可能性が高いのでしょうか？ 「合理的なサイズの」サブセットを表示した後、それらのレコードを自動的に除外するフィルターを説明できると思われます。
PaxdiabloとSleeper SmithとLasse V Karlsenも暗示しているように、あなた（そして彼ら）は要件を熟考していません。上側では、SlickGridが見つかったので、これらのフィルターの必要性がすぐに明らかになったと確信しています。
かなり確実に言うと、何百万行ものデータをユーザーに表示する必要はありません。
そのデータセットを理解または管理できるユーザーは世界中にいないため、たとえ技術的にデータセットを取得したとしても、そのユーザーの既知の問題を解決することはできません。
代わりに、私はwhyユーザーがデータを見たいと思うことに焦点を合わせます。ユーザーは、データを見るためだけにデータを見たくありません。通常、質問があります。代わりにそれらの質問に答えることに焦点を合わせると、実際の問題を解決するものにずっと近くなるでしょう。
バッファービュー機能を備えたExt JSグリッドをお勧めします。
（免責事項：私はw2uiの著者です）
私は最近、100万レコードのJavaScriptグリッドを実装する方法に関する記事を書きました（ http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ） 。最終的に、それをより高くすることを妨げる3つの制限があることを発見しました。
- Divの高さに制限があります（仮想スクロールで克服できます）
- ソートや検索などの操作は、100万件程度のレコードの後、遅くなり始めます
- データはJavaScript配列に格納されるため、RAMは制限されます
100万レコード（IEを除く）でグリッドをテストしましたが、うまく機能します。デモと例については、記事をご覧ください。
dojox.grid.DataGrid はデータのJS抽象化を提供するため、提供されたdojo.dataストアを使用してさまざまなバックエンドに接続したり、独自のデータを記述したりできます。明らかに、この多くのレコードのランダムアクセスをサポートするものが必要です。 DataGridは完全なアクセシビリティも提供します。
編集してください Matthew Russellの記事 へのリンクがあります。これは必要な例を提供し、dojox.gridで何百万ものレコードを表示します。古いバージョンのグリッドを使用しますが、概念は同じであり、互換性のないAPIの改善点がいくつかあります。
ああ、それは完全に無料のオープンソースです。
以下に、速度を上げるために適用できる最適化をいくつか示します。大声で考えてください。
行数は数百万になる可能性があるため、サーバーからの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はscroll.topがコンテナの上部からのスクロール距離を表します。 ここに小さなデモ 。
より多くのデータをいつリクエストするかを検出するには、オブジェクトがスクロールイベントをリッスンするメディエーターとして機能することが理想的です。このオブジェクトは、ユーザーのスクロール速度を追跡し、ユーザーがスローダウンしているように見えるか、完全に停止したように見える場合、対応する行のデータ要求を行います。この方法でデータを取得することは、データが断片化されることを意味するため、キャッシュはそれを念頭に置いて設計する必要があります。
また、ブラウザの最大発信接続数の制限も重要な役割を果たします。ユーザーはAJAX要求を起動する特定の位置までスクロールできますが、それが完了する前にユーザーは他の部分にスクロールできます。サーバーが十分に応答しない場合、要求はキューに入れられ、アプリケーションは応答しないように見えます。要求マネージャーを使用して、すべての要求をルーティングし、保留中の要求をキャンセルしてスペースを確保できます。
jQuery Grid Plugin を使用しました。
私はそれが古い質問であることを知っていますが、それでも.. dhtmlxGrid があり、何百万もの行を処理できます。デモがあります 50,000行 が、グリッドにロード/処理できる行の数に制限はありません。
免責事項：私はDHTMLXチームから来ました。
ポイントを見るのにちょっと失敗しました。jqGridの場合、仮想スクロール機能を使用できます。
http://www.trirand.net/aspnetmvc/grid/performancevirtualscrolling
ただし、フィルタリングを使用して数百万行を実行できます。
http://www.trirand.net/aspnetmvc/grid/performancelinq
「ページがないかのように」という点を本当に見逃しています。つまり、ブラウザに一度に1,000,000行を表示する方法はありません。ユーザーがページを見たくない理由。
とにかく...
免責事項：i 重い use YUI DataTable長時間頭痛のない。強力で安定しています。必要に応じて、 ScrollingDataTable wich suportsを使用できます
- xスクロール
- yスクロール
- xyスクロール
- 強力なイベントメカニズム
必要なものについては、tableScrollEventが欲しいと思います。そのAPIは言う
固定スクロールDataTableにスクロールがあるときに発生します。
各DataTableはDataSourceを使用するため、データを監視できます tableScrollEventを介してレンダーループサイズと一緒に必要に応じてScrollingDataTableを設定します。
レンダリングループサイズは言う
DataTableが非常に大きなデータセット全体を表示する必要がある場合、renderLoopSize構成はブラウザーのDOMレンダリングの管理に役立ち、UIスレッドが非常に大きなテーブルでロックされない。 0より大きい値を設定すると、各ループで指定された行数をレンダリングするsetTimeout（）チェーンでDOMレンダリングが実行されます。厳密なルールはなく、一般的なガイドラインのみがあるため、実装ごとに理想的な値を決定する必要があります。
- デフォルトでは、renderLoopSizeは0であるため、すべての行が単一のループでレンダリングされます。 renderLoopSize> 0はオーバーヘッドを追加するため、慎重に使用してください。
- データのセットが十分に大きい場合（行数X列数X書式設定の複雑さ）ユーザーが視覚的なレンダリングで遅延を経験する、および/またはスクリプトがハングする原因となる検討するrenderLoopSizeの設定。
- 50未満のrenderLoopSizeはおそらく価値がありません。 renderLoopSize> 100の方がおそらく良いでしょう。
- データセットは、数百行の行がない限り、おそらく十分に大きいとは見なされません。
- RenderLoopSize> 0および<total rowsがあると、テーブルが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要素でもかまいません
こちら 私から提供された簡単なチュートリアルを見ることができます。注意してくださいno no DATA_TABLE pluglinは、シングルクリックとデュアルクリックを同時にサポートします。 YUI DataTableを使用するとできます。さらに、頭痛のないJQueryでも使用できます
いくつかの例、あなたは見ることができます
YUI DataTableについて他に必要なことについて気軽に質問してください。
よろしく、
私が考えることができる最良のアプローチは、スクロールが終了する前に、すべてのスクロールまたは何らかの制限に対してjson形式でデータのチャンクをロードすることです。 jsonは簡単にオブジェクトに変換できるため、テーブルの行は控えめに簡単に構築できます。
この質問は数年前ですが、jqgridは仮想スクロールをサポートしています。
http://www.trirand.com/blog/phpjqgrid/examples/paging/scrollbar/default.php
しかし、ページネーションが無効になっている
Open ricoを強くお勧めします。初めに実装することは困難ですが、一度それをつかむと後戻りすることはありません。
シグマグリッドには、数百万行をサポートできるページング機能が組み込まれていることをお勧めします。また、リモートページングが必要になる場合があります。デモを見る http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html
DGridを見てください。
http://dojofoundation.org/packages/dgrid/
ユーザーが一度に何百万行ものデータを表示する必要は決してないことに同意しますが、dGridはそれらをすばやく表示できます（一度に1画面ずつ）。
お茶を入れて海を沸かさないでください。