Comments 13
Долго думал — что за неизвестный продукт космической индустрии "Союз R".
require("RPostgreSQL")Обычно require рекомендуется использовать в функциях, т.к. в случае ошибки он выдает warning. Для загрузки пакета лучше использовать library один раз в начале.
Time <- res1[,c('t')]
City <- res1[,c('city')]Несовсем понятно зачем использовать функцию c() для создания вектора длиной… 1 элемент. Достаточно написать res1[, "t"] или даже res1$t.
Ну и про оператор присваивания. Их так-то 5 штук, и на месте <- спокойно можно использовать = (дело вкуса / соглашения). = необходим при вызове функций и передачи аргументов по имени.
dev.off(), кстати, тоже выполняет определенную функцию и в целом его вызов может не требоваться. Зависит от окружения в котором вы строите графики (например, IDE). dev.off() необходим для I/O, его можно скобинировать с tryCatch({ expr;}, finally = dev.off()) чтобы не оставить ваш "девайс" в подвешенном состоянии если во время построения графика что-то отвалится.
статья из разряда "ну совсем вводная" и конечно не про рекламу R ибо такую "бородатую" визуализацию на R нынче мало кто делает.
Больше интересно было бы про нагрузочное тестирование в этой связке, какие есть вилы/грабли при связке dbplyr+СУБД, какие есть возможности тюнинга для повышения эффективности работы этой связки.
Например недавно коллеги подбросили интересную ссылку по сравнению производительности связки одной колоночной аналитической СУБД как в классической связке (R+Server) так и СУБД развернутой внутри самой R-сессии (вообще огонь). Там к примеру есть сравнение как с (PL/R-naive) так и с (PL/R-tuned), вот про тюнинг было бы интересно почитать как описание личного опыта/эксперимента.
Если у Вас обработка данных разовая то порой проще выгрузить весь набор данных за период не фильтруя в БД, seq-scan дешевле (особенно на ssd).
Join это боль, лучше делать его на самом последнем этапе, и не в БД.
Если таблица в PostgreSQL разбита на партиции то лучше выгружать и обрабатывать данные по каждой партиции отдельно. Большая боль будет если одновременно нужно сделать join по нескольким партишированным таблицам.
Основной подход — выгрузить данные и обрабатывать их за пределами реляционной БД.
Статью можно рассматривать как первый шаг к дальнейшему погружению в R и/или статистическую обработку данных, особенно если у Вас уже есть PostgreSQL (или иная БД с ODBC).
Существует одна ошибка начинающих аналитиков — работая с R мы продолжаем мыслить в рамках терминов баз данных, писать SQL… и, по факту, тратить свое время не на исследование данных.
В R есть великолепный инструмент dplyr, который позволяет абстрагироваться от синтаксиса SQL и перейти непосредственно к обработке данных. Но dplyr не ограничивает Вас и позволяет исполнять «рукописные» запросы.
Когда нужны «рукописные» запросы? Здесь варианты, например — сложные join, ручная оптимизация, вызов табличных функций. Да, в этих случаев иногда стоимостный оптимизатор PostgreSQL справляется не блестяще, но не забываем у нас не OLAP БД.
Рекомендую к прочтению Why SQL is not for Analysis, but dplyr is (eng).
Союз R и PostgreSQL. Анализируем работу аэропортов, рассчитываем пенсии