#r #shiny #read.csv
#r #блестящий #read.csv
Вопрос:
Каков оптимальный формат для этого плоского файла (и соответствующей функции для чтения этого файла), который минимизирует время чтения этого плоского файла в data.frame для приложения shiny в репозитории, содержащем один статический файл данных?
Например, предположим, что при запуске приложения shiny оно считывает .RDS , но предположим, что это занимает ~ 30 секунд, и мы хотим уменьшить это. Существуют ли какие-либо способы сохранения файла и использования функции, которые могут сэкономить время?
Вот что я уже знаю:
- Я читал несколько статей о сравнении скорости, но ни одна из них, похоже, не содержит исчерпывающего сравнения всех методов в контексте блестящего приложения (и возможных последствий для ядер / потоков). Некоторые предлагают разумный совет, например, пытаться загружать меньше данных
- Я замечаю, что такие языки, как julia, иногда могут быть быстрее, но я не уверен, поможет ли чтение файла с использованием другого языка, поскольку его нужно будет преобразовать в объект, который распознает R, и, предположительно, этот процесс займет больше времени, чем просто чтение в качестве объекта R изначально
- Я заметил, что идентичные файлы кажутся меньше при сохранении по
.RDSсравнению с.csv, однако я не уверен, обязательно ли размер файла влияет на время чтения.
Комментарии:
1. Обычно
.rdsэто самый быстрый способ загрузки всех данных без «ленивой» загрузки частичных столбцов. Если вы знаете, что вам не нужны все столбцы, все строки сразу , тоfeatherформаты предполагают хорошую производительность.vroomпакет требует некоторых улучшений для файлов с разделителями, та же предпосылка.2. Из
?saveRDS: «сжатие: логическое указание, должно ли сохранение в именованный файл использовать"gzip"сжатие или одно из"gzip","bzip2"или"xz"указать тип используемого сжатия. Игнорируется, еслиfileэто соединение «.3. Конечно, поэтому удаление сжатия может помочь с некоторой скоростью, но формат RDS эффективен для работы с двоичными файлами, и R действительно хорошо справляется. Как правило, это нормально для большинства, но вам нужно будет выполнить некоторые тесты для ваших данных, чтобы определить, даст ли вам несжатое улучшение скорости.
4. Вероятно, актуально: data.nozav.org/post/2019-r-data-frame-benchmark и blog.dominodatalab.com/the-r-data-i-o-shootout . Если вам нравятся файлы, похожие на базы данных, рассмотрите SQLite или новичка
duckdb, который требует улучшения скорости.5. У меня была аналогичная проблема с блестящим приложением. В основном мне нужно было читать и сохранять фреймы и списки данных, когда пользователь использует приложение. Решение, которое сработало для меня: 1. .rds без какого-либо сжатия 2. Храните каждый файл отдельно самым примитивным способом, насколько это возможно. Подробнее о последнем. Я использую несколько фреймов данных в R6Class. Сначала я попытался сохранить весь экземпляр R6, но он занял много места. Затем я просто сохранил каждый фрейм данных как отдельный .rds, и он работал намного быстрее. Мне нужно было их разделить, чтобы они обновлялись и сохранялись в приложении.