Comments 17
Очень удивился, когда увидел MongoDB в Hold. Можете рассказать, что пошло не так? Пожалуйста.
MongoDB у нас отлично живёт в WMS и там ей довольны, но в новые как-то оказывается логичней использовать что-то другое. Во всех наших проектах хватает возможностей сейчас от PostgreSQL, которая используется, как основная реляционная база + с её jsonb типом хранения. Там есть и поиск по таким полям, фильтрация, и базовые потребности nosql предоставляет :)
На примере нашей R&D команды, мы начинали недавно разработку одного проекта с mongodb в качестве бд, но когда получше разобрались в задаче и уточнили требования, поняли что она там не нужна и быстро заменили на postgres, чтобы лишний раз не раздувать стек. Я так думаю, в остальных командах похожая история.
Решая задачи с помощью R, мы поняли, что это язык не для высоконагруженных приложений. В новых задачах мы используем Python и другие технологии, которые с R несовместимы.
Если имеете в виду приложения с большим кол-вом одновременных обращений, то вы правы, R не для этого. Если речь об обработке больших объемов данных, то позволю себе поспорить – R может быть быстрее и эффективнее Python.
Предположу, что вы используете dplyr для обработки данных. Хэдли Викхэм сделал и продолжает делать очень много для развития R. dplyr и другие пакеты из tidyverse (или “hadleyverse”) очень полезны и сильно облегчают жизнь. Негативный эффект – люди думают, что все необходимые пакеты есть в tidyverse. Как результат, я уже несколько раз сталкивался с тем, что люди, имеющие опыт разработки и анализа данных в R, ничего не слышали про пакет data.table.
data.table — один из самых быстрых инструментов обработки данных в оперативной памяти одного сервера. Он написан на native C. Сравнение data.table с dplyr, pandas и spark sql можно посмотреть здесь. Скорость – это только половина преимущества data.table. Вторая половина – эффективное использование памяти.
Паша Стеценко из H2O.ai сейчас разрабатывает data.table для Python на основе пакета data.table для R. Но он сейчас только в стадии альфа. Презентацию можно посмотреть здесь.
Конечно, R и data.table подходят для обработки данных, только если данные влезают в оперативную память одного сервера (и data.table здесь очень эффективен и экономичен). Но это ограничение справедливо и для Python. При бОльших масштабах нужны уже кластерные решения – spark, flint и др. У spark есть api и для R и для Python.
Про data.table наши аналитики знают :) Но вообще с таким же весом можно говорить что питон медленный, но вот есть же numpy, или что и numpy надо уметь пользоваться.
R это отличный инструмент анализа данных, но он к сожалению создавался не разработчиками и не для разработчиков. Соответственно, разработанные аналитиками решения надо будет потом конвертировать в другие языки, да и инженеры не смогут помогать с оптимизацией. С питоном получается меньше переходов и проще совместная разработка. Ну и из личных наблюдений: я, конечно, не специалист по R, но редко вижу человека, который на нём может что-то писать вне Rstudio.
И да, у нас правда много данных и чаще всего на рабочем лаптопе они не влезут в память. Насколько мне известно, апи у спарка для питона не уступает родному для спарка scala api. Если уж и гнаться за скоростью, то тогда и топить сразу за scala.
Кстати! Раз вы хорошо знаете R и спарк, можете рассказать, можно ли доверять метрикам из вот этой публикации?
Как хабр не читаешь каждую неделю, что то обнаруживается взломанным, то, например, MongoDB лицензию меняет (для корпаративного использования плату взымает).
Вот если честно никогда этого не понимал, понахватать всего, а потом искать приключений…
Ни одного предложения про трудности, с которыми столкнулись, или про недостатки новых инструментов.
Везде получается «Мы модная компания и следим за модой».
Большинство из тех, кто здесь присутствуют, знает, что в целом дают указанные технологии.
Хочется историй «попробовали — не зашло, такие-то проблемы».
Или «Внедрили, но мешало то-то, решили так-то».
Впрочем, возможно это будет в новых статьях? )
В будущих статьях мы детальнее разберём наиболее интересные, на наш взгляд, технологии и как мы к ним пришли (и через что).
А про какие системы вам было бы интереснее всего прочитать?
Радар технологий: перечень языков, инструментов и платформ, которые прошли через руки Lamoda