Как стать автором
Обновить

Комментарии 18

Не хватает пункта "Использую data.table".

Точно! :)
Ещё лучше (чтобы совсем неинтуитивный синтаксис data.table не зубрить) — dtplyr: data.table backend for dplyr
Исходя из того, что R может использоваться в качестве языка процедур и функций на PostgreSQL, не проще ли на этом и остановиться? Зато уж точно не потребуется все засасывать в оперативку и всегда есть выбор, чем удобней обработать данные — SQL или R.
Например, трехтерабайтная БД у меня бодро вертится на 256ГБ оперативки и при этом немало статистики и прогнозирования выполняется именно на R.

Само собой, при прототипировании удобней работать не с серверным R, не имеющим никакого интерактивного интерфейса, а с локальным. Но для продуктивной системы связка SQL+R выглядит привлекательней.

R гораздо богаче по функционалу чем SQL, например в SQL не особо удобно вращать таблицы из широкого формата в длинный и обратно.


По поводу ограничений по оперативке, есть пакеты которые это решают, к примеру есть dbplyr.


В общем надо из задачи исходить.

IMHO, бессмысленно сравнивать функционал SQL и R. Они решают, в общем случае, разные задачи. К слову, Ваш пример не слишком удачен, так как в PostgreSQL через MADLib любые манипуляции с массивами и матрицами реализуются просто и эффективно.

Я утверждал только, что совместное использование SQL и R в одном процессе с общей памятью, как происходит в PostgreSQL, позволяет в любой момент исходить из задачи не затрагивая архитектуру решения.

Цель этой статьи заключается в том, что бы тем кто знает SQL помочь сделать первые шаги в манипуляции данными в R, думаю в любом случае статья полезна.

Я не утверждал, что Ваша статья бесполезна. Легко представляю ситуации, когда использование dplyr даже в теле функции на PL/R совершенно оправдано и удобно.

Я только указал на то, что для манипуляции с большими объемами данных SQL все равно необходим. Да и не поможет dplyr, когда требуются подзапросы, рекурсии, оконные функции, транзакции, индексы, партиционирование, табличные функции, кластеризация и многое другое.
Ну некоторые задачи, именно с точки зрения обработки (та же рекурсия), на R можно решить. Индексы — конечно, это все-таки полуадминистраторская часть, тут без самого SQL не обойдешься.

Ну и 3 Тб данных обрабатывать это жестко в любом инструменте будет, здесь спору нет :)
Говоря про индексы, я имел в виду не столько SQL, сколько отсутствие индексации data frame в dplyr. А это, при join больших data frame в dplyr, может оказаться очень печальным.

Рекурсию, естественно, на R можно реализовать. Но не запросом в dplyr.

я часто использую пакет sqldf, работаю с датафреймами используя ситаксис SQL
Так мне не приходится учить синтаксис data.table или dplyr, ну и sql не забываю)

Не понял чем концепция Tidy Data отличается от первой нормальной формы таблиц и обычной excel таблички с колонками?

Таблицу в эксель (также как и в SQL) можно по-разному сделать. И иногда очень даже криво, и это не редкость :( А tidy data — концепция чистых данных, это касается всего, не только языка R. Просто в tidyverse все пакеты вокруг этого построены.

А можете привести пример "грязной" таблицы в SQL? Кроме того что в текстовых полях хранят даты/числа ничего на ум не приходит, но это так, легкая гигиена.

А вам никогда не попадались таблицы в которых например id через запятую в одной ячейке перечисленны?

Это уже не первая нормальная форма, и нет, в SQL базах я такого не встречал. Может, я слишком долго работаю в Enterprise среде, но для меня это не "грязные" таблицы, а жесткая дичь за которую увольняют

lol у нас это называлось постгре аррей. правда он бы строковый но щито поделать?

Содержимое полей JSON/XML встречал такие, что не меньше, чем с Excel, приходилось кувыркаться. А в текстовых полях встречал так называемые сцепки, когда из-за невозможности изменить структуру таблицы пропиретарного прикладного приложения, в одном поле несколько разных запихивают через разделитель. Жесть еще та.
Так что загадить можно и SQL таблицу.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории