Milyonlarca satır için JavaScript veri ızgarası [kapalı]

JavaScript kullanarak bir kullanıcıya veri satırları (yani milyonlarca satır) çok sayıda sunmanız gerekiyor.

Kullanıcı sayfaları görmemeli veya aynı anda yalnızca sınırlı miktarda veri görüntülememelidir.

Aksine, tüm verilerin mevcut olduğu görülmelidir.

Verileri bir kerede indirmek yerine, kullanıcı onlara geldiğinde küçük parçalar indirilir (ör. Izgarada ilerleyerek).

Satırlar bu kullanıcı arabiriminden düzenlenmeyecektir, bu nedenle salt okunur ızgaralar kabul edilebilir.

Bu tür kesintisiz sayfalama için JavaScript ile yazılmış hangi veri ızgaraları var?

( Feragatname: Ben SlickGrid'in yazarıyım )

GÜNCELLEME Bu artık SlickGrid'de uygulanmıştır .

SlickGrid'in daha fazla sayıda satırla çalışmasına ilişkin devam eden bir tartışma için lütfen http://github.com/mleibman/SlickGrid/issues#issue/22 adresine bakın .

Sorun, SlickGrid'in kaydırma çubuğunun kendisini sanallaştırmamasıdır - kaydırılabilir alanın yüksekliği, tüm satırların toplam yüksekliğine ayarlanmıştır. Kullanıcı kaydırırken satırlar hala eklenmekte ve kaldırılmaktadır, ancak kaydırmanın kendisi tarayıcı tarafından yapılmaktadır. Bu çok hızlı ve pürüzsüz olmasını sağlar (kaydırma olayları kötü bir şekilde yavaştır). Uyarı, tarayıcıların CSS motorlarında bir öğenin potansiyel yüksekliğini sınırlayan hatalar / sınırlamalar olmasıdır. IE için bu 0x123456 veya 1193046 piksel olur. Diğer tarayıcılar için daha yüksektir.

"Largenum-fix" dalında kaydırılabilir alanı 1M piksel yüksekliğine ayarlanmış "sayfalar" ile doldurarak ve daha sonra bu sayfalarda göreli konumlandırma kullanarak bu sınırı önemli ölçüde yükselten deneysel bir geçici çözüm vardır. CSS motorundaki yükseklik sınırı, gerçek düzen motorundan farklı ve önemli ölçüde daha düşük göründüğünden, bu bize çok daha yüksek bir üst sınır verir.

Hala SlickGrid'in şu anda diğer uygulamalar üzerinde tuttuğu performans avantajından vazgeçmeden sınırsız sayıda satıra ulaşmanın bir yolunu arıyorum.

Rudiger, bunu nasıl çözdüğünüzü açıklayabilir misiniz?

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

" SlickGrid, yüzbinlerce öğeyle performansta herhangi bir düşüş olmadan kolayca çalışabilmenizi sağlamak için sanal oluşturmayı kullanır. Aslında, 100 satırlık bir satırla 10 satırlı bir ızgarayla çalışma arasında performans farkı yoktur. "

Bazı önemli noktalar:

• Uyarlanabilir sanal kaydırma (yüz binlerce satırı ele alın)
• Son derece yüksek oluşturma hızı
• Daha zengin hücreler için arka plan post-rendering
• Yapılandırılabilir ve özelleştirilebilir
• Tam klavye gezintisi
• Sütun yeniden boyutlandırma / yeniden sıralama / göster / gizle
• Sütun otomatik boyutlandırma ve zorlama
• Takılabilir hücre biçimlendiricileri ve düzenleyicileri
• Yeni satırları düzenleme ve oluşturma desteği. " mleibman tarafından

Ücretsiz (MIT lisansı). JQuery kullanır.

Bence en iyi Izgaralar aşağıdadır:

• Flexigrid: http://flexigrid.info/
• jQuery Izgarası: 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
• Veri Tabloları http://www.datatables.net/index
• ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows

En iyi 3 seçeneğim jqGrid, jqxGrid ve DataTables. Binlerce satırla çalışabilir ve sanallaştırmayı destekleyebilirler.

Bir alev savaşı başlatmak istemiyorum, ama araştırmacılarınızın insan olduğunu varsayarsak, onları düşündüğünüz kadar iyi tanımıyorsunuzdur. Petabaytlarca veriye sahip olmaları , milyonlarca kaydı bile anlamlı bir şekilde görüntülemelerini sağlamaz. Milyonlarca kayıt görmek istediklerini söyleyebilirler , ama bu sadece aptalca. En akıllı araştırmacılarınıza bazı temel matematik yapmalarını sağlayın: Her kaydı görüntülemek için 1 saniye harcadıklarını varsayın. Bu oranda, altı haftadan fazla süren 1000000 saniye sürecektir (40 saat çalışma haftasından, yemek veya lavabo için mola vermeden).

Onlar (veya siz) ciddi olarak bir kişinin (şebekeye bakan kişinin) bu tür bir konsantrasyon toplayabileceğini mi düşünüyorlar? Bu 1 saniyede gerçekten çok şey yapıyorlar mı yoksa istemedikleri şeyleri filtreliyorlar mı (daha olası) ? "Makul boyutlu" bir alt kümeyi görüntüledikten sonra, bu kayıtları otomatik olarak filtreleyecek bir filtre tanımlayabileceklerinden şüpheleniyorum.

Paxdiablo ve Sleeper Smith ve Lasse V Karlsen'in de ima ettiği gibi, siz (ve onlar) gereksinimleri düşünmediniz. Yukarı tarafta, şimdi SlickGrid'i bulduğunuza göre, bu filtrelere olan ihtiyacın hemen belli oldu.

Kullanıcıya milyonlarca veri satırı göstermeniz gerekmediğini gayet iyi bir şekilde söyleyebilirim.

Dünyada bu veri kümesini anlayabilecek veya yönetebilecek bir kullanıcı yoktur, bu nedenle teknik olarak onu çıkarmayı başarabilirseniz bile, o kullanıcı için bilinen herhangi bir sorunu çözmezsiniz.

Bunun yerine , kullanıcının neden verileri görmek istediğine odaklanacağım . Kullanıcı sadece verileri görmek için verileri görmek istemez, genellikle bir soru sorulur. Bunun yerine bu soruları cevaplamaya odaklanırsanız, gerçek bir sorunu çözen bir şeye çok daha yakın olacaksınız.

Arabellekli Görünüm özelliğiyle Ext JS Izgarasını öneririm.

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

(Feragatname: w2ui'nin yazarıyım)

Geçenlerde 1 milyon kayıt içeren JavaScript ızgarasının nasıl uygulanacağı hakkında bir makale yazdım ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Nihayetinde daha yüksek almayı engelleyen 3 kısıtlama olduğunu keşfettim:

1. Div yüksekliğinin bir sınırı vardır (sanal kaydırma ile aşılabilir)
2. Sıralama ve arama gibi işlemler 1 milyon kayıttan sonra yavaşlamaya başlar
3. RAM sınırlı, çünkü veriler JavaScript dizisinde saklanıyor

Izgarayı (IE hariç) 1 milyon kayıtla test ettim ve iyi performans gösteriyor. Demolar ve örnekler için makaleye bakın.

dojox.grid.DataGrid veriler için bir JS soyutlama sunar, böylece sağlanan dojo.data mağazalarıyla çeşitli arka uçlara bağlayabilir veya kendiniz yazabilirsiniz. Açıkçası bu birçok kayıt için rastgele erişimi destekleyen bir taneye ihtiyacınız olacak. DataGrid ayrıca tam erişilebilirlik sağlar.

Düzenle böylece Matthew Russell'ın dojox.grid ile milyonlarca kayıt görüntüleyerek ihtiyacınız olan örneği vermesi gereken makalesine bir bağlantı . Kılavuzun eski sürümünü kullandığını, ancak kavramların aynı olduğunu, bazı uyumsuz API iyileştirmeleri olduğunu unutmayın.

Oh, ve tamamen ücretsiz bir açık kaynak.

JQuery Grid Plugin kullandım , güzeldi.

Demos

İşte size işleri hızlandırmak için uygulayabileceğiniz birkaç optimizasyon. Sadece yüksek sesle düşünmek.

Satır sayısı milyonlarca olabileceğinden, yalnızca sunucudaki JSON verileri için bir önbellek sistemi isteyeceksiniz. X milyonun tüm öğelerini indirmek isteyen kimseyi hayal edemiyorum, ama eğer yaparlarsa sorun olur. Chrome'da bu 20M + tamsayı dizisi için yapılan bu küçük test , makinemde sürekli çöküyor.

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

Sen kullanabilirsiniz LRU veya başka bir önbelleğe alma algoritması ve bir üst size cache istekli ne kadar veri bağlı bulunmaktadır.

Tablo hücrelerinin kendileri için, DOM düğümlerini oluşturmak / yok etmek pahalı olabilir. Bunun yerine, X sayısını hücre önceden tanımlayabilir ve kullanıcı yeni bir konuma her kaydırdığında JSON verilerini bu hücrelere enjekte edebilir. Kaydırma çubuğunun, tüm veri kümesini temsil etmek için ne kadar alan (yükseklik) gerektiği ile doğrudan bir ilişkisi yoktur. Tablo kabının yüksekliğini 5000 piksel gibi keyfi olarak ayarlayabilir ve toplam satır sayısına eşleyebilirsiniz. Örneğin, kapların yüksekliği 5000 piksel ise ve toplam 10 milyon satır varsa, starting row ≈ (scroll.top/5000) * 10Mburada scroll.topkap kabın üstünden kaydırma mesafesini temsil eder. Burada küçük demo .

Ne zaman daha fazla veri talep edileceğini saptamak için, ideal olarak bir nesne, olayları kaydırmayı dinleyen bir aracı olarak hareket etmelidir. Bu nesne, kullanıcının ne kadar hızlı kaydırdığını izler ve kullanıcı yavaşladığında veya tamamen durduğunda, ilgili satırlar için bir veri isteği yapar. Verileri bu şekilde almak, verilerinizin parçalanacağı anlamına gelir; bu nedenle önbellek, bu bilgileri göz önünde bulundurarak tasarlanmalıdır.

Ayrıca maksimum giden bağlantılardaki tarayıcı sınırları önemli bir rol oynayabilir. Bir kullanıcı bir AJAX isteğini tetikleyecek belirli bir konuma kayabilir, ancak bu işlem bitmeden önce başka bir bölüme geçebilir. Sunucu yeterince yanıt vermiyorsa, istekler sıraya alınır ve uygulama yanıt vermez. Tüm isteklerin yönlendirildiği bir istek yöneticisi kullanabilirsiniz ve alan açmak için bekleyen istekleri iptal edebilir.

Eski bir soru biliyorum ama yine de .. Ayrıca milyonlarca satır işleyebilir dhtmlxGrid vardır. 50.000 satır içeren bir demo var ancak ızgaraya yüklenebilen / işlenebilen satır sayısı sınırsız.

Feragatname: DHTMLX ekibindeyim.

Bunu okumanı öneririm

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

Yasal Uyarı: YUI DataTable'ı uzun süre baş ağrısı olmadan yoğun bir şekilde kullanıyorum . Güçlü ve kararlıdır. İhtiyaçlarınız, bir kullanabilirsiniz ScrollingDataTable wich suports

• X-kaydırma
• y-kaydırma
• xy kaydırma
• Güçlü bir Etkinlik mekanizması

İhtiyacınız olan şey için, bence bir tableScrollEvent . API'sı diyor

Sabit bir kaydırma DataTable'da bir kaydırma olduğunda kullanılır.

Her DataTable bir DataSource kullandığından , ScrollingDataTable'ınızı ihtiyaçlarınıza göre doldurmak için verilerini tableScrollEvent ile oluşturma döngüsü boyutu ile birlikte izleyebilirsiniz .

Oluşturma döngüsü boyutu diyor

DataTable'ınızın çok büyük bir veri kümesinin tamamını görüntülemesi gerektiğinde , renderLoopSize yapılandırması, UI iş parçacığının çok büyük tablolarda kilitlenmemesi için tarayıcı DOM oluşturmanın yönetilmesine yardımcı olabilir . 0'dan büyük herhangi bir değer, DOM döngüsünün her döngüde belirtilen sayıda satırı işleyen setTimeout () zincirlerinde yürütülmesine neden olur. Zor ve hızlı kurallar değil, yalnızca genel kurallar olmadığından uygulama başına ideal değer belirlenmelidir:

• Varsayılan olarak renderLoopSize 0'dır, böylece tüm satırlar tek bir döngüde işlenir. Bir renderLoopSize> 0 ek yük ekler, bu yüzden dikkatli kullanın.
• Veri kümeniz , kullanıcıların görsel oluşturmada gecikme yaşadıkları ve / veya komut dosyasının askıya alınmasına neden olacak kadar büyükse (satır sayısı X Sütun X sayısı biçimlendirme karmaşıklığı), bir renderLoopSize ayarlamayı düşünün .
• 50 yaşın altındaki bir renderLoopSize muhtemelen buna değmez. Bir renderLoopSize> 100 muhtemelen daha iyidir.
• Bir veri kümesi muhtemelen yüzlerce ve yüzlerce satır içermediği sürece yeterince büyük sayılmaz.
• RenderLoopSize> 0 ve <toplam satırlara sahip olmak, tablonun bir döngüde oluşturulmasına neden olur (renderLoopSize = 0 ile aynıdır), ancak oluşturma sonrası satır şeritleme gibi işlevin ayrı bir setTimeout iş parçacığından işlenmesini de tetikler.

Örneğin

// 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> yalnızca tek bir Veri Kaynağıdır . Bir JSON, JSFunction, XML ve hatta tek bir HTML öğesi olabilir

Burada benim tarafımdan sağlanan Basit bir öğretici görebilirsiniz. Unutmayın başka aynı anda DATA_TABLE pluglin destekler tek ve çift tıklama. YUI DataTable size izin verir. Ve dahası, baş ağrısı olmadan JQuery ile bile kullanabilirsiniz

Bazı örnekler görebilirsiniz.

• Liste öğesi

YUI DataTable hakkında istediğiniz başka bir şey hakkında soru sormaktan çekinmeyin.

Saygılarımızla,

Ben tür göremiyorum, jqGrid için sanal kaydırma işlevselliğini kullanabilirsiniz:

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

ancak daha sonra, filtreleme ile milyonlarca satır yapılabilir:

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

Gerçekten "sayfa yokmuş gibi" noktasını göremiyorum, yani ... tarayıcıda aynı anda 1.000.000 satır görüntülemenin bir yolu yok - bu 10MB ham HTML, göremiyorum neden kullanıcılar sayfaları görmek istemez?

Neyse ...

aklıma gelen en iyi yaklaşım, her kaydırma veya kaydırma bitmeden önce bazı sınırlama için veri yığınını json formatında yükleyerek. json kolayca nesnelere dönüştürülebilir ve bu nedenle tablo satırları göze batmadan kolayca yapılabilir

Açık rico tavsiye . Başlangıçta uygulamak zordur, ancak bir kez yakaladığınızda asla geriye bakmazsınız.

Bu sorunun birkaç yaşında olduğunu biliyorum, ancak jqgrid artık sanal kaydırmayı destekliyor:

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

ancak sayfalandırma devre dışı bırakıldığında

Sigma grid'i öneririm, sigma grid milyonlarca satırı destekleyebilecek sayfalama özellikleri içerir. Ayrıca, bunu yapmak için uzaktan sayfalamaya ihtiyacınız olabilir. demoya bakın http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

DGrid'e bir göz atın:

https://dgrid.io/

Kullanıcıların ASLA milyonlarca veri satırını aynı anda görüntülemesi gerektiğine katılıyorum, ancak dGrid bunları hızlı bir şekilde görüntüleyebilir (her seferinde ekranlı).

Bir fincan çay yapmak için okyanusu kaynatmayın.