Kisi data JavaScript untuk jutaan baris [ditutup]

Saya perlu menyajikan sejumlah besar baris data (mis. Jutaan baris) kepada pengguna dalam kotak menggunakan JavaScript.

Pengguna seharusnya tidak melihat halaman atau hanya melihat data dalam jumlah terbatas pada suatu waktu.

Sebaliknya, akan muncul bahwa semua data tersedia.

Alih-alih mengunduh data sekaligus, potongan kecil diunduh saat pengguna datang kepada mereka (mis. Dengan menggulir melalui grid).

Baris tidak akan diedit melalui ujung depan ini, jadi grid hanya baca dapat diterima.

Kisi data apa, yang ditulis dalam JavaScript, ada untuk jenis paging tanpa batas ini?

( Penafian: Saya penulis SlickGrid )

PEMBARUAN Ini sekarang telah diterapkan di SlickGrid .

Silakan lihat http://github.com/mleibman/SlickGrid/issues#issue/22 untuk diskusi berkelanjutan tentang membuat SlickGrid berfungsi dengan jumlah baris yang lebih banyak.

Masalahnya adalah bahwa SlickGrid tidak memvirtualisasikan scrollbar itu sendiri - ketinggian area yang dapat digulir diatur ke tinggi total semua baris. Baris masih ditambahkan dan dihapus saat pengguna sedang menggulir, tetapi pengguliran itu sendiri dilakukan oleh browser. Itu memungkinkan untuk menjadi sangat cepat namun lancar (acara onroll sangat terkenal lambat). Peringatannya adalah bahwa ada bug / batas dalam mesin CSS browser yang membatasi ketinggian potensial suatu elemen. Untuk IE, itu adalah 0x123456 atau 1193046 piksel. Untuk browser lain, ini lebih tinggi.

Ada solusi eksperimental di cabang "fix-fix" yang meningkatkan batas itu secara signifikan dengan mengisi area yang dapat digulir dengan "halaman" yang diatur ke ketinggian 1M piksel dan kemudian menggunakan posisi relatif di dalam halaman tersebut. Karena batas ketinggian di mesin CSS tampaknya berbeda dan jauh lebih rendah daripada di mesin tata letak yang sebenarnya, ini memberi kita batas atas yang jauh lebih tinggi.

Saya masih mencari cara untuk mendapatkan jumlah baris yang tidak terbatas tanpa melepaskan keunggulan kinerja yang saat ini dimiliki SlickGrid atas implementasi lainnya.

Rudiger, dapatkah Anda menjelaskan bagaimana Anda memecahkan ini?

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

" SlickGrid menggunakan rendering virtual untuk memungkinkan Anda bekerja dengan mudah dengan ratusan ribu item tanpa penurunan kinerja. Bahkan, tidak ada perbedaan dalam kinerja antara bekerja dengan grid dengan 10 baris versus 100'000 baris. "

Beberapa hal penting:

• Pengguliran virtual adaptif (menangani ratusan ribu baris)
• Kecepatan rendering yang sangat cepat
• Latar belakang pasca rendering untuk sel yang lebih kaya
• Dapat dikonfigurasi & disesuaikan
• Navigasi keyboard lengkap
• Ubah ukuran kolom / atur ulang / tampilkan / sembunyikan
• Kolom diotomatiskan & dipaksakan
• Pemformat & editor sel Pluggable
• Dukungan untuk mengedit dan membuat baris baru. "oleh mleibman

Ini gratis (lisensi MIT). Ini menggunakan jQuery.

Grid terbaik menurut saya adalah di bawah ini:

• 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

3 pilihan terbaik saya adalah jqGrid, jqxGrid dan DataTables. Mereka dapat bekerja dengan ribuan baris dan mendukung virtualisasi.

Saya tidak bermaksud memulai perang api, tetapi dengan anggapan peneliti Anda adalah manusia, Anda tidak mengenal mereka sebaik yang Anda pikirkan. Hanya karena mereka memiliki petabyte data tidak membuat mereka mampu melihat jutaan catatan dengan cara apa pun yang berarti. Mereka mungkin mengatakan ingin melihat jutaan rekaman, tapi itu konyol. Mintalah para peneliti Anda yang paling cerdas melakukan beberapa matematika dasar: Asumsikan mereka menghabiskan 1 detik melihat setiap catatan. Pada tingkat itu, akan dibutuhkan 10.00000 detik, yang bekerja lebih dari enam minggu (40 jam kerja-minggu tanpa istirahat untuk makanan atau toilet).

Apakah mereka (atau Anda) serius berpikir satu orang (yang melihat grid) dapat mengumpulkan konsentrasi semacam itu? Apakah mereka benar-benar menyelesaikan banyak hal dalam 1 detik, atau apakah mereka (lebih mungkin) menyaring hal-hal yang tidak diinginkan? Saya menduga bahwa setelah melihat subset "berukuran cukup", mereka dapat mendeskripsikan filter untuk Anda yang akan secara otomatis menyaring catatan tersebut.

Seperti paxdiablo dan Sleeper Smith dan Lasse V Karlsen juga menyiratkan, Anda (dan mereka) belum memikirkan persyaratannya. Di sisi atas, sekarang Anda telah menemukan SlickGrid, saya yakin kebutuhan untuk filter-filter itu menjadi jelas.

Saya dapat mengatakan dengan kepastian yang cukup baik bahwa Anda serius tidak perlu menunjukkan jutaan baris data kepada pengguna.

Tidak ada pengguna di dunia yang akan dapat memahami atau mengelola kumpulan data itu sehingga bahkan jika Anda secara teknis berhasil melakukannya, Anda tidak akan memecahkan masalah yang diketahui untuk pengguna itu.

Sebagai gantinya saya akan fokus pada mengapa pengguna ingin melihat data. Pengguna tidak ingin melihat data hanya untuk melihat data, biasanya ada pertanyaan yang diajukan. Jika Anda berfokus untuk menjawab pertanyaan-pertanyaan itu, maka Anda akan lebih dekat dengan sesuatu yang memecahkan masalah aktual.

Saya merekomendasikan Ext JS Grid dengan fitur Buffered View.

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

(Penafian: Saya adalah penulis w2ui)

Saya baru-baru ini menulis sebuah artikel tentang bagaimana menerapkan JavaScript grid dengan 1 juta catatan ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Saya menemukan bahwa pada akhirnya ada 3 batasan yang mencegah dari mengambilnya lebih tinggi:

1. Ketinggian div memiliki batas (dapat diatasi dengan scrolling virtual)
2. Operasi seperti pengurutan dan pencarian mulai lambat setelah sekitar 1 juta rekaman
3. RAM terbatas karena data disimpan dalam array JavaScript

Saya telah menguji grid dengan 1 juta catatan (kecuali IE) dan kinerjanya baik. Lihat artikel untuk demo dan contoh.

dojox.grid.DataGrid menawarkan abstraksi JS untuk data sehingga Anda dapat menghubungkannya ke berbagai backend dengan toko dojo.data yang disediakan atau menulis sendiri. Anda pasti membutuhkan satu yang mendukung akses acak untuk banyak catatan ini. DataGrid juga menyediakan aksesibilitas penuh.

Sunting jadi di sini adalah tautan ke artikel Matthew Russell yang seharusnya memberikan contoh yang Anda butuhkan, melihat jutaan catatan dengan dojox.grid. Perhatikan bahwa ia menggunakan versi grid yang lama, tetapi konsepnya sama, hanya ada beberapa peningkatan API yang tidak kompatibel.

Oh, dan ini open source sepenuhnya gratis.

Saya menggunakan Plugin jQuery Grid , itu bagus.

Demo

Berikut adalah beberapa optimasi yang dapat Anda terapkan untuk mempercepat. Hanya berpikir keras.

Karena jumlah baris dapat mencapai jutaan, Anda perlu sistem caching hanya untuk data JSON dari server. Saya tidak bisa membayangkan ada orang yang ingin mengunduh semua X juta item, tetapi jika mereka melakukannya, itu akan menjadi masalah. Tes kecil ini di Chrome untuk array pada 20M + integer crash di mesin saya terus-menerus.

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

Anda bisa menggunakan LRU atau algoritma caching lainnya dan memiliki batas atas berapa banyak data yang ingin Anda cache.

Untuk sel tabel sendiri, saya pikir membangun / menghancurkan node DOM bisa mahal. Alih-alih, Anda bisa menentukan sebelumnya jumlah sel X, dan kapan pun pengguna menggulir ke posisi baru, masukkan data JSON ke dalam sel-sel ini. Bilah gulir hampir tidak memiliki hubungan langsung dengan berapa banyak ruang (tinggi) yang diperlukan untuk mewakili seluruh dataset. Anda bisa secara sewenang-wenang mengatur ketinggian penampung tabel, katakan 5000px, dan petakan itu ke jumlah baris. Misalnya, jika ketinggian wadah adalah 5000px dan ada total baris 10M, maka di starting row ≈ (scroll.top/5000) * 10Mmana scroll.topmewakili jarak gulir dari bagian atas wadah. Demo kecil di sini .

Untuk mendeteksi kapan meminta lebih banyak data, idealnya sebuah objek harus bertindak sebagai mediator yang mendengarkan gulir peristiwa. Objek ini melacak seberapa cepat pengguna menggulir, dan ketika sepertinya pengguna melambat atau benar-benar berhenti, membuat permintaan data untuk baris yang sesuai. Mengambil data dengan cara ini berarti data Anda akan terfragmentasi, jadi cache harus dirancang dengan mempertimbangkan hal itu.

Juga batas browser pada koneksi keluar maksimum dapat memainkan bagian penting. Seorang pengguna dapat menggulir ke posisi tertentu yang akan memecat permintaan AJAX, tetapi sebelum itu selesai pengguna dapat menggulir ke bagian lain. Jika server tidak cukup responsif permintaan akan antri dan aplikasi akan terlihat tidak responsif. Anda bisa menggunakan manajer permintaan melalui mana semua permintaan dialihkan, dan itu dapat membatalkan permintaan yang tertunda untuk membuat ruang.

Saya tahu ini pertanyaan lama tapi tetap saja .. Ada juga dhtmlxGrid yang dapat menangani jutaan baris. Ada demo dengan 50.000 baris tetapi jumlah baris yang dapat dimuat / diproses dalam grid tidak terbatas.

Penafian: Saya dari tim DHTMLX.

Saya sarankan Anda membaca ini

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

Penafian: Saya banyak menggunakan YUI DataTable tanpa sakit kepala untuk waktu yang lama . Ia kuat dan stabil. Untuk kebutuhan Anda, Anda dapat menggunakan suport ScrollingDataTable yang

• gulir x
• menggulir-y
• xy-scrolling
• Mekanisme Acara yang kuat

Untuk apa yang Anda butuhkan, saya pikir Anda inginkan adalah tableScrollEvent . API-nya mengatakan

Dipecat ketika gulir tetap DataTable memiliki gulir.

Karena setiap DataTable menggunakan DataSource, Anda dapat memantau datanya melalui tableScrollEvent bersama dengan ukuran render loop untuk mengisi ScrollingDataTable Anda sesuai dengan kebutuhan Anda.

Render ukuran lingkaran kata

Dalam kasus di mana DataTable Anda perlu menampilkan keseluruhan set data yang sangat besar, konfigurasi renderLoopSize dapat membantu mengelola rendering DOM browser sehingga utas UI tidak terkunci pada tabel yang sangat besar . Nilai apa pun yang lebih besar dari 0 akan menyebabkan rendering DOM dieksekusi di rantai setTimeout () yang merender jumlah baris yang ditentukan di setiap loop. Nilai ideal harus ditentukan per implementasi karena tidak ada aturan keras dan cepat, hanya pedoman umum:

• Secara default renderLoopSize adalah 0, jadi semua baris dirender dalam satu loop. A renderLoopSize> 0 menambahkan overhead jadi gunakan dengan bijaksana.
• Jika kumpulan data Anda cukup besar (jumlah baris X jumlah kompleksitas pemformatan Kolom X) yang dialami pengguna dalam latensi rendering visual dan / atau menyebabkan skrip digantung, pertimbangkan untuk mengatur renderLoopSize .
• RenderLoopSize di bawah 50 mungkin tidak sepadan. RenderLoopSize> 100 mungkin lebih baik.
• Satu set data mungkin tidak dianggap cukup besar kecuali memiliki ratusan dan ratusan baris.
• Memiliki renderLoopSize> 0 dan <total rows memang menyebabkan tabel di-render dalam satu loop (sama seperti renderLoopSize = 0) tetapi juga memicu fungsionalitas seperti striping post-render yang akan ditangani dari thread setTimeout yang terpisah.

Misalnya

// 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> hanya satu DataSource . Ini bisa berupa JSON, JSFunction, XML dan bahkan elemen HTML tunggal

Di sini Anda dapat melihat tutorial Sederhana, yang disediakan oleh saya. Ketahuilah tidak ada pluglin DATA_TABLE lainnya yang mendukung klik tunggal dan ganda pada saat yang sama. YUI DataTable memungkinkan Anda. Dan banyak lagi, Anda dapat menggunakannya bahkan dengan JQuery tanpa sakit kepala

Beberapa contoh, bisa Anda lihat

• Daftar barang

Jangan ragu untuk bertanya tentang hal lain yang Anda inginkan tentang YUI DataTable.

salam,

Saya agak gagal melihat intinya, untuk jqGrid Anda dapat menggunakan fungsi gulir virtual:

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

tetapi sekali lagi, jutaan baris dengan penyaringan dapat dilakukan:

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

Saya benar-benar gagal melihat titik "seolah-olah tidak ada halaman" meskipun, maksud saya ... tidak ada cara untuk menampilkan 1.000.000 baris sekaligus di browser - ini adalah 10MB HTML mentah, saya agak gagal melihat mengapa pengguna tidak ingin melihat halaman.

Bagaimanapun...

Pendekatan terbaik yang bisa saya pikirkan adalah dengan memuat potongan data dalam format json untuk setiap gulir atau batas tertentu sebelum gulir berakhir. json dapat dengan mudah dikonversi menjadi objek dan karenanya baris tabel dapat dibangun dengan mudah tanpa mengganggu

Saya sangat merekomendasikan Open rico . Sulit untuk diterapkan di awal, tetapi begitu Anda meraihnya, Anda tidak akan pernah melihat ke belakang.

Saya tahu pertanyaan ini sudah berumur beberapa tahun, tetapi sekarang jqgrid mendukung pengguliran virtual:

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

tetapi dengan pagination dinonaktifkan

Saya sarankan sigma grid, sigma grid telah menyematkan fitur paging yang dapat mendukung jutaan baris. Dan juga, Anda mungkin perlu paging jarak jauh untuk melakukannya. lihat demo http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Lihatlah dGrid:

https://dgrid.io/

Saya setuju bahwa pengguna tidak akan pernah, pernah perlu melihat jutaan baris data sekaligus, tetapi dGrid dapat menampilkannya dengan cepat (satu layar penuh pada suatu waktu).

Jangan merebus lautan untuk membuat secangkir teh.