आर/पायथन और एसएसडी का उपयोग कर डेटा विश्लेषण

Question

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

Answer 1

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

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

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

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

एक फर्जी डेटा फ्रेम का उपयोग कर एक समय प्रयोग, और एसएसडी डिस्क बनाम एक सामान्य डिस्क बनाम पाठ प्रारूप बनाम बाइनरी प्रारूप में पढ़ने और लिखना।

> tt <- 100 
> longtext <- paste(rep("dqsdgfmqslkfdjiehsmlsdfkjqsefr",1000),collapse="") 
> test <- data.frame(
+  X1=rep(letters,tt), 
+  X2=rep(1:26,tt), 
+  X3=rep(longtext,26*tt) 
+) 

> SSD <- "C:/Temp" # My ssd disk with my 2 operating systems on it. 
> normal <- "F:/Temp" # My normal disk, I use for data 

> # Write text 
> system.time(write.table(test,file=paste(SSD,"test.txt",sep="/"))) 
    user system elapsed 
    5.66 0.50 6.24 

> system.time(write.table(test,file=paste(normal,"test.txt",sep="/"))) 
    user system elapsed 
    5.68 0.39 6.08 

> # Write binary 
> system.time(save(test,file=paste(SSD,"test.RData",sep="/"))) 
    user system elapsed 
     0  0  0 

> system.time(save(test,file=paste(normal,"test.RData",sep="/"))) 
    user system elapsed 
     0  0  0 

> # Read text 
> system.time(read.table(file=paste(SSD,"test.txt",sep="/"),header=T)) 
    user system elapsed 
    8.57 0.05 8.61 

> system.time(read.table(file=paste(normal,"test.txt",sep="/"),header=T)) 
    user system elapsed 
    8.53 0.09 8.63 

> # Read binary 
> system.time(load(file=paste(SSD,"test.RData",sep="/"))) 
    user system elapsed 
     0  0  0 

> system.time(load(file=paste(normal,"test.RData",sep="/"))) 
    user system elapsed 
     0  0  0 

Answer 2

http://www.codinghorror.com/blog/2010/09/revisiting-solid-state-hard-drives.html एसएसडी पर एक अच्छा लेख है, टिप्पणियां अंतर्दृष्टि की बहुत सारी पेशकश करती हैं।

आपके द्वारा किए जा रहे विश्लेषण के प्रकार पर निर्भर करता है, चाहे वह सीपीयू बाध्य या आईओ बाध्य है। रिग्रेशन मॉडलिंग से निपटने वाला व्यक्तिगत अनुभव मुझे बताता है कि पूर्व में अक्सर मामला होता है, एसएसडी का अधिक उपयोग नहीं किया जाएगा।

संक्षेप में, सबसे पहले अपने आवेदन को प्रोफाइल करने के लिए सबसे अच्छा।

Answer 3

एसएसडी के लिए पढ़ने और लिखने का समय मानक 7200 आरपीएम डिस्क से काफी अधिक है (यह अभी भी 10k आरपीएम डिस्क के साथ लायक है, यह सुनिश्चित नहीं है कि यह 15k से अधिक में कितना सुधार है)। तो, हाँ, आपको डेटा पहुंच पर बहुत तेज समय मिलेगा।

प्रदर्शन सुधार निर्विवाद है। फिर, यह अर्थशास्त्र का सवाल है। 2 टीबी 7200 आरपीएम डिस्क $ 170 एक टुकड़ा हैं, और 100 जीबी एसएसडीएस की लागत $ 210 है। तो यदि आपके पास बहुत अधिक डेटा है, तो आप एक समस्या में भाग सकते हैं।

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

Answer 4

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

मैं दृढ़ता से आपको प्रोफाइल का सुझाव दूंगा पहले अपना कोड, और हार्डवेयर में निवेश करने से पहले आप कौन से सुधार प्राप्त कर सकते हैं यह देखने के लिए वैकल्पिक पुस्तकालयों (जैसे numpy) का उपयोग करने पर विचार करें।

Answer 5

क्षमा करें, लेकिन मैं @joris द्वारा सबसे ज्यादा रेट जवाब से सहमत नहीं है। यह सच है कि यदि आप उस कोड को चलाते हैं, तो बाइनरी संस्करण को लगभग शून्य समय लगता है। लेकिन ऐसा इसलिए है क्योंकि परीक्षण सेट अजीब है। बड़ी पंक्ति 'लांगटेक्स्ट' प्रत्येक पंक्ति के लिए समान है। आर में डेटा फ्रेम एक बार से अधिक (कारकों के माध्यम से) डुप्लिकेट मानों को स्टोर करने के लिए पर्याप्त स्मार्ट नहीं हैं।

तो अंत में हम 335K का एक बाइनरी फ़ाइल बनाम 700MB की एक पाठ फ़ाइल के साथ खत्म (बेशक द्विआधारी तेज हो गया है xD)

-rw-r--r-- 1 carlos carlos 335K Jun 4 08:46 test.RData 
-rw-rw-r-- 1 carlos carlos 745M Jun 4 08:46 test.txt 

लेकिन अगर हम यादृच्छिक डेटा

> longtext<-paste(sample(c(0:9, letters, LETTERS),1000*nchar('dqsdgfmqslkfdjiehsmlsdfkjqsefr'), replace=TRUE),collapse="") 
> test$X3<-rep(longtext,26*tt) 
> 
> system.time(write.table(test,file='test.txt')) 
    user system elapsed 
    2.119 0.476 4.723 
> system.time(save(test,file='test.RData')) 
    user system elapsed 
    0.229 0.879 3.069 

के साथ प्रयास करें

और फ़ाइलों है कि विभिन्न

-rw-r--r-- 1 carlos carlos 745M Jun 4 08:52 test.RData 
-rw-rw-r-- 1 carlos carlos 745M Jun 4 08:52 test.txt 

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

लेकिन हमेशा एक बिंदु है जहां डिस्क बाधा बन जाती है। मेरा परीक्षण एक शोध सर्वर में चलाया गया था जहां NAS समाधान के माध्यम से हमें 600 एमबी/एस से डिस्क पढ़ने/लिखने का समय मिलता है। यदि आप अपने लैपटॉप में ऐसा करते हैं, तो 50 एमबी/एस से अधिक जाना मुश्किल है, तो आप अंतर देखेंगे।

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