Говоря про индексы, я имел в виду не столько SQL, сколько отсутствие индексации data frame в dplyr. А это, при join больших data frame в dplyr, может оказаться очень печальным.
Рекурсию, естественно, на R можно реализовать. Но не запросом в dplyr.
Я не утверждал, что Ваша статья бесполезна. Легко представляю ситуации, когда использование dplyr даже в теле функции на PL/R совершенно оправдано и удобно.
Я только указал на то, что для манипуляции с большими объемами данных SQL все равно необходим. Да и не поможет dplyr, когда требуются подзапросы, рекурсии, оконные функции, транзакции, индексы, партиционирование, табличные функции, кластеризация и многое другое.
IMHO, бессмысленно сравнивать функционал SQL и R. Они решают, в общем случае, разные задачи. К слову, Ваш пример не слишком удачен, так как в PostgreSQL через MADLib любые манипуляции с массивами и матрицами реализуются просто и эффективно.
Я утверждал только, что совместное использование SQL и R в одном процессе с общей памятью, как происходит в PostgreSQL, позволяет в любой момент исходить из задачи не затрагивая архитектуру решения.
Исходя из того, что R может использоваться в качестве языка процедур и функций на PostgreSQL, не проще ли на этом и остановиться? Зато уж точно не потребуется все засасывать в оперативку и всегда есть выбор, чем удобней обработать данные — SQL или R.
Например, трехтерабайтная БД у меня бодро вертится на 256ГБ оперативки и при этом немало статистики и прогнозирования выполняется именно на R.
Само собой, при прототипировании удобней работать не с серверным R, не имеющим никакого интерактивного интерфейса, а с локальным. Но для продуктивной системы связка SQL+R выглядит привлекательней.
Индустрия во многие стороны двигается. Повышение потребности в литии, при ограниченности его запасов, в перспективе начнет влиять на стоимость. Скорее в будущем следует ожидать алюминий (алюминий-ионные аккумуляторы и воздушно-алюминиевые батареи). Плотность энергии в них существенно выше, а о запасах алюминия точно беспокоиться не стоит. Это самый распостраненный металл на планете.
Так что, есть обоснованные ожидания, что алюминий-ионные АКБ могут и заменить литий-ионные, и сравняться по цене с кислотно-свинцовыми.
Какая разница, если в документации указан рекомендуемый АКБ и он совсем не стартерный? Факт в том, что данное устройство не расчитано на использование стартерных АКБ.
Так Вам для каких целей потребовался UPS именно с литиевыми АКБ? Вам реально необходимы несколько тысяч циклов заряд-разряд? В описанном мной применении и сотни циклов хватит лет на 8-10. А дольше литий и не живет.
Вдвое больший срок службы АКБ, при цене в 10 раз выше?
Одно дело речь о накопителе энергии от ветрогенератора или солнечной батареи, который каждый день заряжается и глубоко разряжается. Причем, возможно, неоднократно. Тогда литий имеет явные преимущества перед свинцом. Другое дело — резервный источник питания на случай, когда раз в месяц электричество на несколько часов отрубят.
Я же нашел к нему инструкцию, где явно сказано, что он только инвертор и заряжать АКБ не умеет. Даже на вашем фото ни слова о входе ином, кроме 12 V DC.
Понятно, что в режиме ежедневного заряда с глубоким разрядом при работе от солнечных батарей или ветрогенератора — литий имеет явные преимущества перед свинцом. Но в качестве резервного источника питания литий точно не окупится.
Для зарядки литевых батарей нужен контроллер заряда и балансир для каждого элемента. Но цена литиевых батарей настолько выше кислотно-свинцовых, что не думаю, что есть смысл с этим связываться. Одно дело мобильный источник питания, где вес АКБ имеет огромное значение, а совсем другое — стационарный.
А так, ищите контроллер заряда лития для солнечных батарей с инвертором. На вход ему — обычный импульсный БП от сети.
Рекурсию, естественно, на R можно реализовать. Но не запросом в dplyr.
Но с вышеописанными платами по мощности его, конечно, не сравнить.
Я только указал на то, что для манипуляции с большими объемами данных SQL все равно необходим. Да и не поможет dplyr, когда требуются подзапросы, рекурсии, оконные функции, транзакции, индексы, партиционирование, табличные функции, кластеризация и многое другое.
Я утверждал только, что совместное использование SQL и R в одном процессе с общей памятью, как происходит в PostgreSQL, позволяет в любой момент исходить из задачи не затрагивая архитектуру решения.
Ограничьтесь, пожалуйста, просто ссылкой на сайт производителя, где этот факт будет явно озвучен.
И вижу там:
Например, трехтерабайтная БД у меня бодро вертится на 256ГБ оперативки и при этом немало статистики и прогнозирования выполняется именно на R.
Само собой, при прототипировании удобней работать не с серверным R, не имеющим никакого интерактивного интерфейса, а с локальным. Но для продуктивной системы связка SQL+R выглядит привлекательней.
Так что, есть обоснованные ожидания, что алюминий-ионные АКБ могут и заменить литий-ионные, и сравняться по цене с кислотно-свинцовыми.
Она AGM, а не стартерная. Значит стартерную он просто убьет своим зарядным устройством.
Одно дело речь о накопителе энергии от ветрогенератора или солнечной батареи, который каждый день заряжается и глубоко разряжается. Причем, возможно, неоднократно. Тогда литий имеет явные преимущества перед свинцом. Другое дело — резервный источник питания на случай, когда раз в месяц электричество на несколько часов отрубят.
Но цена отбивает всякое желание уходить от кислотно-свинцовых АКБ.
Понятно, что в режиме ежедневного заряда с глубоким разрядом при работе от солнечных батарей или ветрогенератора — литий имеет явные преимущества перед свинцом. Но в качестве резервного источника питания литий точно не окупится.
А так, ищите контроллер заряда лития для солнечных батарей с инвертором. На вход ему — обычный импульсный БП от сети.