Хранение одной длинной строки символов с минимальным использованием диска с помощью R

Question

Я хочу использовать R для хранения последовательности ДНК с минимальным использованием диска. Последовательность ДНК представляет собой очень длинную (обычно десятки миллионов символов) строку символов, состоящую из «A», «C», «G» и «T».

Предположим, что «abc.fa» - это текстовый файл на диске, содержащий 43 миллиона символов, я пробовал следующие различные подходы.

(1) Без использования R я использую команду Linux gzip для сжатия файла «abc.fa», а файл результата «abc.fa.gz» занял около 13 Мб дискового пространства.

(2) Используя Biostring пакет R.

dat <- readDNAStringSet("abc.fa") 
writeXStringSet(dat, file="abc.comp.fa", compress=TRUE) 

Выходной файл abc.comp.fa также занято около 13 Мб дискового пространства.

(3) Используя save функцию R для хранения последовательности в качестве character строки R.

dat <- readDNAStringSet("abc.fa") 
dat <- as.character(dat) 
save(dat, file="abc.chara.fa", compress="xz") 

выходного файла abc.chara.fa занимаемого около 9 Мб дискового пространства.

мне интересно, если есть более эффективные подходы к хранению этого рода последовательности с еще меньшим использованием диска в R.

Спасибо.

Answer 1

EDIT:

Я сделал некоторое исследование. Оба save и saveRDS поставляются с тремя различными алгоритмами сжатия, как вы уже знаете. Что для меня более интересным является аргумент compression_level, который поставляется с save. Это целое число от 1 до 9, по умолчанию установлено значение 6 для сжатия gzip и 9 для сжатия bzip2 или xz. saveRDS поставляется только со значениями по умолчанию для трех алгоритмов сжатия.

Более высокая степень сжатия имеет недостатки в времени считывания и записи. Ранее я предложил saveRDS, так как вам нужно сохранить один объект. В любом случае, если вас не интересует отзывчивость (поскольку объект данных довольно мал), я предлагаю вам протестировать три алгоритма с помощью compression_level = 9 и проверить, какой из них лучше подходит вашим потребностям.

EDIT 2:

Насколько я знаю, структура строки не должна влиять на размер объекта, но у меня есть гипотеза. Ваши данные имеют только четыре значения, а именно A, C, T, G. Данные часто хранятся и представлены в стандартном формате IEEE 754. Это позволяет гораздо более широкий диапазон представлений. На самом деле, вы должны быть в порядке с системой представления двух цифр, где 00, 01, 10, 11 способны обрабатывать ваши данные, сохраняя в противном случае неиспользуемое пространство. Вы должны проверить, как представлены ваши данные, и, в конечном счете, рассмотреть возможность преобразования.