जावास्क्रिप्ट टेबल सॉर्टिंग/पेजिंग (क्लाइंट-साइड)। कितना बड़ा बहुत बड़ा है?

Question

मैं अपने अनुप्रयोगों में से एक में लॉग टेबल की क्लाइंट-साइड सॉर्टिंग करने के लिए Tablesorter नामक एक jQuery प्लगइन का उपयोग कर रहा हूं। मैं tablepager ऐड-इन का भी उपयोग कर रहा हूं।

मुझे वास्तव में प्रतिक्रिया है कि क्लाइंट-साइड सॉर्टिंग और पेजिंग पार्टी में लाती है। मुझे यह भी पसंद है कि आपको बार-बार वेब सर्वर या डेटाबेस को हिट करने की आवश्यकता नहीं है।

हालांकि मैं देख सकता हूं कि, समय पर, जो लॉग मैं प्रदर्शित कर रहा हूं वह काफी बड़ा हो सकता है। मुझे यकीन है कि वहां एक बिंदु आता है जहां क्लाइंट-साइड पेजिंग और सॉर्टिंग अव्यवहारिक होने जा रही है। इस तकनीक को अपने वजन के नीचे किस बिंदु पर गिरना शुरू हो जाएगा? 500 रिकॉर्ड? 2000 रिकॉर्ड? 10,000 रिकॉर्ड?

संपादित करें: संक्षेप में, आप सर्वर-साइड पेजिंग के विपरीत क्लाइंट-साइड सॉर्टिंग/पेजिंग का उपयोग करने जा रहे हैं या नहीं, यह निर्धारित करने के लिए आप किन मापदंडों का उपयोग करेंगे? क्या अपेक्षित परिणाम का आकार आपके निर्णय में कारक निर्धारित करता है? टिपिंग प्वाइंट कहां है?

Answer 1

हालांकि मैं देख सकता हूँ कि, समय के साथ लॉग मैं प्रदर्शित कर रहा हूँ काफी बड़े हो जाना सकता है। मुझे यकीन है कि एक बिंदु आता है जहां क्लाइंट-साइड पेजिंग और सॉर्टिंग अव्यवहारिक होने जा रहा है। क्या बिंदु क्या यह तकनीक को अपने वजन के नीचे पतन शुरू कर देगी? 500 रिकॉर्ड? 2000 रिकॉर्ड? 10,000 रिकॉर्ड?

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

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

Answer 2

यह तकनीक शायद तब गिर जाएगी जब ब्राउज़र या क्लाइंट होस्ट इसे नहीं ले सकता है।

इसे रोकने के लिए सर्वर-साइड पेजिनेशन का उपयोग करें।

मैं पहले क्लाइंट को जो डेटा भेज रहा हूं, उस पर विचार करता हूं, जो बदले में लोडिंग टाइम कारक का कारण बनता है।

कहें कि तालिका की प्रत्येक पंक्ति 200 बाइट्स है, और मैं क्लाइंट को 10000 पंक्तियां भेज रहा हूं (जो क्लाइंट सॉर्टिंग और पेजिनेशन की अनुमति देता है), मैं 200 * 10000 = 2,000,000 बाइट्स, उर्फ ​​2 एमबी भेज रहा हूं। यह ब्राउजर को सर्वर से लोड करने में काफी समय लगेगा, फिर कुछ समय सॉर्ट करने के लिए सॉर्टिंग प्लगइन के लिए कुछ समय, पेज पेज पर पेजिंग करने के लिए कुछ समय लगेगा।

वास्तव में, आप सर्वर लोड सभी क्लाइंट को भेजने की आवश्यकता के साथ बढ़ेगा।

आम तौर पर जावास्क्रिप्ट को संभालने के लिए इतना डेटा और पुनरावृत्ति के साथ, ब्राउज़र (फ़ायरफ़ॉक्स या इसी तरह) लॉक हो जाएगा और ऐसा लगता है कि यह क्रैश हो रहा है।

यदि आप सर्वर साइड सॉर्टिंग + पेजिनेशन का उपयोग करते हैं, तो क्लाइंट सटीक और अद्यतित जानकारी देखता है। यह भी कहें कि आपके पास 20000 पंक्तियां हैं, प्रत्येक 200 बाइट्स। आपके पास प्रति पृष्ठ 20 पंक्तियां हैं। आप केवल 20 * 200 = 4000 बाइट भेज रहे हैं, जो कि 4 केबी है, अपेक्षाकृत छोटा है और ब्राउज़र/सर्वर द्वारा संभाला जा सकता है।

Answer 3

कॉलम की संख्या के आधार पर कुछ सौ शायद ठीक है। जब आप 10^3 (हजारों) के आदेश पर डेटा से निपट रहे हों तो यह निश्चित रूप से टूट जाएगा।

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