L'analisi dei dati mediante R / python e SSD

Question

Qualcuno ha qualche esperienza con r / python con dati memorizzati in Solid State Drive. Se si sta facendo per lo più si legge, in teoria questo dovrebbe migliorare in modo significativo i tempi di caricamento di dati di grandi dimensioni. Voglio scoprire se questo è vero e se vale la pena investire in SSD per migliorare i tassi di IO dati applicazioni intensive.

Answer 1

I miei 2 centesimi: SSD paga solo fuori se le applicazioni sono memorizzati su di esso, non i dati. E anche allora solo se un sacco di accesso al disco è necessaria, come per un sistema operativo. Le persone hanno ragione a puntare a profiling. Posso dirvi senza farlo che quasi tutto il tempo di lettura va al trattamento, di non leggere sul disco.

Si paga molto di più per pensare al Formato dei dati, invece di cui è memorizzato. Un aumento di velocità nella lettura dei dati può essere ottenuto utilizzando le giuste applicazioni e il formato giusto. Come utilizzando il formato interno di R invece di armeggiare intorno con i file di testo. Fare che un punto esclamativo: mai continuare a armeggiare intorno con i file di testo. Vai binario se la velocità è quello che vi serve.

A causa del sovraccarico, che in genere non fare la differenza se si dispone di uno SSD o un disco normale per leggere i dati da. Ho sia, e utilizzare il disco normale per tutti i miei dati. Faccio juggle in giro grandi insiemi di dati a volte, e mai sperimentato un problema con esso. Fuori rotta, se devo andare davvero pesante, ho solo il lavoro sui nostri server.

Quindi potrebbe fare la differenza quando si parla concerti e giga di dati, ma anche allora dubito molto che l'accesso al disco è il fattore limitante. A meno che il continuo la lettura e la scrittura sul disco, ma poi direi che si dovrebbe iniziare a pensare di nuovo su cosa esattamente si sta facendo. Invece di spendere quei soldi su unità SDD, memoria aggiuntiva potrebbe essere l'opzione migliore. O semplicemente convincere il boss per ottenere un server di calcolo decente.

Un esperimento temporizzazione utilizzando un frame di dati fasullo, e la lettura e la scrittura in formato testo vs. formato binario su un disco SSD contro un disco normale.

> 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 / rivisitando-solid-state-hard-drives.html ha un buon articolo su SSD, i commenti di offrire un sacco di spunti.

Dipende dal tipo di analisi che si sta facendo, sia che si tratti di CPU destinata o IO legato. L'esperienza personale che fare con un modello di regressione mi dice che prima è più spesso il caso, gli SSD non sarebbero di grande utilità, allora.

In breve, meglio al profilo prima l'applicazione.

Answer 3

Scusate ma io sono d'accordo con risposta più votata da @joris. E 'vero che se si esegue il codice, versione binaria quasi prende a zero tempo per essere scritta. Ma questo è perché il set di prova è strano. Il columm grande 'longtext' è lo stesso per ogni riga. frame di dati in R sono abbastanza intelligenti non per memorizzare i valori duplicati più di una volta (tramite fattori).

Così, alla fine finiamo con un file di testo di 700MB rispetto a un file binario di 335K (Naturalmente binario è molto più veloce 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

Tuttavia, se proviamo con dati casuali

> 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 

e file non sono poi così diversi

-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

Come si vede, il tempo trascorso, non è la somma di utente + sistema ... in modo che il disco è il collo di bottiglia in entrambi i casi. Si memorizzazione binario sarà sempre più veloce dal momento che non c'è bisogno di includere e virgola, citazioni o il personale del genere, ma solo il dumping oggetto di memoria su disco.

, ma c'è sempre un punto in cui diventa disco di collo di bottiglia. Il mio test è stato eseguito in un server di ricerca in cui tramite soluzione NAS otteniamo disco lettura / scrittura volte sopra 600MB / s. Se fate lo stesso in un computer portatile, in cui è difficile andare oltre 50 MB / s, si noterà la differenza.

Quindi, se effettivamente ha a che fare con la vera bigData (e ripetizione di un milione di volte la stessa mille stringa di caratteri non è grande di dati), quando il dump binario dei dati è più di 1 GB, apprezzerete avere un buon disk (SSD è una buona scelta) per la lettura dei dati di input e scrivere i risultati su disco.

Answer 4

devo il suggerimento secondo Giovanni al profilo dell'applicazione. La mia esperienza è che non è i dati effettivi si legge che sono la parte lenta, è il sovraccarico di creare oggetti di programmazione per contenere i dati, gettando dalle stringhe, allocazione della memoria, ecc

vorrei vivamente di profilo il codice prima, e considerare l'utilizzo di librerie alternative (come NumPy) per vedere quali miglioramenti si può ottenere prima di investire in hardware.

Answer 5

I tempi di lettura e scrittura per le unità SSD sono significativamente superiori a standard di 7200 RPM dischi (è ancora la pena con un disco 10k RPM, non so quanto di un miglioramento è più di un 15k). Quindi, sì, si otterrebbe molto più veloce i tempi di accesso ai dati.

Il miglioramento delle prestazioni è innegabile. Poi, è una questione di economia. 2 TB 7200 RPM dischi sono $ 170 a pezzo, e 100GB SSD costano $ 210. Quindi, se avete un sacco di dati, si può incorrere in un problema.

Se andate a leggere / scrivere un sacco di dati, ottenere uno SSD. Se l'applicazione è la CPU, tuttavia, che ci si beneficiare molto di più di ottenere un processore migliore.