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

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

НЛО прилетело и опубликовало эту надпись здесь
Некрасиво так делать: две минуты втыкал, как же это гугл без дополнительных параметров сразу редиректит на один из результатов поиска
НЛО прилетело и опубликовало эту надпись здесь
Может объясните, как?)
Никак: гугл не редиректит
Ааа, все, понял
«Глупо отвечать на вопрос, который вы не понимаете. Грустно стремиться к цели, которую вы не желаете достичь.»

Дык, это ж про любого политика. То, что для одних глупо, для других — суть их работы

аффтор вероятно студент и делает первые шаги в индустрии. студент так и не понял что популярность бигдата стека не от размера данных, а от бесплатности. те кто внедряют хорошо понимают что они не гугл. они внедряют хадупы в первую очередь, что бы не платить миллионы за лицензии. они не гугл, они просто считают деньги.
постгрес бесплатный
платный. как минимум та вариация (greenplum), которая хоть как то соревнуется с хадупами и мап-редюсами.
а обычный постгрес совсем под аналитику не подходит. там нет колончатых структур и мусор в таблицах раздувает файлы данных. и партишенинг лишь в пг10 обещают завести, то что там есть пародия, не партишенинг.
> партишенинг лишь в пг10 обещают завести
Как вам там из 2010 года пишется?

Всё остальное поддержу. К счастью, сейчас есть ClickHouse.
Если верить Википедии, «В 2015 году исходный код СУБД Greenplum выпущен под свободной лицензией».

Ещё Citus есть, и он тоже открыт.
Вот как раз по моему опыту студенты очень легко поддаются хайпу на технологии, ибо собственного критического опыта пока еще не хватает, зато энтузиазм так и прет, и очень хочется добавить красивые строчки к своему пока полупустому резюме.
Ну, вы не совсем правы точно. Хотя то что написано в посте про хадуп, с моей точки зрения тоже так себе формулировочки.

Во-первых, насчет бесплатности. Владение хадупом очень даже платно. У нас скажем CDH, и он не бесплатный, и включает поддержку. Возможно по сравнению с аналогичным ораклом тут и есть какая-то экономия, но весьма не очевидная. Не говоря уже о том, что ресурсы железа хадуп вполне себе потребляет, и масштабируется неплохо, поэтому машинки с терабайтом памяти в кластере на сегодня уже вполне типичны (и недешевы). Ну и своя поддержка тоже нужна.

Во-вторых, упоминание отказоустойчивости и MapReduce. Вот уж для чего хадуп точно не ставят — так это ради отказоустойчивости. Максимум чего от него стоит ждать — обеспечения _некоторой_ отказоустойчивости на «обычном» железе.

Дальше, сам MapReduce. Уже давно, на момент написания оригинала точно, в мире почти не пишут на чистом MapReduce. Это не значит, что таких нет, я сам писал — ровно одно приложение. Ну хорошо — одно писал, и одно использовал, компилировал и т.п. Но в среднем доля MapReduce быстро стремится к нулю, замещаясь спарком, включая сюда и Python, Hive, и так далее. И этот стек — он не просто сопоставим с любым другим (PL/SQL условно), он зачастую лучше. Он более открыт, гибок, и при этом производителен (при правильной настройке).

Ну и все остальное, по мелочи… Автор похоже не понимает, что компаний, у которых данных завались, на самом деле очень много. Все сотовые операторы с их биллингом, все банки с их карточным процессингом — это генераторы приличных потоков. Сколько нужно данных, чтобы они перестали влезать в один диск? Хм. Я думаю одного дня достаточно, сколько там нынче на один шпиндель, терабайт 8?
я прав и это факт.
у нас CDH кластер на 600 cores и не платили ни копейки. денег там стоит исключительно супорт, мы супорт не брали. даже 200 ядер на оракле с rac, партишенингом, компрессией, датагвардом это миллионы баксов только лицензий. + еще супорт.
отказоустойчивость в хадупе бай дизайн. вылет любой ноды — штатная ситуация, есть понятие rack awareness. в оракле же rac не отменяет обязанности иметь датагвард, что скорее костыль.
map-reduce, да отходит, но у нас еще вовсю применяется главным образом из-за дубовости и надежности. если у канторы суровые SLA, быстрый спарк с его 100500 нюансов на тему поломанных кешей, меняющимися планами и кастрацией от клоудеры бывает не самый лучший выбор. в map-reduce нечему ломаться и время исполнения много проще предсказать.
Я не говорил, что вы не сэкономите по сравнению с ораклом. Я говорю, что это нужно считать. Вас устраивает без поддержки? Ну так у вас и кластер маленький, и вероятно один.

И вот не надо мне рассказывать про отказоустойчивость — вылет namenodes вполне обычное явление, и оно зачастую НЕ выживает после такого. У хадупа еще полно подобных точек отказа, если специально этим не озаботиться.
вы говорили, что владение хадупом «очень даже платно». надеюсь я доступно это опроверг. кластер по меркам оракла огромный, по меркам хадупа конечно не из больших, но повторюсь, мы не гугл, для нас все дело в тех миллионах, что не ушли на оракловые лицензии.
на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу. если мапер стартовал, то блоки данных у него локальны и от неймноды ничерта уже не нужно. лично я наблюдал много больше проблем при вылетах датанод. инфраструктуру передали кому то внешнему и теперь у нас это не такая уж редкость когда целиком мап-редюс джоб фейлится и у ярна не выходит рестартануть. но к отказу и это не приводит, опять же во многом из-за того что у хадупа файлики имутабл бай дизайн. такие джобы рестартит наш шедулер и никто никогда особо даже такие инциденты на хадупе не замечает. лично у нас устойчивость системы выросла многократно. rac бы сравнимых издевательств не пережил бы однозначно. ни за какие деньги.

а на счет кол-ва у нас еще полно микрокластеров под игрушки, плюс у каждого девелопера все компоненты апликухи в докерах. от куду и импалы, до того самого спарка. на фоне оракла мягко говоря другой уровень. и снова в первую очередь не от того что оракл не могёт в докерах-шмокерах, а лицензионный бред и бабло.
Повторюсь, я и не говорил что оно дороже оракла. Я говорил что оно не бесплатное само — и структура этих трат другая, так что нужно считать все равно, за какой-то период. Вы вот похоже почему-то свою работу по настройке кластера не считаете вообще, как будто ее и нет.

>на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу.

Хм. Рассказываю: вы запускаете задачу, длинную, на пару дней. Она в момент перед завершением собирается записать результат в файл, и в это время неймнода того… Ваша задача пытается повторить операцию несколько раз, и завершается с ошибкой. Очень даже незаметно, когда вы теряете работу за два дня.
я кластер не настраивал, этим занимается отдельные 1.5 человека. это вполне сравнимо с той командой DBA которые возились с десятком наверно инстансов относящихся к не OLTP задачам.
по неймноде я чуть ниже расписал. хадуп так не работает. zookeeper назначит главной одну из секондари неймнод и джоб ничего не заметит. даже в совсем трагической ситуации джоб не метиться как фейлед целиком, пометится лишь один из тасков редюсера. один из многих сотен. в худшем случае ярн рестартанет один-два редюсера.
HA для нейм нод без простоя (совсем без простоя все равно нет) давно завезли в хадуп?
у нас вылетала и главная неймнода и секондари. софту это хлопот вообще не доставляло. при файловере zookeeper просто назначает глвной другую неймноду и все. таски мап-редюс или спарка если стартанули, то им пофигу, если они пытаются стартануть прямо во время фаловера, ну пару раз фейлятся, ярн рестартанет.
но суть даже не в том что у хадупа все обложено всякими HA, зукиперами и автоматами на рестарт, а то что там вообще вся идеология строится на имутабл файликах. че-то там зафейливось — не трагедия. минут через 5 можно смело пробовать еще разок стартануть. в традиционных субд же такие фокусы не проходят.
Кто такой автор легко выяснить, если перейти по ссылке на оригинал или погуглить «Ozan Onay».
github.com/ozan
Этот?
Да, это он.
Скажем прямо, из его github совершенно не очевидно, знает ли он что-то о том, про что пишет. Впрочем, из моего тоже :)
Автор говорит — подумайте о своей задаче и выберите подходящий по всем параметрам вариант решения.
Не бывает лучшего инструмента вне контекста задачи.

Вся статья про логику, при чем здесь github?
Может его примеры неудовлетворительны, но с логикой не поспоришь.
Так я и не спорю с его (вполне очевидной и не новой) логикой. Мне лишь примеры активно не понравились.
НЛО прилетело и опубликовало эту надпись здесь
Использование излишне сложных инструментов, это одна сторона проблемы. Другая сторона — когда люди/компании пытаются «упросить» задачу путем её усложнения. Например используя фреймворки для статических вебсайтов или прокладки-генераторы запросов для работы с базами данных. Почему то некоторые считают, что язык и синтаксис фреймворка сильно легче, чем любой язык программирования, а выучить sql сложнее, чем разбираться с его интерпретатором.
Отдельным идиотизмом попахивает тенденция к оутсорсингу всего и вся. Одна транснациональная компания, производитель специализированного оборудования, купила решение для создания интерфейсов к софту для управления оборудованием. Для чего им нужен этот фреймворк? Для того, что бы любая секретарша или фрилансер или целая специализированная фирма могли им на коленке мышкой нарастягивать интерфейс за 5 копеек/пучек. Учитывая крайнюю консервативность среды этого софта и редкость релизов, необходимость в дополнительном модуле, который конечно устанавливается отдельно и кушает память и озу, крайне сомнительна. Зато эффективные менеджеры внедрили и освоили и будут экономить по рублю на лайоут. А то, что в релизах у пользователей висят левые строки в меню и разъезжаются панели — зато программисты освоили новый продукт и больше не думают над интерфейсами. Можно сокращать, если что.
Полезность ORM уже 100 раз обсудили, и давно все сошлись на мнении что если у вас не high-perf случай, то они прекрасно выполняют свою работу. Один язык, автогенерируемые миграции, защита от инъекций, красивый микс исполнения трансформаций на базе и на сервере. Плюсов море, из минусов — пониже перфоманс (часто сильно), и не всегда удобно когда нужно вклиниться с очень кастомным SQL (решаемо).

Про jekyll (github pages) я даже не знаю что вам сказать. Вы хотите чтобы на каждый запрос на статику проворачивалась машинерия рендерящая html? Даже если он не менялся год? Может вам в архитекторы?

Аутсорс — это бизнес решение. Ваша еденичная история — это безусловно повод чтобы сделать обобщение на всех, но возможно стоит посмотреть немного шире.
Из всех плюсов ORM я бы всё же только миграции отметил. Всё остальное решается ничуть не более сложнее, чем без ORM. В этом смысле Dapper мне ближе.

Читая обсуждения тут же на Хабре я совсем не уверен в "сошлись во мнении". Плюс к этому если у вас "не high-perf" то можно и без автомиграций обойтись. Тем более, если у вас "не high-perf" где стоимость оборудования не плюс минус лям, а гораздо меньшие суммы, нативно используя SQL можно сильно экономить.


Про оутсорс это может быть особенность американской среды, но тут это очень популярно у крупных компаний. До степени идиотизма, когда органично внутренние сервисы покупают у сторонних производителей тратя деньги на адаптацию и получая "универсальное" решение в разы сложнее в поддержке, безопасности, трудозатратнее при использовании и тп но зато любую секретаршу обучить можно.

ORM ORM-у рознь. Например, Eloquent очень сильно подставила тем, что вместо LEFT JOIN, она сначала сделала SELECT всех id(загрузив их в память процесса), а затем вставила другой большой SELECT WHERE [id] IN (… и здесь через запятую подставила более 2000+ всех id продаж). Со временем, отображение страницы замедлялось, пока БД не поругалась, что батька передаёт слишком много параметров в одном запросе.
Вместо одного красивого и быстрого запроса она сделала 2 больших, некрасивых, и по моему мнению хуже этого и придумать было невозможно запрос хуже.
Лечить пришлось глубоким изучением синтаксиса Eloquent, чтобы понять в каком же волшебном порядке нужно передавать параметры, чтобы на выходе получился желаемый быстрый SQL-запрос без лишних сущностей и подзапросов. Таким образом, ваш разработчик сначала учит ORM, потом учит SQL, потом доучивает ORM чтобы он был похож на SQL, потом плюётся и не понимает, зачем ему ORM, когда он уже знает SQL (который к тому же мало чем отличается от БД к БД).
Похоже на старые споры сторонников шаблонизаторов в PHP и тех кто считает, что сам PHP и так нормальный шаблонизатор.

Я что-то не понял аргумента против кафки. Кто в здравом уме будет руководствоваться идеей "эта штука слишком хороша для нас, поэтому давайте не будем её использовать"? Давайте тогда писать неэффективные sql запросы, индексы не создавать — у нас же не хайлоад, чего уж там.

В случае 100 событий в день можно не запариваться над установкой Кафки и логировать прямо в базу данных, например :)
Могу по своему опыту сказать, что таки да, лучше кафку для нехайлоада не использовать. Нюансов настройки на порядок больше, чем в РСУБД. Плюс они неочевидные. И проблема в том, что они вылезают даже для хеллоувордов в виде различных падений коннекшена по таймаутам, ребалансировкам.
Схема с двумя таблицами в СУБД — одна для данных, вторая для оффсетов, и поллинг раз в н секунд этого дела решит проблему большинства бизнесов, требующих очереди, и при этом одновременно даст ниже стоимость владения и отказоустойчивость из коробки в виде репликации и бекапов.
Вот это уже аргумент хороший, в отличии от приведенного в статье.
НЛО прилетело и опубликовало эту надпись здесь
И оно ведь работает и в обратную сторону. Использование хайповых технологий позволяет быстро набрать людей на рынке. И это тоже может быть осознанным решением — пожертвовать эффективностью и простотой рантайма ради хайринга.
НЛО прилетело и опубликовало эту надпись здесь
все верно, Resume Driven Development.

позиция разработчика по-честному: зачем отказываться от опыта использования крутой технологии, когда можно ещё и тренинг за счёт работодателя получить^^

я немедленно начну получать предложения о работе — т.е. моя рыночная ценность увеличивается

Мне кажется, описанные в статье примеры по умолчанию содержат предусловие о том, что разработчик хочет в первую очередь решить бизнес задачу оптимальным способом, а не поднять денег или качнуть скилл за счет работодателя/заказчика.
НЛО прилетело и опубликовало эту надпись здесь
Мда, столько слов и все мимо, приплели сюда и концлагерь и политику и еще черти чего. Все проще гораздо.
Правда жизни такова — разработчик будет стремиться «бизнес задачу оптимальным способом» только тогда, когда это ему выгодно

Я этого и не отрицал, разработчик за выполненную бизнес задачу может получить премию и еще есть моральное удовлетворение — когда твой продукт востребован, им пользуется много людей и у разработчика возникает чувство гордости. Я знаю человека, который работал даже когда перестали платить зарплату, но, правда, таких людей совсем мало.
А есть другой пример, разработчик срать хотел на то, зачем вообще продукт делается, но он читал про микросервисы недавно и ему интересно их попробовать. Дальше все просто, он говорит что без микросервисов ничего не получится. Наигравшись, либо увольняется, либо узнает о новой серебряной пуле и требует все переделать.
Вот тут, мне кажется, вы подошли к сути проблемы. Разработчики используют те или иные технологии не для оптимального решения задачи, а для себя. Для улучшения своего резюме или получения навыков. Ещё есть конечно довольно сильные комплексы и гипертрофированное чувство собственной важности feel like Google. Поэтому гвозди забиваются микроскопом. Ведь микроскоп — это круто
Чтобы выбрать оптимальное решение, нужно много и детально знать, чтобы было что сравнивать. Не все так много знают, поэтому предлагают либо что хорошо знают, либо хайп.
Сколько раз спорил с коллегами, в итоге все равно разтащили систему по микросервисам, оказалось что и них есть минусы, но колеги то были уволены, а разгребать пришлось мне.
Решение микросервисы/монолит (как и любое другое решение) должно соответствовать запросам и учитывать не только сложность реализации и внедрения, но и последующее обслуживание (не говоря уже об решении поставленых задач и стоимости). А самое главное: для каждого отдельного проекта решение будет своё.
Микросервисы это уже бич какой-то, это впаривают везде чуть ли ни как серебряную пулю. Пора уже антипаттерн заводить.
Опять же, надо исходить из задачи. Упираться рогами в монолит там, где всё говорит в пользу микросервисов тоже не вариант.
Ну да, первый комментарий к статье
хочется или нет — но ты «обязан» использовать те или иные технологии. Вся соль в том, что большинство «избыточных» технологий имеют богатую человеко-читаемую документацию, бэст практикс, саксес сторис и т.д… Они не просто существуют — их вам продают. Это как МММ, серьёзно.Так или иначе, как сказали выше, вы придете к тому, что нужно и резюме наполнять и работать с тем, с чем работают в вашей нише. Этот вектор диктуете не вы, а рынок, при чем рынок «больших дядей», поскольку разработчик будет стремится именно в к ним.
Когда-то мы перешли на k8s, clickhouse, ceph и кучу других умных слов и тэгов — что-то попробовать, что-то было реально необходимо — куда не глянь в лицо пихают истории успеха, сравнительные тесты и.т.д… Мы перешли везде, где только смогли достать и «раздробить». По факту мы перешли в точку невозврата. Бич проблемы в том что мы не гугл, но не по тем причинам что написал автор. Мы не гугл в том, что в свое время решили покрыть свои амбиции роста и нагрузки с запасом опираясь на то, что это используют все и это правильный путь использовать «современное» и проверенное большими компаниями, а в итоге имеем то, что не можем позволить перечеркнуть месяцы разработки и отказаться от всего к чему пришли, ведь мы получили результат, хоть и не во всем нас устраивающий.
Вы бы возможно получили похожий результат и на любых других технологиях. Если, условно, вместо хадупа выбрать greenplum, то вы окажетесь через год-другой в такой же позе, только с другими проблемами. Будет ли лучше или хуже — все равно зависит только от вас, а не от гугля.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории