Анализ данных с использованием R/python и SSD

Ответ 1

Мои 2 цента: SSD только окупается, если ваши приложения хранятся на нем, а не ваши данные. И даже тогда, только если требуется большой доступ к диску, например, для ОС. Люди имеют право указать вам на профилирование. Я могу сказать вам, не делая этого, что почти все время чтения идет на обработку, а не на чтение на диске.

Оплачивается гораздо больше, чтобы думать о формате ваших данных вместо того, где он хранится. Ускорение чтения ваших данных можно получить, используя правильные приложения и правильный формат. Подобно использованию внутреннего формата R вместо того, чтобы возиться с текстовыми файлами. Сделайте восклицательный знак: никогда не дергайтесь с текстовыми файлами. Идите в двоичном формате, если скорость - это то, что вам нужно.

Из-за накладных расходов, как правило, не имеет значения, если у вас есть SSD или обычный диск для чтения ваших данных. У меня есть оба, и я использую обычный диск для всех моих данных. Иногда я иногда жонглирую вокруг больших наборов данных и никогда не сталкивался с проблемой. Конечно, если мне нужно очень тяжело, я просто работаю на наших серверах.

Таким образом, это может иметь значение, когда мы говорим о концертах и ​​концертах с данными, но даже тогда я очень сомневаюсь, что доступ к диску является ограничивающим фактором. Если вы не будете постоянно читать и писать на диск, но я бы сказал, вы должны снова подумать о том, что именно вы делаете. Вместо того, чтобы тратить эти деньги на диски SDD, дополнительная память может быть лучшим вариантом. Или просто убедите начальника, чтобы вы получили приличный расчетный сервер.

Эксперимент по синхронизации с использованием фальшивого фрейма данных и чтение и запись в текстовом формате по сравнению с двоичным форматом на диске SSD по сравнению с обычным диском.

> 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 

Ответ 2

http://www.codinghorror.com/blog/2010/09/revisiting-solid-state-hard-drives.html есть хорошая статья о SSD, комментарии предлагают много идей.

Зависит от типа анализа, который вы выполняете, независимо от того, связан ли он с процессором или привязана IO. Личный опыт, связанный с регрессионным моделированием, говорит о том, что бывший чаще всего случается, поэтому SSD не будут иметь большого значения.

Короче говоря, лучше сначала профилировать ваше приложение.

Ответ 3

Извините, но я должен не согласиться с наиболее рейтинговым ответом от @joris. Это правда, что если вы запустите этот код, бинарная версия почти забирает нулевое время для записи. Но это потому, что набор тестов странный. Большой длинный текст columm одинаковый для каждой строки. Кадры данных в R достаточно умны, чтобы не сохранять повторяющиеся значения более одного раза (через коэффициенты).

Итак, в конце мы заканчиваем текстовым файлом в 700 Мбайт по сравнению с двоичным файлом в 335 К (Конечно, двоичный файл намного быстрее 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 ГБ, вы оцените наличие хорошего диск (SSD - хороший выбор) для чтения входных данных и записи результатов на диск.

Ответ 4

Мне нужно второе предложение Джона, чтобы профилировать ваше приложение. Мой опыт в том, что это не фактические данные, которые являются медленной частью, это накладные расходы на создание объектов программирования для хранения данных, кастинг из строк, распределение памяти и т.д.

Я бы настоятельно предложил вам сначала профилировать свой код и подумать об использовании альтернативных библиотек (например, numpy), чтобы узнать, какие улучшения вы можете получить, прежде чем инвестировать в оборудование.

Ответ 5

Время чтения и записи для SSD значительно выше, чем стандартные диски с частотой 7200 об/мин (он по-прежнему стоит с диском 10 000 об/мин, а не уверен, насколько он улучшен до 15 тыс.). Итак, да, вы получите гораздо более быстрое время доступа к данным.

Совершенствование производительности неоспоримо. Тогда это вопрос экономики. Диски 2TB 7200 RPM составляют 170 долларов за штуку, а SSDR на 100 ГБ - 210 долларов. Поэтому, если у вас много данных, у вас может возникнуть проблема.

Если вы читаете/записываете много данных, получите SSD. Однако, если приложение имеет интенсивность процессора, вы получите гораздо больше преимуществ от получения лучшего процессора.