प्रदर्शन को कम करने वाली बड़ी बाइनरी फ़ाइल

Question

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

तो, मैंने इस बड़ी बाइनरी फ़ाइल (> 100 एमबी) को छोटे (< 100 एमबी) में विभाजित करने का विचार किया। लेकिन ऐसा लगता है कि यह समाधान प्रदर्शन प्राप्त नहीं कर रहा है। तो, मैं बस सोच रहा था कि इस परिदृश्य को संभालने के लिए बेहतर दृष्टिकोण क्या हो सकता है?

यह आपके लिए इस पर टिप्पणी करने के लिए वास्तव में बहुत मददगार होगा।

धन्यवाद

Answer 1

हो सकता है कि आप के बजाय एक Sqlite डेटाबेस का उपयोग कर की कोशिश कर सकते।

Answer 2

यदि आपकी ऐप डीबी में माइग्रेट करने वाले डेटा अनुक्रमिक को पढ़ रही है तो प्रदर्शन बढ़ाने में मदद नहीं करेगा। यदि यादृच्छिक पहुंच का उपयोग किया जाता है तो आपको डेटा को डीबी में स्थानांतरित करने पर विचार करना चाहिए, खासकर यदि अलग-अलग सूचकांक का उपयोग किया जाता है। आपको यह जांचना चाहिए कि पर्याप्त संसाधन उपलब्ध हैं, अगर मेमोरी वर्चुअल मेमोरी प्रबंधन में पूरी तरह से लोड किया गया हो तो प्रदर्शन (स्वैपिंग, पेजिंग) पर असर हो सकता है। आपके ओएस सेटिंग के आधार पर फ़ाइल आईओ बफर के लिए एक सीमा तक पहुंचा जा सकता है। फ़ाइल सिस्टम स्वयं खंडित किया जा सकता है। एक उच्च गुणवत्ता वाले उत्तर प्राप्त करने के लिए आपको हार्डवेयर, ओएस, मेमोरी और फ़ाइल सिस्टम के बारे में जानकारी प्रदान करनी चाहिए। और जिस तरह से आपकी डेटा फ़ाइल का उपयोग किया जाता है। आप कर्नेल ट्यूनिंग इत्यादि के बारे में संकेत प्राप्त कर सकते हैं।

Answer 3

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

बेशक, अगर आपने इंडेक्सिंग के कुछ रूपों को लागू किया है तो आपने अपना खुद का डेटाबेस बनाने की सड़क शुरू कर दी है।

आपके आवेदन के बारे में और जानने के बिना यह विशिष्ट सलाह देने के लिए हमारे लिए दिक्कत होगी। शायद समाधान आरडीबीएमएस समाधान लागू करना होगा। संभवतः एक नोएसक्यूएल दृष्टिकोण बेहतर होगा। शायद आपको एक टेक्स्ट इंडेक्सिंग और पुनर्प्राप्ति इंजन की आवश्यकता है।

तो ...

कितनी बार आपके आवेदन रिकॉर्ड को पुनः प्राप्त करने की जरूरत है? यह कैसे तय करता है कि कौन से रिकॉर्ड प्राप्त करना है? खराब प्रदर्शन की आपकी परिभाषा क्या है? आपने (आपकी प्रोजेक्ट) डेटाबेस के बजाए फ्लैट फ़ाइलों का उपयोग करने का फैसला क्यों किया? हम किस तरह के रिकॉर्ड के बारे में बात कर रहे हैं?

Answer 4

सिस्टम की केवल एक झलक के साथ सटीक उत्तर प्रदान करना हमेशा मुश्किल होता है, लेकिन क्या आपने वास्तव में वास्तविक थ्रूपुट की जांच करने की कोशिश की है?

पहले समाधान के रूप में, मैं बस एक समर्पित डिस्क का उपयोग करने की सिफारिश करता हूं (इसलिए अन्य प्रक्रियाओं से कोई समवर्ती पढ़ने/लिखने की क्रिया नहीं होती है), और उस पर एक तेज़। इस तरह यह हार्डवेयर अपग्रेड की केवल कुछ लागत होगी, और हम सभी जानते हैं कि हार्डवेयर आमतौर पर सॉफ़्टवेयर सस्ता है;) आप थ्रूपुट को अधिकतम करने के लिए RAID नियंत्रक पर भी जा सकते हैं।

यदि आप अभी भी डिस्क थ्रूपुट द्वारा सीमित हैं, तो फ्लैश तकनीक का उपयोग करके वहां नई तकनीकें हैं: यूएसबी कुंजी (हालांकि यह बहुत पेशेवर प्रतीत नहीं हो सकती है) या "नया" सॉलिड स्टेट ड्राइव एक से अधिक थ्रूपुट प्रदान कर सकता है यांत्रिक डिस्क

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

• एक सॉकेट दृष्टिकोण: दूसरी उपयोगिता एक बंदरगाह पर सुन रही है और आप इसे वहां डेटा भेजते हैं। एक स्थानीय मशीन पर यह अपेक्षाकृत तेज़ है, और आप भी काम को समानांतर करते हैं, इसलिए यदि डेटा का आकार बढ़ता है, तो भी आप काफी जल्दी इलाज शुरू कर देंगे।
• एक मेमोरी मैपिंग दृष्टिकोण: लाइव मेमोरी में एक समर्पित क्षेत्र को लिखें और उस क्षेत्र से उपयोगिता को पढ़ें (Boost.Interprocess मदद कर सकता है, अन्य समाधान भी हैं)।

ध्यान दें कि अगर पढ़ा अनुक्रमिक है, तो मुझे इसे 'पाइप' दृष्टिकोण (अला यूनिक्स) को आजमाने के लिए और अधिक "प्राकृतिक" लगता है ताकि दोनों प्रक्रियाएं एक साथ निष्पादित हो जाएं। पारंपरिक पाइप में, डेटा डिस्क के बाद सभी को हिट नहीं कर सकता है।

एक शर्म की बात है, यह नहीं है कि भारी प्रसंस्करण शक्ति की इस उम्र में, हम अभी भी हमारी डिस्क आईओ के साथ संघर्ष कर रहे हैं?