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

Question

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

Answer 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 

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Таким образом, в конце концов, мы закончим с текстовым файлом 700MB против двоичного файла 335K (конечно двоичного гораздо быстрее 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 Мбайт/с, вы заметите разницу.

Итак, если вам действительно нужно иметь дело с real bigData (и повторяя миллион раз, то одна тысячная символьная строка - это не большие данные), когда двоичный дамп данных превышает 1 ГБ, вы оцените наличие хороший диск (SSD - хороший выбор) для чтения входных данных и записи результатов на диск.