जब आपका इनपुट गीगा/टेराबाइट आकार होता है तो क्या बदलता है?

Question

मैंने आज अपना पहला बच्चा कदम आज वास्तविक वैज्ञानिक कंप्यूटिंग में लिया जब मुझे डेटा सेट दिखाया गया था जहां 1600 पंक्तियों (क्रोमोसोम 22 के लिए कई लोगों के लिए हैप्लोटाइप) द्वारा छोटी फ़ाइल 48000 फ़ील्ड है। और यह छोटा माना जाता है।

मैं पाइथन लिखता हूं, इसलिए मैंने पिछले कुछ घंटों में एचडीएफ 5, और नम्पी और पायटेबल के बारे में पढ़ा है, लेकिन मुझे अभी भी लगता है कि मैं वास्तव में नहीं सोच रहा हूं कि टेराबाइट आकार का डेटा वास्तव में मेरे लिए क्या मतलब है एक प्रोग्रामर

उदाहरण के लिए, किसी ने इंगित किया कि बड़े डेटा सेट के साथ, पूरी चीज को मेमोरी में पढ़ना असंभव हो जाता है, न कि मशीन में अपर्याप्त रैम है, लेकिन क्योंकि आर्किटेक्चर में अपर्याप्त पता स्थान है! यह मेरे दिमाग उड़ा दिया।

कक्षा में मैं अन्य मान्यताओं का पालन कर रहा हूं जो इस इनपुट के साथ काम नहीं करते हैं? अलग-अलग तरीके से करने या सोचने के लिए मुझे किस तरह की चीजों की आवश्यकता है? (यह पाइथन विशिष्ट नहीं होना चाहिए।)

Answer 1

मैं वर्तमान में तेल उद्योग के एक छोटे से कोने में उच्च प्रदर्शन कंप्यूटिंग में व्यस्त हूं और नियमित रूप से उन परिमाण के आदेशों के डेटासेट के साथ काम करता हूं जिनके बारे में आप चिंतित हैं। यहां कुछ बिंदुओं पर विचार करने के लिए दिए गए हैं:

1. डेटाबेस में इस डोमेन में बहुत अधिक कर्षण नहीं है। लगभग सभी हमारे डेटा फ़ाइलों में रखा जाता है, उनमें से कुछ फ़ाइलें 70 के दशक में डिजाइन किए गए टेप फ़ाइल प्रारूपों पर आधारित होती हैं। मुझे लगता है कि डेटाबेस के गैर-उपयोग के कारण का हिस्सा ऐतिहासिक है; 10, यहां तक ​​कि 5 साल पहले मुझे लगता है कि ओरेकल और उसके रिश्तेदार ओ (टीबी) के एकल डेटासेट को प्रबंधित करने के काम पर नहीं थे, ऐसे डेटासेट के 1000s के डेटाबेस को अकेले छोड़ दें।

   एक अन्य कारण प्रभावी डेटाबेस विश्लेषण और डिजाइन और वैज्ञानिक डेटा सेट की प्रकृति के सामान्यीकरण नियमों के बीच एक वैचारिक विसंगति है।

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

   हालांकि, मैं अभी भी देख रहा हूं, वास्तव में, एचडीएफ 5 देख रहा हूं।इसमें मेरे लिए कुछ आकर्षण हैं (ए) यह सिर्फ एक और फ़ाइल प्रारूप है इसलिए मुझे अपनी जटिलताओं के साथ एक डीबीएमएस और कुश्ती स्थापित करने की आवश्यकता नहीं है, और (बी) सही हार्डवेयर के साथ मैं समानांतर में एचडीएफ 5 फाइल को पढ़/लिख सकता हूं । (हाँ, मुझे पता है कि मैं समानांतर में डेटाबेस पढ़ और लिख सकता हूं)।

2. जो मुझे दूसरे बिंदु पर ले जाता है: बहुत बड़े डेटासेट से निपटने पर आपको वास्तव में समांतर गणना का उपयोग करने की सोचने की आवश्यकता होती है। मैं ज्यादातर फोरट्रान में काम करता हूं, इसकी ताकत इसकी सरणी वाक्यविन्यास है जो बहुत से वैज्ञानिक कंप्यूटिंग पर बहुत अच्छी तरह से फिट बैठती है; दूसरा समानांतरता के लिए अच्छा समर्थन है। मेरा मानना ​​है कि पायथन में समानांतर समर्थन के सभी प्रकार हैं, इसलिए शायद यह आपके लिए खराब विकल्प नहीं है।

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

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

4. प्रदर्शन कार्यक्रमों के निष्पादन प्रदर्शन, और डेवलपर प्रदर्शन दोनों के गंभीर तरीके से महत्वपूर्ण है। ऐसा नहीं है कि 1TB डेटासेट को 1 जीबी डेटासेट के रूप में 10 गुना अधिक कोड की आवश्यकता होती है, इसलिए आपको तेजी से काम करना होगा, यह है कि कुछ विचार जो आपको लागू करने की आवश्यकता होगी, वे पागल जटिल होंगे, और शायद डोमेन विशेषज्ञों द्वारा लिखे जाने चाहिए, यानी वैज्ञानिक जिनके साथ आप काम कर रहे हैं। यहां डोमेन विशेषज्ञ Matlab में लिखते हैं।

लेकिन यह बहुत लंबा हो रहा है, मैं बेहतर काम करने के

Answer 2

जबकि कुछ भाषाओं में दूसरों के मुकाबले स्वाभाविक रूप से स्मृति प्रकार ओवरहेड कम है, वास्तव में इस आकार के डेटा के लिए कोई फर्क नहीं पड़ता - आप अपना पूरा डेटा सेट नहीं रखते हैं आप जिस भाषा का उपयोग कर रहे हैं उसकी परवाह किए बिना स्मृति में, इसलिए पाइथन का "व्यय" यहां अप्रासंगिक है। जैसा कि आपने बताया है, इस डेटा को संदर्भित करने के लिए बस पर्याप्त पता स्थान नहीं है, अकेले इसे पकड़ने दें।

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

Answer 3

संक्षेप में, मुख्य अंतर IMO वापस पाने चाहते हैं:

1. आप पहले से क्या आपके संभावना पता होना चाहिए बाधा (I/O या CPU) होगी और इसे हल करने के लिए सर्वोत्तम एल्गोरिदम और आधारभूत संरचना पर ध्यान केंद्रित करें। I/O अक्सर बाधा है।
2. एल्गोरिदम का विकल्प और ठीक-ट्यूनिंग अक्सर किसी अन्य विकल्प पर हावी होती है।
3. एल्गोरिदम और एक्सेस पैटर्न में भी मामूली परिवर्तन परिमाण के आदेश द्वारा प्रदर्शन को प्रभावित कर सकते हैं। आप बहुत अनुकूलन करेंगे। "सर्वश्रेष्ठ" समाधान सिस्टम-निर्भर होगा।
4. अपने सहकर्मियों और अन्य वैज्ञानिकों से इन डेटा सेट के साथ अपने अनुभवों से लाभ प्राप्त करने के लिए बात करें। पाठ्यपुस्तकों में बहुत सी चालें नहीं मिल सकती हैं।
5. प्री-कंप्यूटिंग और स्टोरिंग बेहद सफल हो सकती है।

बैंडविड्थ और मैं/हे

प्रारंभ में, बैंडविड्थ और मैं/हे अक्सर अड़चन है। आपको एक परिप्रेक्ष्य देने के लिए: SATA 3 के सैद्धांतिक सीमा पर, 1 टीबी पढ़ने में लगभग 30 मिनट लगते हैं। यदि आपको यादृच्छिक पहुंच की आवश्यकता है, तो कई बार पढ़ें या लिखें, आप इसे ज्यादातर समय मेमोरी में करना चाहते हैं या कुछ तेज़ी से तेज करना चाहते हैं (उदा।iSCSIInfiniBand के साथ)। आप जिस भी इंटरफ़ेस का उपयोग कर रहे हैं, सैद्धांतिक सीमा के करीब जितना संभव हो सके, अपने सिस्टम को आदर्श रूप से parallel I/O करने में सक्षम होना चाहिए। उदाहरण के लिए, MPI-2 I/O के शीर्ष पर विभिन्न प्रक्रियाओं में समानांतर में अलग-अलग फ़ाइलों को एक्सेस करना, या HDF5 बहुत आम है। आदर्श रूप से, आप समानांतर में गणना और I/O भी करते हैं ताकि दोनों में से एक "मुक्त" हो।

क्लस्टर

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

एल्गोरिदम

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

कंप्यूटर, भाषा, विशेष उपकरणों

अपने टोंटी है मैं/हे, इसका मतलब है कि बड़े डेटा सेट के लिए एल्गोरिदम अधिक मुख्य स्मृति (जैसे 64 बिट) या प्रोग्रामिंग भाषाओं/डाटा संरचनाओं के साथ से लाभ उठा सकते कम स्मृति खपत (उदाहरण के लिए, पायथन __slots__ में उपयोगी हो सकता है), क्योंकि अधिक मेमोरी का मतलब प्रति CPU समय कम I/O हो सकता है। बीटीडब्ल्यू, मुख्य स्मृति के टीबी के साथ सिस्टम की अनदेखी नहीं की जाती है (उदा। HP Superdomes)।

इसी प्रकार, यदि आपके टोंटी सीपीयू, तेजी से मशीन, भाषाओं और compilers है कि आप एक वास्तुकला का विशेष सुविधाओं का उपयोग करने की अनुमति है (उदाहरण के लिए SIMDSSE) की तरह प्रदर्शन परिमाण के एक आदेश से बढ़ सकता है।

डेटा खोजने और एक्सेस करने का तरीका, और मेटा जानकारी स्टोर करने के लिए प्रदर्शन के लिए बहुत महत्वपूर्ण हो सकता है। डेटा को संग्रहीत करने के लिए आप अक्सर फ्लैट फ़ाइलों या डोमेन-विशिष्ट गैर मानक पैकेज का उपयोग करेंगे (उदा। सीधे एक रिलेशनल डीबी नहीं) जो आपको डेटा को अधिक कुशलता से एक्सेस करने में सक्षम बनाता है। उदाहरण के लिए, kdb+ बड़ी समय श्रृंखला के लिए एक विशेष डेटाबेस है, और ROOT कुशलता से डेटा तक पहुंचने के लिए TTree ऑब्जेक्ट का उपयोग करता है। pyTables का उल्लेख आप एक और उदाहरण होगा।

Answer 4

मुख्य धारणाएं एक स्वीकार्य मूल्य पर एक मशीन में आपके पास सीपीयू/कैश/रैम/स्टोरेज/बैंडविड्थ की मात्रा के बारे में हैं। 4 जी रैम के साथ 32 बिट मशीन की पुरानी धारणाओं और भंडारण के टेराबाइट और 1 जीबी नेटवर्क के आधार पर स्टैक ओवरफ्लो पर अभी भी बहुत सारे उत्तर हैं। 220 यूरो, 1612 जीबी रैम पर 16 जीबी डीडीआर -3 रैम मॉड्यूल के साथ, 48 कोर मशीनों को उचित मूल्य पर बनाया जा सकता है। हार्ड डिस्क से एसएसडी में स्विच एक और महत्वपूर्ण बदलाव है।