Вы не Google

Автор оригинала: Oz Nova
  • Перевод


Разработчики сходят с ума от самых странных вещей. Мы все предпочитаем считать себя супер-рациональными существами, но когда дело доходит до выбора той или иной технологии, мы впадаем в некое подобие безумия, перескакивая от комментария на HackerNews к посту в каком-нибудь блоге, и вот уже будто в забытье, мы беспомощно плывем по направлению к самому яркому источнику света и покорно преклоняемся перед ним, абсолютно позабыв о том, что именно мы изначально искали.


Это совсем не так, как рациональные люди принимают решения. Но ровно так разработчики решают использовать, к примеру, MapReduce.


Как отметил Джо Хеллерштайн в своей лекции по базам данных для студентов-баклавров (на 54-й минуте):


Дело в том, что существует примерно 5 компаний в мире, которые выполняют настолько масштабные задачи. Что касается всех остальных… они тратят невероятные ресурсы, чтобы обеспечить отказоустойчивость системы, которая им на самом деле не нужна. У людей была своеобразная «гугломания» в 2000х: «мы будем делать всё точно так же, как делает Google, потому что мы ведь тоже управляем самым большим сервисом по обработке данных в мире…» [иронично покачивает головой и ждет смеха из зала]


Сколько этажей в здании вашего дата-центра? Google решили остановиться на четырех, по крайней мере, в этом конкретном дата-центре, расположенном в округе Мейс, Оклахома.


Да, ваша система более отказоустойчива, чем вам необходимо, но подумайте, чего это может стоить. Дело не только в необходимости обрабатывать большие объемы данных. Вероятно, вы размениваете полноценную систему — с транзакциями, индексами и оптимизацией запросов — на нечто относительно слабое. Это значительный шаг назад. Сколько пользователей Hadoop идут на это осознанно? Сколько из них принимают действительно взвешенное решение?


MapReduce/Hadoop — это весьма простой пример. Даже последователи «карго-культа» уже поняли, что самолеты не решат всех их проблем. Тем не менее, использование MapReduce позволяет сделать важное обобщение: если вы используете технологию, созданную для крупной корпорации, но при этом решаете небольшие задачи, возможно вы действуете необдуманно. Даже не так, наиболее вероятно, что вы руководствуетесь мистическими представлениями о том, что имитируя гигантов вроде Google и Amazon, вы достигните тех же вершин.



Да, эта статья — очередной противник «карго-культа». Но подождите, у меня для вас полезный чек-лист, который вы можете использовать, чтобы принимать более взвешенные решения.


Классный фреймворк: UNPHAT


В следующий раз, когда вы будете гуглить какую-нибудь новенькую крутую технику (ре)формирования вашей системы, я призываю вас остановиться и просто воспользоваться фреймворком UNPHAT:


  1. Даже не пытайтесь обдумывать возможные решения до того, как понять (Understand) проблему. Ваша основная цель — это «решить» проблему в терминах проблемы, а не в терминах решений.
  2. Перечислить (eNumerate) несколько возможных решений. Не нужно сразу же показывать пальцем на ваш любимый вариант.
  3. Рассмотрите отдельное решение, а потом прочитайте документацию (Paper), если таковая имеется.
  4. Определите исторический контекст (Historical context), в котором данное решение было создано.
  5. Сопоставьте достоинства (Advantages) с недостатками. Проанализируйте, чем авторам решения пришлось пожертвовать, чтобы достичь своей цели.
  6. Думайте(Think)! Трезво и спокойно обдумайте, насколько хорошо данное решение подходит для удовлетворения вашей потребности. Что именно должно измениться, чтобы вы передумали? Например, насколько меньший объем данных должен быть, чтобы вы предпочли не использовать Hadoop?

Вы не Amazon


Применять UNPHAT весьма просто. Вспомним мой недавний разговор с компанией, которая спешно решила использовать Cassandra для процесса интенсивного считывания данных, загружаемых по ночам.


Так как я уже был знаком с документацией по Dynamo и знал, что Cassandra является производной системой, я понимал, что в этих базах данных основной фокус направлен на возможность производить запись (в Amazon была потребность сделать так, чтобы действие «добавить в корзину» никогда не подводило). Я также оценил, что разработчики пожертвовали целостностью данных — да и, по сути, каждой фичей, присущей традиционным РСУБД. Но ведь у компании, с которой я общался, возможность производить запись не была в приоритете. Честно говоря, проектом подразумевалось создание одной большой записи в день.



Amazon продает очень много всего. Если бы функция «добавить в корзину» вдруг перестала работать, они потеряли бы ОЧЕНЬ МНОГО денег. А у вас проблема того же порядка?


Эта компания решила использовать Cassandra, потому что выполнение PostgreSQL запроса, о котором идет речь, занимало несколько минут, и они решили, что это технические ограничения со стороны их железа. После прояснения пары моментов мы поняли, что таблица состояла примерно из 50 миллионов строк по 80 байт. Её чтение с SSD заняло бы около 5 секунд, если бы требовалось пройтись по ней полностью. Это медленно, но это всё равно на два порядка быстрее, чем скорость выполнения запроса составляла на тот момент.


На данном этапе у меня было много вопросов (U = understand, понять проблему!) и я начал взвешивать около 5 различных стратегий, которые могли бы решить первоначальную проблему (N = eNumerate, перечислить несколько возможных решений!), но в любом случае к тому моменту уже было совершенно ясно, что использование Cassandra было в корне неверным решением. Всё, что им было необходимо – это немного терпения для настройки, вероятно, новый дизайн для базы данных и, возможно (хотя вряд ли), выбор другой технологии… Но совершенно точно не хранилище данных в формате «ключ-значение» с возможностью интенсивной записи, которое создали в Amazon для их корзины!


Вы не LinkedIn


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


Для сравнения вспомним, что Kafka создавался для обработки всех аналитических событий в LinkedIn. Это просто колоссальное количество данных. Даже пару лет назад это было порядка 1 триллиона событий ежедневно, с пиковой нагрузкой в 10 миллионов сообщений в секунду. Я, конечно, понимаю, что Kafka можно использовать для работы с более низкими нагрузками, но чтобы на 10 порядков меньше?



Солнце, будучи весьма массивным объектом, и то всего лишь на 6 порядков тяжелее Земли.


Может быть, разработчики даже приняли обдуманное решение, основываясь на ожидаемых потребностях и хорошем понимании назначения Kafka. Но я думаю, что они скорее подпитывались (как правило оправданным) энтузиазмом сообщества относительно Kafka и практически не задумывались, действительно ли это тот инструмент, который им был необходим. Вы только представьте… 10 порядков!


Я уже говорил? Вы не Amazon


Ещё более популярным, чем распределенное хранилище данных от Amazon, является архитектурный подход к разработке, который обеспечил им возможности масштабирования: сервисно-ориентированная архитектура. Как отметил Вернер Фогельс в этом интервью 2006 года, которое он давал Джиму Грею, в 2001 году в Amazon осознали, что они испытывают трудности с масштабированием интерфейса (фрон-энд части) и, что сервисно-ориентированная архитектура могла им помочь. Эта идея заражала одного разработчика за другим пока стартапы, состоящие из всего лишь пары разработчиков и практически не имеющие клиентов, не принялись дробить свой софт на наносервисы.


К тому времени, когда Amazon решили перейти на SOA (Service-oriented architecture), у них было около 7800 сотрудников, а их объемы продаж превышали $3 млрд.



Концертный зал Bill Graham Auditorium в Сан-Франциско вмещает 7000 человек. У Amazon было около 7800 сотрудников, когда они перешли на SOA.


Это не значит, что вы должны откладывать переход на SOA пока ваша компания не достигнет отметки в 7800 сотрудников… просто всегда думайте своей головой. Действительно ли это лучшее решение в рамках вашей задачи? Какая именно задача перед вами стоит и есть ли иные пути её решения?


Если же вы мне скажете, что работа вашей организации, состоящей из 50 разработчиков, попросту встанет без SOA, то я поинтересуюсь, почему так много крупных компаний просто замечательно функционируют используя единое, но хорошо организованное приложение.


Даже Google — не Google


Примеры использования систем обработки высоконагруженных потоков данных (Hadoop или Spark) могут действительно вызывать недоумение. Очень часто традиционные СУБД лучше подходят для имеющейся нагрузки, а иногда объемы данных настолько малы, что для них хватило бы даже имеющейся памяти. Вы знали, что можно купить 1Тб оперативной памяти где-то за $10 000? Даже если бы у вас был миллиард пользователей, вы бы всё равно смогли обеспечить каждого из них 1 Кб оперативки.


Возможно, этого не будет достаточно для вашей нагрузки, ведь нужно будет производить чтение и запись на диск. Но неужели вам действительно потребуется несколько тысяч дисков для чтения и записи? Вот сколько у вас данных по факту? GFS и MapReduce были созданы для решения вычислительных задач в масштабах всего интернета… например, для пересчета поискового индекса во всем Интернете.



Цены на жесткие диски сейчас гораздо ниже, чем в 2003 году, когда была опубликована документация GFS.


Может быть, вы читали документацию GFS и MapReduce и обратили внимание, что одной из проблем для Google являлись не объемы данных, а пропускная способность (скорость их обработки): они использовали распределенное хранилище, потому что слишком много времени уходило на передачу байтов с дисков. Но какова же будет пропускная способность устройств, которую вы будете использовать в этом году? Учитывая, что вам даже близко не нужно будет столько же устройств, сколько было нужно Google, может быть лучше просто купить более современные диски? Во что вам обойдется использование SSD?


Может быть, вы хотите заранее учесть возможность масштабирования. А вы уже провели все необходимые расчеты? Будете ли вы накапливать данные быстрее, чем цены на SSD будут идти вниз? Во сколько раз должен будет вырасти ваш бизнес, чтобы все имеющиеся данные больше не умещались на одном устройстве? По состоянию на 2016 год, Stack Exchange обрабатывал 200 миллионов запросов в день при поддержке лишь 4 SQL серверов: основного для Stack Overflow, ещё одного для всего остального, и двух копий.


Опять же, вы можете прибегнуть к UNPHAT и всё равно решить использовать Hadoop или Spark. И решение даже возможно будет верным. Главное, это чтобы вы действительно использовали подходящую технологию для решения вашей задачи. Кстати, в Google это хорошо известно: когда они решили, что MapReduce не подходит для индексации, они прекратили его использовать.


Перво-наперво, понять проблему


Пусть мой посыл и не является чем-то новым, но, возможно, именно в таком виде он отзовется в вас или может быть, вам попросту будет легко запомнить UNPHAT и применять его в жизни. Если же нет, вы можете посмотреть речь Рича Хики на Hammock Driven Development, или книгу Поля «How to Solve it», или курс Хэмминга «The Art of Doing Science and Engineering». Потому что главное, о чем мы все просим — это думать!


И действительно понимать задачу, которую вы пытаетесь решить. Говоря вдохновляющими словами Поля:


«Глупо отвечать на вопрос, который вы не понимаете. Грустно стремиться к цели, которую вы не желаете достичь.»



Перевод на русский


Перевод: Александр Трегубов
Редактура: Алексей Иванов (@ponchiknews)
Сообщество: @ponchiknews
Иллюстрация: LucidChart Content Team

Поделиться публикацией

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                              Вся статья про логику, при чем здесь github?
                              Может его примеры неудовлетворительны, но с логикой не поспоришь.
                                0
                                Так я и не спорю с его (вполне очевидной и не новой) логикой. Мне лишь примеры активно не понравились.
                        0

                        Полно простых бесплатных решений. Преждевременная оптимизация — зло)

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

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

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

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


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

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

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

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

                                  Одна из современных модификаций марксистской теории стоимости объявляет знания и трудовые навыки средствами производства (если кто не в курсе — оная теория обладает некоторыми фундаментальными противоречиями, которые пытаются преодолеть разными модификациями. то что я упомянул — одня из подобных попыток).

                                  Таким образом, все что осваивает разработчик (и вообще любой квалифицированный специалист) является инвестициями — точно такими-же как скажем приобретение недвижимости в спекулятивных целях или покупка акций какой нибудь компании. Инвестиция может быть неудачной — скажем можно приобрести недвижимость, спрос ка которую резко упал (или был изначально низким), можно купить акции компании которая завтра объявит о своем банкротстве, а можно изучить технологии, фреймворки которые имеют низкую востребованность на рынке труда.

                                  Так что если разработчики продавливают в компании использовании Hadoop, не стоит голословно объявлять их поборниками карго-культа — куда больше причин подозревать их в том, что они просто пытаются повысить свою рыночную стоимость.

                                  Из личного опыта — в компании в которой я работаю UI разрабатывается на vaadin — я не знаю кто когда и зачем продавил такое решение, но поменять его сегодня нет никаких шансов. Людей которые готовы писать UI код у нас очень мало. Очень мало из и на рынке. И в компании в которой работает просто охрененное количество разработчиков (по всему миру я имею в виду) практически все разработчики шарахаются от разработки UI кода как черт от ладана. И так будет и в дальнейшем пока все старперы, на которых держится данное решение не уйдут на пенсию (что не так уж и долго кстати). Причина очень проста — такого «слона» продать очень и очень сложно.

                                  Но при этом прямо противоположный пример — я всего несколько месяцев осваиваю Kafka — я не уверен, что использование этого продукта обосновано в нашей компании (но уже знаю о том, что несколько решений на его базе довольно сомнительны и противоречат типовым сценариям использования этого продукта, что как раз проблемой не является — все в равном положении новичков и потому готовы исправляь ошибки). Но я абсолютно уверен, что если я сейчас вставлю kafka в свой профайл в линкедине, я немедленно начну получать предложения о работе — т.е. моя рыночная ценность увеличивается. Ну и какое мне тогда дело до каких-то там UNPHAT?
                                    +2
                                    И оно ведь работает и в обратную сторону. Использование хайповых технологий позволяет быстро набрать людей на рынке. И это тоже может быть осознанным решением — пожертвовать эффективностью и простотой рантайма ради хайринга.
                                      0
                                      Оно работает во все стороны. Но ведь для того и голова на пречах квалифицированного специалиста, чтобы выдерживать определенный баланс для того, чтобы всегда оставаться в плюсе.

                                      И хайповость тут совершенно не при чем — на рынке просто немеряно «хайповых технологий», вокруг которых создается много шумихи, но которые либо останутся узко нишевыми или достаточно быстро сойдут со сцены.
                                      +1
                                      все верно, Resume Driven Development.
                                        0

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

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

                                          Мне кажется, описанные в статье примеры по умолчанию содержат предусловие о том, что разработчик хочет в первую очередь решить бизнес задачу оптимальным способом, а не поднять денег или качнуть скилл за счет работодателя/заказчика.
                                            0
                                            >>предусловие о том, что разработчик хочет в первую очередь решить бизнес задачу оптимальным способом, а не поднять денег или качнуть скилл за счет работодателя/заказчика.

                                            В конце 19-го — начале 20-го веков несколько инициативных групп продвинутых людей, вдохновившись теоретическими изысканиями одного немецкого философа решили реализовать его теоретические построения на практие — для начала в ожной, отдельно взятой стране — последнее условие потребовало правда некоторой модификации исходной теории, а затем еще одной, а потом еще парочки… Но в сущности никакие модификации не могли повлиять на один единственный и непредложный факт реальной жизни — человек (не тот, который описывался классиками, а реальный человек — лююбой из 7.7 млрд ныне живущих) никогда и ни при каких условиях не будет ставить собственные интересы, интересы своей семьи, интересы своего социального, этнического, религиозного (итп) сообщества ниже интересов абстрактного «общества» (общественных интересов), хотя декларировать это поведение он конечно будет на каждом углу, используя все возможные виды словоблудия (вроде «я угробил 60 человек ради общественного блага»).

                                            Много лет спустя, один последователь той-же теории родом из Южной Америки понял си. банальную истину и пришело к парадоксальным выводам — для реализации всех идей того немецкого философа (кои он тоже понял несколько по своему, творчески развив из в своем понимании) имеющиеся в наличии люди не годятся. Ну вот совсем… дрянь народец лжним словом. Нужны новые люди. Где взять? Ну… для начала нужно как-то устранить старых — их наличие неприемлимо. Дальше… ну вы поняли — геноцид, физическое устранение от 1 до 3 млн чел (до сих пор считают) интервенция соседней страны (тоже на тот момент реализующей идеи того-же самого философа)…

                                            Это я к чему все? В данной, крайне утрированной форме я пытаюсь сказать банальную вещь — любые попытки смоделировать поведение людей (особенно социальных групп) на основе идеализированных представлениях об их мотивации (особенно противоречащей биологической природе оных) всегда кончаются очень плачевно — в истории примеров этого не счесть. В общем случае не бывает разработчиков, которые хотят «в первую очередь решить бизнес задачу оптимальным способом». Бывают разработчики которые откровенно лгут, сообщая нечто подобное менеджерам (и которые делают вид, что они верят во всю эту ересь, да они и сами врут похожим образом, ибо таковы правила игры).

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

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

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое