javascript - लाखों पंक्तियों के लिए जावास्क्रिप्ट डेटा ग्रिड




jquery html5 (13)

( अस्वीकरण: मैं SlickGrid के लेखक हूँ )

अद्यतन अब यह SlickGrid में लागू किया SlickGrid

बड़ी संख्या में पंक्तियों के साथ SlickGrid काम करने पर चल रही चर्चा के लिए कृपया http://github.com/mleibman/SlickGrid/issues#issue/22 देखें।

समस्या यह है कि SlickGrid स्क्रॉलबार को वर्चुअलाइज नहीं करता है - स्क्रोल करने योग्य क्षेत्र की ऊंचाई सभी पंक्तियों की कुल ऊंचाई पर सेट होती है। चूंकि उपयोगकर्ता स्क्रॉल कर रहा है, पंक्तियों को अभी भी जोड़ा जा रहा है और हटा दिया जा रहा है, लेकिन स्क्रॉलिंग स्वयं ब्राउज़र द्वारा की जाती है। यह इसे बहुत तेजी से चिकनी होने की अनुमति देता है (ऑनस्कोल घटनाएं कुख्यात रूप से धीमी होती हैं)। चेतावनी यह है कि ब्राउज़र के सीएसएस इंजन में बग / सीमाएं हैं जो किसी तत्व की संभावित ऊंचाई को सीमित करती हैं। आईई के लिए, यह 0x123456 या 1193046 पिक्सल होता है। अन्य ब्राउज़रों के लिए यह अधिक है।

"मोटेन्यूम-फ़िक्स" शाखा में एक प्रयोगात्मक कार्यवाही है जो स्क्रॉल करने योग्य क्षेत्र को "पृष्ठों" के साथ 1 एम पिक्सल ऊंचाई पर सेट करके और फिर उन पृष्ठों के सापेक्ष स्थिति का उपयोग करके उस सीमा को महत्वपूर्ण रूप से बढ़ाती है। चूंकि सीएसएस इंजन में ऊंचाई सीमा वास्तविक लेआउट इंजन की तुलना में अलग और काफी कम दिखाई देती है, इससे हमें बहुत अधिक ऊपरी सीमा मिलती है।

मैं अभी भी प्रदर्शन किनारों को छोड़ दिए बिना पंक्तियों की असीमित संख्या प्राप्त करने का एक तरीका ढूंढ रहा हूं, जिसमें स्लिकग्रिड वर्तमान में अन्य कार्यान्वयनों पर निर्भर है।

रुडिगर, क्या आप इस बात का विस्तार कर सकते हैं कि आपने इसे कैसे हल किया?

https://code.i-harness.com

मुझे जावास्क्रिप्ट का उपयोग करके ग्रिड में उपयोगकर्ता की बड़ी संख्या में पंक्तियों (यानी लाखों पंक्तियां) प्रस्तुत करने की आवश्यकता है।

उपयोगकर्ता को पृष्ठों को नहीं देखना चाहिए या एक समय में केवल सीमित मात्रा में डेटा देखना चाहिए।

इसके बजाय, यह दिखाना चाहिए कि सभी डेटा उपलब्ध हैं।

डेटा को एक बार में डाउनलोड करने के बजाय, छोटे टुकड़े डाउनलोड होते हैं क्योंकि उपयोगकर्ता उनके पास आता है (यानी ग्रिड के माध्यम से स्क्रॉल करके)।

पंक्तियों को इस फ्रंट एंड के माध्यम से संपादित नहीं किया जाएगा, इसलिए केवल-पढ़ने वाले ग्रिड स्वीकार्य हैं।

जावास्क्रिप्ट में लिखे गए डेटा ग्रिड, इस तरह के निर्बाध पेजिंग के लिए मौजूद हैं?


(अस्वीकरण: मैं w2ui के लेखक हूँ)

मैंने हाल ही में 1 मिलियन रिकॉर्ड ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ) के साथ जावास्क्रिप्ट ग्रिड को कार्यान्वित करने के तरीके पर एक लेख लिखा है। मैंने पाया कि आखिरकार 3 प्रतिबंध हैं जो इसे उच्च करने से रोकते हैं:

  1. Div की ऊंचाई की सीमा है (वर्चुअल स्क्रॉलिंग से दूर किया जा सकता है)
  2. सॉर्ट और सर्च जैसे ऑपरेशंस 1 मिलियन रिकॉर्ड या उसके बाद धीमे होने लगते हैं
  3. राम सीमित है क्योंकि डेटा जावास्क्रिप्ट सरणी में संग्रहीत है

मैंने ग्रिड का परीक्षण 1 मिलियन रिकॉर्ड (आईई को छोड़कर) किया है और यह अच्छा प्रदर्शन करता है। डेमो और उदाहरणों के लिए आलेख देखें।


डीजीआईआर पर एक नज़र डालें:

http://dojofoundation.org/packages/dgrid/

मैं मानता हूं कि उपयोगकर्ताओं को कभी भी डेटा की लाखों पंक्तियों को देखने की आवश्यकता नहीं होगी, लेकिन डीजीआईआर उन्हें तुरंत प्रदर्शित कर सकता है (एक समय में एक स्क्रीनफुल)।

एक कप चाय बनाने के लिए सागर उबालें मत।


मुझे पता है कि यह एक पुराना सवाल है लेकिन अभी भी .. dhtmlxGrid भी है जो लाखों पंक्तियों को संभाल सकता है। 50,000 पंक्तियों वाला एक डेमो है लेकिन ग्रिड में लोड / संसाधित पंक्तियों की संख्या असीमित है।

अस्वीकरण: मैं डीएचटीएमएक्स टीम से हूं।


मेरा मतलब है कि लौ युद्ध शुरू करने का मतलब नहीं है, लेकिन मानते हैं कि आपके शोधकर्ता मानव हैं, आप उन्हें और साथ ही नहीं जानते हैं। सिर्फ इसलिए कि उनके पास डेटा के पेटबाइट्स हैं, उन्हें किसी भी सार्थक तरीके से लाखों रिकॉर्ड देखने में सक्षम नहीं हैं। वे कह सकते हैं कि वे लाखों रिकॉर्ड देखना चाहते हैं, लेकिन यह सिर्फ मूर्ख है। अपने सबसे अच्छे शोधकर्ताओं को कुछ बुनियादी गणित करें: मान लीजिए कि वे प्रत्येक रिकॉर्ड को 1 सेकंड देखते हैं। उस दर पर, इसमें 1000000 सेकंड लगेंगे, जो छः हफ्तों से अधिक समय तक काम करता है (40 घंटे के कार्य-सप्ताहों में भोजन या शौचालय के लिए कोई ब्रेक नहीं है)।

क्या वे (या आप) गंभीरता से सोचते हैं कि एक व्यक्ति (जो ग्रिड को देख रहा है) उस तरह की एकाग्रता को जरूरी कर सकता है? क्या वे वास्तव में उस 1 सेकंड में बहुत कुछ कर रहे हैं, या वे उन चीजों को फ़िल्टर कर रहे हैं जो अधिक नहीं चाहते हैं? मुझे संदेह है कि "उचित रूप से आकार" सबसेट देखने के बाद, वे आपको एक फ़िल्टर का वर्णन कर सकते हैं जो स्वचालित रूप से उन रिकॉर्ड्स को फ़िल्टर कर देगा।

चूंकि पक्सडीब्लो और स्लीपर स्मिथ और लास वी कार्ल्सन ने भी निहित किया, आप (और उन्होंने) आवश्यकताओं के माध्यम से नहीं सोचा है। ऊपर की ओर, अब आपको स्लिमग्रिड मिला है, मुझे यकीन है कि उन फ़िल्टरों की आवश्यकता तुरंत स्पष्ट हो गई है।



मैं ओपन रिको की अत्यधिक अनुशंसा करता हूं। शुरुआत में इसे लागू करना मुश्किल है, लेकिन एक बार जब आप इसे पकड़ लेंगे तो आप कभी वापस नहीं देखेंगे।


मैं बहुत अच्छी निश्चितता के साथ कह सकता हूं कि आपको गंभीरता से उपयोगकर्ता को डेटा की लाखों पंक्तियां दिखाने की आवश्यकता नहीं है।

दुनिया में ऐसा कोई उपयोगकर्ता नहीं है जो उस डेटा सेट को समझने या प्रबंधित करने में सक्षम होगा, भले ही आप तकनीकी रूप से इसे खींचने का प्रबंधन करते हैं, फिर भी आप उस उपयोगकर्ता के लिए किसी ज्ञात समस्या का समाधान नहीं करेंगे।

इसके बजाय मैं इस बात पर ध्यान केंद्रित करूंगा कि उपयोगकर्ता डेटा क्यों देखना चाहता है। उपयोगकर्ता डेटा देखने के लिए डेटा नहीं देखना चाहता है, आमतौर पर एक सवाल पूछा जा रहा है। यदि आप इसके बजाय उन सवालों के जवाब देने पर ध्यान केंद्रित करते हैं, तो आप किसी वास्तविक समस्या को हल करने वाले किसी चीज़ के बहुत करीब होंगे।



मैं सिग्मा ग्रिड का सुझाव देता हूं, सिग्मा ग्रिड में पेजिंग फीचर्स एम्बेड हैं जो लाखों पंक्तियों का समर्थन कर सकता है। और साथ ही, आपको इसे करने के लिए एक दूरस्थ पेजिंग की आवश्यकता हो सकती है। डेमो http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html


यहां कुछ ऑप्टिमाइज़ेशन दिए गए हैं जिन्हें आप लागू कर सकते हैं आप चीजों को तेज करते हैं। बस जोर से सोच रहा हूँ।

चूंकि पंक्तियों की संख्या लाखों में हो सकती है, इसलिए आप सर्वर से JSON डेटा के लिए कैशिंग सिस्टम चाहते हैं। मैं कल्पना नहीं कर सकता कि कोई भी सभी एक्स मिलियन आइटम डाउनलोड करना चाहता है, लेकिन अगर उन्होंने किया, तो यह एक समस्या होगी। 20 एम + पूर्णांक पर एक सरणी के लिए क्रोम पर यह छोटा परीक्षण लगातार मेरी मशीन पर दुर्घटनाग्रस्त हो जाता है।

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

आप LRU या कुछ अन्य कैशिंग एल्गोरिदम का उपयोग कर सकते हैं और इस पर ऊपरी सीमा है कि आप कितना डेटा कैश करना चाहते हैं।

तालिका कोशिकाओं के लिए, मुझे लगता है कि डीओएम नोड्स का निर्माण / नष्ट करना महंगा हो सकता है। इसके बजाय, आप केवल कोशिकाओं की एक्स संख्या को पूर्व-परिभाषित कर सकते हैं, और जब भी उपयोगकर्ता किसी नई स्थिति में स्क्रॉल करता है, तो इन कोशिकाओं में JSON डेटा इंजेक्ट करें। स्क्रॉलबार का पूरा प्रत्यक्ष संबंध नहीं होगा कि पूरे डेटासेट का प्रतिनिधित्व करने के लिए कितनी जगह (ऊंचाई) की आवश्यकता है। आप मनमाने ढंग से तालिका कंटेनर की ऊंचाई निर्धारित कर सकते हैं, 5000px कह सकते हैं, और पंक्तियों की कुल संख्या में नक्शा कर सकते हैं। उदाहरण के लिए, यदि कंटेनर ऊंचाई starting row ≈ (scroll.top/5000) * 10M है और कुल 10 एम पंक्तियां हैं, तो starting row ≈ (scroll.top/5000) * 10M जहां scroll.top कंटेनर के शीर्ष से स्क्रॉल दूरी का प्रतिनिधित्व करता है। यहां छोटे डेमो

अधिक डेटा का अनुरोध कब करें, यह पता लगाने के लिए, आदर्श रूप से किसी ऑब्जेक्ट को मध्यस्थ के रूप में कार्य करना चाहिए जो घटनाओं को स्क्रॉल करने के लिए सुनता है। यह ऑब्जेक्ट ट्रैक करता है कि उपयोगकर्ता कितनी तेज़ी से स्क्रॉल कर रहा है, और जब ऐसा लगता है कि उपयोगकर्ता धीमा हो रहा है या पूरी तरह से बंद हो गया है, तो संबंधित पंक्तियों के लिए डेटा अनुरोध करता है। इस फैशन में डेटा को पुनर्प्राप्त करने का अर्थ है कि आपका डेटा खंडित किया जा रहा है, इसलिए कैश को इसके साथ दिमाग में डिजाइन किया जाना चाहिए।

अधिकतम आउटगोइंग कनेक्शन पर ब्राउज़र सीमा भी एक महत्वपूर्ण भूमिका निभा सकती है। कोई उपयोगकर्ता किसी निश्चित स्थिति पर स्क्रॉल कर सकता है जो AJAX अनुरोध को आग लगाएगा, लेकिन इससे पहले कि उपयोगकर्ता कुछ अन्य भाग तक स्क्रॉल कर सके। यदि सर्वर पर्याप्त उत्तरदायी नहीं है तो अनुरोध कतारबद्ध हो जाएंगे और आवेदन अनुत्तरदायी दिखाई देगा। आप एक अनुरोध प्रबंधक का उपयोग कर सकते हैं जिसके माध्यम से सभी अनुरोधों को रूट किया जाता है, और यह स्थान बनाने के लिए लंबित अनुरोध रद्द कर सकता है।


स्क्रॉलिंग समाप्त होने से पहले प्रत्येक स्क्रॉल या कुछ सीमा के लिए जेसन प्रारूप में डेटा का हिस्सा लोड करके सबसे अच्छा तरीका मैं सोच सकता हूं। जेसन आसानी से वस्तुओं में परिवर्तित किया जा सकता है और इसलिए टेबल पंक्तियों को आसानी से अविभाज्य रूप से बनाया जा सकता है


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

" SlickGrid वर्चुअल प्रतिपादन का उपयोग करता है ताकि आप आसानी से प्रदर्शन में किसी भी बूंद के बिना सैकड़ों हजारों आइटमों के साथ काम कर सकें। असल में, 100 पंक्तियों के विरुद्ध 10 पंक्तियों के साथ ग्रिड के साथ काम करने के बीच प्रदर्शन में कोई अंतर नहीं है। "

कुछ हाइलाइट्स:

  • अनुकूली आभासी स्क्रॉलिंग (हजारों पंक्तियों को संभाल लें)
  • बेहद तेज प्रतिपादन गति
  • समृद्ध कोशिकाओं के लिए पृष्ठभूमि पोस्ट-रेंडरिंग
  • विन्यास योग्य और अनुकूलन योग्य
  • पूर्ण कीबोर्ड नेविगेशन
  • कॉलम का आकार बदलें / पुन: व्यवस्थित / दिखाएं / छुपाएं
  • कॉलम ऑटोोज़ाइजिंग और बल-फिट
  • प्लग करने योग्य सेल स्वरूपक और संपादक
  • नई पंक्तियों को संपादित करने और बनाने के लिए समर्थन। " mleibman द्वारा

यह मुफ़्त है (एमआईटी लाइसेंस)। यह jQuery का उपयोग करता है।








slickgrid