Комментарии 197
«Медовая» неделя, знакомлюсь с состоянием дел.
— А вот тут у нас основная база данных, мы сделали горизонтальный шард на 6 (шесть!) инстансов, запись в БД у нас делается специальной процедурой, вот тут в ней идет вычисление ключа шарда…
— Ну ОК, сделано довольно грамотно, молодцы. А сколько записей сейчас в самой большой таблице?
— 50 000…
facepalm.jpg
Я это называю «удовлетворять своё любопытство за счёт работодателя».
Бизнесу, как ни странно, нужно решение его задач. Бизнес нанимает людей, наивно полагая, что они знают, как решать задачи бизнеса максимально эффективно.
Оказалось же, что задачу «сделать шардинг» никто не ставил, более того: она не была обоснована необходимостью решения какой-либо бизнес-задачи.
А теперь представьте себе. Скажем, три человека (тим-лид и два его подчиненных) в той или иной мере 2-3 месяца работали над реализацией этой идеи (я про ненужный шардинг, если вы не забыли). Грубый подсчет дает около полутора миллионов рублей, потраченных за это время только на их зарплату с начислениями. И это я еще не считаю стоимость аренды и оборудования рабочих мест и прочие косвенные расходы.
То есть ребята взяли и просто так, без всякой необходимости, распылили в воздухе полтора чужих миллиона. Потому что им стало любопытно.
Я думаю, что если бы им предложили возместить расходы, они бы сильно задумались в следующий раз, стоит ли проводить такие эксперименты.
1. Запас по прочности и масштабируемости(для приведенной выше ситуации)
2. Прокаченных и довольных разработчиков, которые могут решать теперь и более сложные задачи.
Да, бизнес от этого может пострадать, но только в случае, описанном вами. Представьте себе другую ситуцию, в которой разработчики пытаются рости в профессиональном плане и их инициатива не стоит компании сильно бОльших денег, чем какой либо иной подход
В подавляющем большинстве случаев работодателю нужно оптимальное решение задачи подходящим инструментом в оптимальные сроки. Что подразумевает отсутствие экспериментов с незнакомыми платформами. Ну просто потому, что даже если платформа и решает поставленную задачу (по слухам, которые донеслись из Stack Overflow и прочих интернетов), то в 99% случаев незнакомый с ней разработчик потратит непозволительное количество времени на набивание шишек и обход подводных камней. И если и вправду она такая хорошая, то при осознанном выборе зовут сторонних консультантов, имеющих опыт работы с ней, и внедряют под их руководством, одновременно обучая своих специалистов. В этом случае как раз на выходе будет и запас по прочности, и прокачанные свои разработчики.
А когда собственный разработчик убеждает работодателя: «А давайте возьмем эту новую клёвую штуку и попробуем сделать проект на её основе», при том, что инструмент ему незнакомый, но ему интересно просто с ним поработать, то это, как правило, чистой воды халтура и обман своего работодателя.
Что подразумевает отсутствие экспериментов с незнакомыми платформами
А если задача ставится так, что оптимально использовать незнакомые платформы, по сравнению с знакомыми? Например, вы всегда работали с postgresql, а тут вам нужен полнотекстовый поиск с кучей других параметров.
И опять же таки, в подавляющем большинстве случаев vision проекта (а его может и не быть) может кардинально менятся, и выбрать один инструмент, а не другой в итоге может получится выгоднее, хотя и не очень видно вначале.
А если задача ставится так, что оптимально использовать незнакомые платформы, по сравнению с знакомыми? Например, вы всегда работали с postgresql, а тут вам нужен полнотекстовый поиск с кучей других параметров.
Найдите специалиста по незнакомой платформе и оплатите консультацию. Это будет на порядки дешевле, чем по вляпаться в зря потерянное время по причине своей некомпетентности и нежелания эту некомпетентность признавать.
И опять же таки, в подавляющем большинстве случаев vision проекта (а его может и не быть) может кардинально менятся
Меняются требования — перепроектируем. Это нормальный процесс.
Найдите специалиста по незнакомой платформе и оплатите консультацию. Это будет на порядки дешевле, чем по вляпаться в зря потерянное время по причине своей некомпетентности и нежелания эту некомпетентность признавать.
Или взять некомпетентного специалиста на коснультацию. Ведь шанс напоротся на некомпетентного специалиста особенно на рынке СНГ довольно велик, ведь вы не знаете технологию нормально.
Иногда сделать это будет значительно дороже, чем разобраться самим. Имеем: компетентную команду, застафленную на проекте, которой поставлена задача на исследование оптимальной технологии для данного бизнеса. Принимать решение о привлечении внешнего специалиста команда сама не может, при этом уровня локальных специалистов вполне достаточно чтобы разобраться с новыми незнакомыми технологиями.
Так бывает достаточно часто — над проектами работают сложившеяся команды. Да, конечно же удобно когда те технологии, которые полностью знакомы команде совпадают с текущими задачами, но что делать если нет? Сразу вот так вот менять команду? Добавлять/менять специалистов? Время и ресурсы потраченные на это часто превысят расходы на до-обучение текущих.
Мы обычно сами пытаемся решить возникающие трудности, привлекаем специалистов для коротких консультаций, но честно, этих специалистов-архитекторов не очень то и много, и почти никто не занимается фрилансом, т е в выгодном свете здесь стоит корпоративная разработка, где есть пул архитекторов решений, а для маленьких команд проще всё таки опираться на свои силы.
Ну и главное — почти все решения не окончательны. Всегда можно что то попробовать, fail fast, и вернуться на правильный путь. Путём небольших экспериментов продвигаться к цели.
Найдите специалиста по незнакомой платформе и оплатите консультацию.
Разработчик, пускай даже глава разработчиков оплатить может разве что из своего кармана, как правило.
Это будет на порядки дешевле, чем по вляпаться в зря потерянное время
В плане затрат, как правило, не на порядки. Разовые коммерческие консультации стоят порядка месячной зарплаты штатного разработчика минимум при сроках порядка недели. Хотя бы потому что в цену входит не только зарплата специалиста, но и зарплаты персонала от уборщицы до гендира, плюс прибыль.
1. Затраты на эксперименты и «прокачку» разработчиков посчитаны, хотя бы в условных человеко-часах, что позволяет оценить себестоимость, и доведены до бизнеса.
2. Бизнес согласен на такие затраты. Причем согласие тоже зафиксировано каким-то образом, а не на уровне «Ну мне Петя сказал, что можно этим заниматься».
1. Затраты на эксперименты и «прокачку» разработчиков посчитаны, хотя бы в условных человеко-часах, что позволяет оценить себестоимость, и доведены до бизнеса.
Посчитаны кем? Разработчиками? С чего вдруг? А если бизнес не счел нужным посчитать — почему разработчик этим должен заниматься? Причем в рабочее время, ага, которое тоже, между прочим, денег стоит.
2. Бизнес согласен на такие затраты. Причем согласие тоже зафиксировано каким-то образом, а не на уровне «Ну мне Петя сказал, что можно этим заниматься».
Если речь идет о ФОТ — то он будет, при условии что бизнес доволен конечным результатом. Причем этот результат — с т.з. бизнеса, а не наши с вами рассуждения об избыточности примененной технологии. Выплаченная ЗП — это и есть подтверждение согласия, увольнение — неподтверждение.
Посчитаны кем? Разработчиками? С чего вдруг?
С того, что в любой методике разработки первичная оценка дается исполнителем. Это совершенно нормальная часть любого процесса.
— Тут надо применить Монгу
— ОК, сколько тебе примерно надо времени, чтобы попробовать и решить точно?
— Ну дня три…
— Хорошо, пишем 40 часов на research
Выплаченная ЗП — это и есть подтверждение согласия, увольнение — неподтверждение.
Как-то у вас всё категорично :)
Посчитаны кем? Разработчиками? С чего вдруг? А если бизнес не счел нужным посчитать — почему разработчик этим должен заниматься? Причем в рабочее время, ага, которое тоже, между прочим, денег стоит.
Не Вам конкретно, но вообще:
В нормальных бизнесах исследования новых решений должны идти особняком, а не при выполнении текущего заказа от клиента (исключая случаи, когда это нужно именно здесь и сейчас и сам факт эксперимента согласован с заказчиком и он согласен это оплачивать). Заказы выполнять надо только с помощью проверенных разработчиком решений.
Но такая схема работает только в случае, когда цену на свои услуги разработчик нормально формирует, закладывая в расчеты себестоимости и затраты на эти исследования и повышение квалификации персонала, а не тупо «ЗП + 100% наценки + любой наш каприз за ваши деньги». Работающие по последней схеме долго не выживают — их первые методично сожрут рано или поздно.
Разработчик написал игрушечное demo-приложение?
Так все нюансы проявляются только в реальном проекте, и иногда не в первый месяц разработки.
Стандартный деплой СУБД контейнером, стандартные компоненты доступа, малый объём тестовых данных, никакой разницы не заметишь.
малый объём тестовых данных, никакой разницы не заметишь
Генерация тестовых данных, нагрузочные тесты, не? Тогда почитайте о бенчмарках баз данных — многие «решения» отпадут даже после их прочтения. А потом можно провести по этим методикам и свои исследования.
Вы отрицаете самое главное: что бы быть в мейнстриме надо не просто распихивать модные фишки направо и налево, а предлагать клиентам апробированные хотя бы на тестах решения. Для этого нужно постоянно выделять ресурсы и время на исследования и обучение. Конечно если Вы строите бизнес, а не стрижете капусту здесь и сейчас.
Вы про коммерческую разработку для внешних заказчиков? Как быть с чисто внутренними проектами?
Собственный отдел разработки не ИТ-компании, например.
Как быть с "предлагать клиентам апробированные хотя бы на тестах решения"? На каком уровне должен решаться вопрос "давайте попробуем новую технологию", если бизнес (внутренний заказчик) не отличит ReactJS от ReactOS?
Как быть с «предлагать клиентам апробированные хотя бы на тестах решения»?
Очень просто: если руководство поставит мне задачу «должен появиться вот такой-то воркфлоу» и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работу.
На каком уровне должен решаться вопрос «давайте попробуем новую технологию», если бизнес (внутренний заказчик) не отличит ReactJS от ReactOS?
Внутри службы. Но руководитель службы несет ответственность за этот выбор. И, в случае фиаско зачастую идет искать другую работу.
:) :)
Или Вы про клинические случаи, когда руководители не просто отдают заявку «нам надо то-то и то-то» в работу ИТ-службе, а еще и указывают чем и где это реализовывать? Тогда все равно рано или поздно лучше начать искать другую работу :)
и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работуА иначе можно всю жизнь на Фортране просидеть. Как руководство поймёт, что это хромированный молоток, а не самый подходящий инструмент для задачи?
Как руководство поймёт, что это хромированный молоток, а не самый подходящий инструмент для задачи?
А Ваше руководство счета подписывает не глядя? Куда слать резюме?
Хромированным молотком может быть и бесплатный ClickHouse.
Хромированным молотком может быть и бесплатный ClickHouse.
Я без руля что это, но если Главная Система упадет, и это произойдет по причине того, что простую задачку, решаемую небольшой допиской существующими инструментами, Вы решили с помощью какого-то новомодного ClickHouse, который Вам просто понравился на рекламном баннере, то таки хороший штраф или искать другую работу.
PS
Не вижу смысла обсуждать сферических коней в вакууме, которых Вы вырисовываете на основании моих предыдущих ответов. Можете считать, что Вы победили.
если руководство поставит мне задачу «должен появиться вот такой-то воркфлоу» и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работу.
А если вы его начнёте реализовывать с изобретения палки-копалки?
Внутри службы. Но руководитель службы несет ответственность за этот выбор. И, в случае фиаско зачастую идет искать другую работу.
О чём и речь. Выбирают техсредства техспециалисты, а не бизнес. Бизнес может доверять выбор полностью (если он условно бесплатный), может требовать ТЭО различного уровня детализации и достоверности, может применять меры дисциплинарной ответственности за выходы из бюджетов/сроков и т. п. — это его решения.
Теперь понятно, почему в разных компаниях стоимость одних и тех же решений задач отличается в десятки раз. Бизнес в незавидном положении.
На ассемблере решать задачи того же складского учёта?
Суть сколь-нибудь оригинальной разработки в экспериментах на всех уровнях. Нет "золотых пуль".
Адекватность — понятие субъективное. Какой выбор по вашему более адекватный — берём фреймворк, закрывающий 90% функциональности, пускай и содержащий ещё 400% кода, который использовать в обозримом будущем не планируется, или берём набор библиотек, закрывающий процентов 50 функциональности, а остальное пишем сами?
и содержащий ещё 400% кода, который использовать в обозримом будущем не планируется
А вы что конкретно экономите-то? Место в пять мегабайт на диске под «неиспользуемый» код?
И нужно ли его экономить?
А вы что конкретно экономите-то? Место в пять мегабайт на диске под «неиспользуемый» код?
Обсуждать некий абстрактный теоретический фреймворк — дело неблагодарное, но в общем случае «400% ненужного кода» совсем не означает, что он просто лежит на диске и никому не мешает. Он может быть задействован, негативно влиять на производительность приложения, наконец, содержать баги и нежелательные фичи, которые как-то влияют на остальные 100% нужного и полезного кода. Поэтому тут каждый конкретный случай надо рассматривать отдельно.
«Ненужный» может быть задействован. ОК.
Вы зря так это скептически восприняли. Это не какая-то неожиданность, а повсеместная практика. Вот, например, простое веб-приложение на ASP.NET MVC. Я там использую один классический маршрут «сущность\идентификатор», под него контроллер и пару представлений. Фрейморк мне пошарится в поисках кастомных обработчиков, поищет файлы на диске, поищет фильтры и т.д.
Весь этот код для решения моей задачи совершенно ненужный. Но фреймворк так устроен, этот код там есть для других целей и других задач, и я никуда от него не денусь, он будет и в моём приложении и будет вызываться при обработке каждого запроса.
Файл настройки под сервер печати Линукс — 20 кб (при этом файлы, к примеру, от Самсунга подходят для Ксерокса).
Мне кажется, что-то здесь не так. Мало того, что место на диске, он еще и висит в процессах.
Надо еще учитывать, что некоторые фреймворки, закрывая какую-то функциональность, увеличивают стоимость оставшейся функциональности.
А почему я не могу взять набор библиотек закрывающий процентов 95% функциональности, а остальное написать сам?
Это отвратительная идея с точки зрения бизнеса.
А где в этот момент был бизнес, почему он не контролировал?
Вкратце: поверили вместо «проверили». Более подробно вряд ли смогу здесь рассказать.
Некомпетентность сверху привела к некомпетентности снизу (я считаю тезис о том, что только такая причинно-следственная связь возможна, доказывать не требуется).
Некомпетентность сверху привела к некомпетентности снизу
Почему некомпетентность? Обычное делегирование полномочий. Топ-менеджмент доверяет руководителю ИТ-департамента в этом плане, а тот также выбором фреймворков не занимается, а делегировал это своим девелоперским подразделениям.
Такое точно делегирование и в финансовом учете, и в маркетинге, и в производстве. Просто специфика разработки софта такова, что у программистов обычно возникает и желание, и возможность поковыряться в чём-то новом сугубо для утоления любопытства. Такого нет ни в маркетинге, ни в бухгалтерии.
руководителю ИТ-департамента в этом плане, а тот также выбором фреймворков не занимается
А тогда что у вас делает CTO? Делегирует дальше и зарплату получает, а ответственность на ком?
Поверьте, так тоже бывает.
Все всегда преследуют свои интересы. Тот же архитектор может преследовать сделать самую совершенную систему с масштабированием и отказоустойчивостью.
Вменяемый архитектор сначала уточнит бизнес-требования, а затем превратит их в технические.
У вменяемого архитектора не может быть своих интересов, не обусловленных требованиями бизнеса, ведь вполне может стать так, что бизнесу просто не нужно никакое масштабирование. И отказоустойчивостью в разумных пределах тоже можно пренебречь.
Если он это не понимает — он не архитектор пока еще.
Архитектор же должность. Разве нет?
Все люди подвержены своим интересам, и архетектор в том числе. Превращение бизнес-требований в технические не очень однозначный процесс, так что тут остается простор для своих решений в духе "у меня был полезненный опыт касательно X, так что тут я заложу масштабирование, даже если заказчик не хочет, то он точно захочет это в дальнейшем и так далее",
Если ресурсы позволяют вам иметь выделенного «освобожденного» архитектора — я вас поздравляю, такое случается нечастно.
я заложу масштабирование, даже если заказчик не хочет
Об этом и был мой самый первый коммент. Удовлетворение своего любопытства за чужой счет. Имхо, один из самых страшных грехов «разработчиков», которые никак не хотят понять, что «творцы тут не нужны» (с)
А тогда что у вас делает CTO?
СТО должен заниматься стратегическими вопросами — в каком направлении развивать ИТ инфраструктуру. Финансовыми вопросами по своей части — определять и защищать бюджеты на поддержание и развитие ИТ, и обеспечивать контроль их выполнения. Планированием работ по своей зоне ответственности должен заниматься. Должен контролировать приоритетные ИТ-задачи для бизнеса. Ну а фреймворки — это уже ответственность системного архитектора (иногда в одном лице с тимлидом), а никак не СТО.
Ну т.е. когда проблема всплывёт, как раз СТО будет раздавать люлей своим подчинённым, и будет отчитываться перед руководством компании, что-то сочинять про «обстоятельства, которые невозможно было предусмотреть на этапе проектирования». Но вот на уровне СТО заранее избежать подобной проблемы, как правило, действительно не получается.
А кто требования к системе формирует? Архитектор лишь создает архитектуру исходя из требований и ограничений(в том числе и финансовых)
А кто требования к системе формирует?
Требования к системе формирует бизнес. Или продакт-менеджер, если разрабатываемый софт не для внутреннего потребления, а для внешних клиентов. И в требованиях могут быть условия «нужно реализовать интеграцию с Х» или «нужно уметь выполняться в среде Y», но практически никогда не бывает условий «нужно писать на фреймворке Z». Этот Z уже определяется архитектором, исходя из его видения, насколько Z подходит для решения задачи.
В контексте существовала определенная ситуация.
Сугубо для утоления любопытства, это, пожалуй, редкость. Чаще сочетание двух основных факторов в той или иной пропорции:
- повышение (или хотя бы не понижение) своей востребованности на рынке труда
- решение текущих проблем разработки и эксплуатации
По второму фактору, увы, разработчики часто ведутся на маркетинг, то есть проблема реально есть, и разрекламированный инструмент вроде как её должен решить судя по рекламе. Но подводные камни и(или) полная цена решения проблемы разработчику неизвестны.
То, что эти потребности бизнеса будут удовлетворяться «распределенной системой» — это уже техническое решение. И не факт, что верное.
Конечно, кажется, что дела идут вразрез с идей оптимизации затрат каждого конкретного бизнеса, но зато существует экосистема как таковая. Некая избыточность для системы — благо, именно избыточность даёт ресурс для быстрого развития.
Вполне возможно, что бизнес просто не захочет оплачивать избыточность, осознав, что она ему не нужна. А вы, не сказав про альтернативу и заложив в архитектуру эту избыточность, фактически просто обманете заказчика.
Смысл всех моих комментов можно свести к фразе «Обманывать — нехорошо».
Не зря же говорят, допустим, что IT-бизнес лучше всего делать в Силиконовой долине. Почему? — Потому что концентрация людей, которые умеют и знают, там наибольшая.
Никто конкретно не оплачивает эту самую избыточность из своего кармана, но всем объективно хорошо, когда она есть, потому что дела растут быстрее у всех. Но я, конечно, понимаю, что с точки зрения микроэкономики, атомизированного субъекта отношений «купи-продай» это всё ересь. Однако — работает в реальной жизни!
ps. Понятие «обман» вообще очень размытое в нашей отрасли. «Вася, сколько тебе нужно на этот таск? — Два ч/д… Вася, прошло два ч/д, где коммит? — Обнаружились новые обстоятельства...» :)
Прошу обратить внимание, что вашим собеседником слово "избыточность" используется совершенно не в том смысле, в каком его используете вы.
Вася, сколько тебе нужно на этот таск? — Два ч/д… Вася, прошло два ч/д, где коммит?
Какая прекрасная в своей нелепости ошибка.
Вася сказал честно — два человеко-дня, примерно 15 часов работы.
Тот, кто спрашивал, не сумел превратить оценку трудозатрат в календарный срок, составив план-график, и теперь сваливает вину за свою некомпетентность, как PM-а, на бедного Василия.
А ведь Вася срок не говорил!
Кстати.
Все эти миллионы были распылены только в том случае, если разработчики в течение всего этого задвигали важные задачи подальше и весь рабочий день до последней минуты тратили на шардинг. Но я сильно сомневаюсь, что руководство будет терпеть то, что выдаваемые им задачи (зачастую срочные, весьма вероятно) начнут решаться через 2-3 месяца.
Куда вероятнее, что они тратили на него свое свободное время (а между задачами руководства почти всегда можно найти час-другой в день, либо задержаться на работе), и все задачи руководства решали в срок, либо с небольшой (да, в 3,14 раза)) задержкой срока, которая совершенно не влияла на бизнес.
Не было бы шардинга, у них всего лишь было бы свободное непродуктивно потраченное на баш и хабр время. Зарплата выплачивалась бы все равно в том же объеме.
И в чем тут "распыление"? В изношенной клавиатуре? Протертых байтами проводах? Километрах пробега мыши?
MapReduce, которые создавались, на минуточку, для хранения поискового индекса ВСЕГО ИНТЕРНЕТА.
И если вы это используете для чего-то меньшего, то вы не правы?) Я вот для обработки 100кб данных использовал что-то похожее на MapReduce, правда самописное.
Идея использовать инструменты по предназначению довольно неплохо, но проблема в том, что на уровне мелких компаний откровенно все равно, что использовать.
А на уровне больших все равно нужно будет передылывать.
Целых 0, потому что MapReduce — это парадигма, и к ней не обязательно поднимать гиганские кластеры.
Я к тому, что не совсем не понимаю спича по поводу "Не используйте MapReduce", ведь это парадигма работы с данными, которая масштабируется от одной маленькой базы до ВСЕГО ИНТЕРНЕТА.
MapReduce — модель распределённых вычислений, представленная компанией Google, используемая для параллельных вычислений над очень большими, несколько петабайт, наборами данных в компьютерных кластерах.
Но парадигма Group-By обработки данных конечно появилась задолго до этого.
Это тот случай когда копировальный аппарат начали называть ксероксом, хотя это всего лишь производитель
Но ведь на текущем витке фронтендовых технологий SPA и правда удобнее и проще делать. Каноничный клиент-сервер кажется проще ровно до тех пор, пока внезапно не оказывается, что фильтры в интернет-магазине должны работать без перезагрузки страницы, справа внизу должен быть уютный чятик, а блок сравнения товаров желательно сделать так, чтобы он тоже не требовал перезагрузки страницы.
Современный веб уже очень сильно не про "отдать отрендеренную сервером страничку".
Весь адъ начинает твориться уже на фронте. Это какой-то отдельный мир :)
Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:
- внутреннее состояние (любимый цвет кнопок, текст не до конца набранного комментария, настройки какого-нибудь фильтра и еще уйма интересных штук, которые разумеется более чем реализуемы в парадигме "отдать страничку, а при переходе по ссылке отдать следующую страничку", но по какой-то причине очень часто приводят к "я тут накидал на jquery, пожалуйста не трогай это никогда")
- архитектура. Потому что на чистом HTML, CSS и JS можно реализовать всё что угодно, но на Angular (фанатам фейсбука читать как "React") оно почему-то выходит более поддерживаемым и работоспособным.
- как ни странно, команда, которая обычно этим самым фронтендом занимаются фуллтайм, и обычно, при SPA подходе decoupling (как это по-русски правильно?) получается значительно выше.
Не забываем про PJAX и аналоги. Те же ВК, ютуб, гитхаб (правда, хз зачем это ему) работают без перезагрузки и имеют «уютные чятики» и прочие аудиоплееры, однако сервер им по старинке отдаёт отрендеренную страничку (точнее, часть), которая через innerHTML запихивается куда надо. По своему опыту могу сказать, что делать такое нетрудно.
(с печалью) и в итоге мы имеем бесконечную прокрутку в стиле xkcd#1309 ("Почему ты переворачиваешь страницы так странно? — Если я притронусь не в том месте, то потеряю открытую страницу, и придётся листать с самого начала")
SPA требует много работы, и об этом забывают — в итоге 95% SPA хуже, чем тупая пачка страниц со ссылками. Примерно все, которые сделаны не самыми крупными разработчиками.
Проблема исключительно в one-way binding'е данных на UI. Когда при прокрутке странички (допустим, у нас статья с кучей подзаголовков) хэштег страницы автоматически подменяется на текущий позаголовок (и при обновлении страницы мы попадем на него) такого не происходит никогда.
Понятно, что конкретная проблема решаема (в конце концов, работают же SPA у Гугла, Мейлру и прочих). Но при этом на куче сайтов (к примеру, мобильный сайт fontanka.ru — не самое мелкое СМИ) всё криво (случайно тапнул по статье, нажал back — листай с начала).
Т.е. масса народу лажает в SPA и т.п. — при том, что SPA им не особо и нужны, люди просто погнались за модой.
Начал писать длинный ответ, но потом понял, что он ни к чему.
SPA сложнее, и сломать его легче — это понятно. Но разработка любого современного портала, окромя возможно сайта-визитки ученика школы 1218 требует этой сложности.
Понятно, что конкретная проблема решаема (в конце концов, работают же SPA у Гугла, Мейлру и прочих). Но при этом на куче сайтов (к примеру, мобильный сайт fontanka.ru — не самое мелкое СМИ) всё криво (случайно тапнул по статье, нажал back — листай с начала).
Тайпнул по статье, нажал back, прокрутка вернулась назад — всё нормально работате. Правда, я смотрел в responsive-вкладке дебага хрома, не на телефоне, мб особенности железа. Но на первый взгляд я не вижу там никаких проблем.
Мода — понятие растяжимое. Мода мыть руки — тоже мода. Носить одежду после каменного века — тоже. Нужно только разделять полезную вроде этих, и бесполезный хайп. SPA я считаю скорее полезной тенденцией, в среднем.
А использовать инструмент без его понимания вредно в любом случае, что для SPA, что для Pure-HTML only, что для чего угодно. Не вина инструмента в этом.
Только что проверил: m.fontanka.ru, листаете до полного списка статей (или просто жмёте "все новости"), несколько раз нажимаете "ещё новости", чтобы подгрузить список дальше (при этом url не изменяется). Дальше тап по статье, бэк — всё, позиция потеряна.
В общем, хочется посоветовать разработчику: "не льсти себе, встань ближе" ;-)
при том, что SPA им не особо и нужны, люди просто погнались за модой.
Мне, как разработчику, SPA нужны. Их легче разрабатывать и поддерживать чем традиционные "серверные HTML-генераторы". Естественно при наличии соответствующего инструментария.
При наличии соответствующего инстрементария может оказаться легче использовать "серверные HTML-генераторы", разве нет?
Нет. При наличии сопоставимого инструментария легче разрабатывать и поддерживать при чётком разделении на фронтенд и бэкенд, которые общаются между собой по фиксированному API.
Разработка сразу двух слоев не может быть проще чем разработка одного слоя при наличии сопоставимого инструментария.
Разработка монолита дешевле, но поддержка дороже.
Может. Уменьшение связанности, увеличение связности, уменьшения количества ответственностей и прочие подобные принципы созданы для упрощения разработки, а не усложнения.
Но до недавнего времени с инструментарием на фронтенде было гораздо хуже, чем с инструментарием на бэкенде.
У нас во фронт-енде действительно с этим полный адЪ :)
Если каждый сайт начинать с нового стэка, модного на этой неделе, то да, проще и быстрее написать на коленке.
Если же писать приложение, с расчётным сроком эксплуатации лет в 5 хотя бы...
Пусть страницы останутся нативно-индексируемыми, а все что требует сложной интерактивности будет внутри неких компонентов. Я возлагал надежды на web-components в этом плане, но как то у них медленно все продвигается.
Вы забываете задать себе вопрос: а нужно это бизнесу? То есть, возможно этот магазин и не будет сколько ни будь популярным, может оно ему это все пока и не нужно. Ну и всегда есть возможность масштабированя другими инструментами, не только так сказать SPA-first.
Только хотел бы отметить один момент:
Я прочёл оригинальный документ, в котором описывались принципы работы Dynamo и, зная, что Cassandra достаточно близка к Dynamo, понял, что эти системы строились на принципе приоритизации операций записи.
И они даже добились этого, пожертвовав, однако, гарантированной консистентностью и функциональностью традиционных реляционных баз данных. Но компания, с которой я обсуждал применения этого решения, не ставила запись данных в приоритеты (все данные приходили одним блоком раз в сутки), а вот консистентность и производительное чтение были как-раз очень нужны.
Чтобы прийти к таким выводам, нужно достаточно глубоко изучить инструмент, что, на самом деле, не так просто и требует времени. Усугубляет ситуацию обилие выбора, особенно в NoSQL решениях.
Разработчик зачастую не хочет копать достаточно глубоко, проще и приятнее — «чик-чик и в продакшен».
Даже если компания экстремально маленькая, всегда можно найти на почасовку грамотного человека, который подготовит вам архитектурное решение.
Иначе так и будут плодиться «CRM на mongoDB», которые потом приходится переписывать, тратя человеко-годы, или просто выкидывать (причем бывает, что вместе с командой, которая такое накодила)
И много программистов согласится на такое?
Системный архитектор — это роль, отвечающая как раз за обоснованный выбор технологий и архитектурных решений.
Отсутствие в команде такой роли приводит обычно к Битриксу :)
И всегда эти истории заканчивались печально. «Архитекторы» увольнялись, кому-то приходилось, употребляя весьма непечатные выражения, наводить порядок в их хозяйстве и объяснять бизнесу, что решение фактически придется написать заново…
Нет, не понравилось что вы отбираете право влиять на выбор архитектурных решений у того, кто потом ими и будет пользоваться.
По моему опыту — именно специальные системные архитекторы и имеют привычку выбирать странные решения вроде монги, шарепоинта или SSIS. Просто потому что читали об их плюсах — но не читали о минусах.
Но пока считаю ровно так, как написал выше: архитектор и разработчик это разные роли, и тот, кто пишет код, не может нести ответственность за выбор архитектурного решения.
Выбор — это ответственность прежде всего. А ответственность может быть только персональной.
Если им сверху спустить sharepoint, они будут плеваться и брыкаться, делать пусть не на от^&%сь, но строго в рамках ТЗ (чуть шире им не интересно).
Если они сами выбирают технологию, они смогут с ней поиграться, как им нравится, и сделать намного больше и красивее, чем в ТЗ.
Со стороны бизнеса «поиграться» равносильно «выкинуть деньги в никуда». Когда бизнес нанимает разработчика, он полагает, что нанял профессионала, который знает решение его (бизнеса) проблем, и что разработчику не нужно «играться», но он может сесть и сделать.
Вы же предлагаете немного по-детски наивный подход: «дайте нам бабла, мы поиграемся и сделаем, как нам нравится, и пофигу на ТЗ».
В реальной жизни не нужно делать лучше, чем в ТЗ. Нужно сделать то, что написано и как можно быстрее.
Мотивация? Ну да, отчасти здесь я с вами соглашусь. Однако существует множество методик управления, которые создадут у разработчиков иллюзию их причастности к принимаемым решениям. Так что не вижу большой проблемы.
Вы с другой стороны, уважаемый коллега.Возможно, и нет. Для вашего решения требуется больше затрат. Нужны отдельные люди на много новых ролей: дизайнеры, UI-специалисты, архитекторы решений, и т.п.
Если разработчик не будет прилагать усилий, а тупо кодить, кто-то другой должен приложить эти усилия и описать, что нужно. Причём в случае заинтересованного разработчика он уже в «теме» проекта. А вводить 100500 лишних людей в проект, чтобы они вникли во все детали — это время, значит, и деньги.
Однако существует множество методик управления, которые создадут у разработчиков иллюзию их причастности к принимаемым решениямЕсли какой-то разработчик зевает от упоминания sharepoint, можно его убедить, что он сам его и выбрал?
Нужны отдельные люди на много новых ролей
Я нигде не утверждал, что роль == должность или что каждая роль — это отдельный человек. Напротив, если вы внимательно почитаете мои комментарии, то найдете прямо противоположные утверждения.
Один человек вполне может сочетать несколько ролей, не вижу никаких проблем. Важно только, чтобы роли были выделены, формализован список обязанностей и зафиксирована ответственность по каждой роли.
Если какой-то разработчик зевает от упоминания sharepoint, можно его убедить, что он сам его и выбрал?
Плохой пример, потому что никто в здравом уме не будет выбирать sharepoint :)) Но в целом да, решение можно подать, как якобы принятое коллективно.
Один человек вполне может сочетать несколько ролей, не вижу никаких проблем. Важно только, чтобы роли были выделены, формализован список обязанностей и зафиксирована ответственность по каждой ролиКак это в реальности выглядит?
Мол, ты, Вася — сегодня архитектор. Пишешь дизайн-документ для себя — завтрашнего кодера. Обоснуешь принятое решение.
И что от этого изменится? Если Вася хочет Кассандру, он напишет в документе, какая она крутая и как используется в решениях всякими знаменитостями типа Cisco и т.п.
Как это в реальности выглядит?
Это выглядит как документ. На бумаге. Который фиксирует должностные обязанности, скажем, некоего «Ведущего разработчика». В котором написано «Исполняет роль DBA, включая следующие обязанности: ...».
Условный Вася знакомится с этим документом и приказом о введении его в действие, после чего начинает нести ответственность в соответствии с возложенными на него обязанностями.
И что от этого изменится?
Появляется понятие «ответственность». Если аудит покажет, что решение было неверным, но принятым Васей в рамках его обязанностей (которые он на себя принял), то Вася может пострадать материально (возмещение убытков) или морально (увольнение).
Кто и по каким канонам решает, что верно, а что — неверно? Нет никаких формальных документов, значит — произвол «эксперта».
Если какая-то контора это практикует, вокруг них должна сложиться репутация, что там, мягко говоря, странные руководители. Адекватный человек туда не пойдёт.
Задача разработчика — код писать, а не выбирать решения.
Извините, конечно, но «код писать» — это задача кодера, а не разработчика.
На мой взгляд, тем и отличается хороший разработчик от плохого, что плохой просто сидит и пишет код, а хороший разработчик создаёт законченное, надёжной и качественное решение безнес-задачи.
Очень хорошая и правильная статья. Но до своей ЦА вряд ли дойдёт. А этих ребят, как ни странно, безумное количество. Раз в неделю вижу примеры, например, переписывания с PHP на Go неких проектов, которые годами исправно тащили все свои полтора rps. Причём уже несколько раз видел, когда это закономерно проваливается, и люди делают вывод, что нужно было подражать другому популярному тренду. И начинают новый виток бессмысленной разработки.
Очень жаль, что эту простую истину приходится каждый раз объяснять заново.
— Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора
— Не закупать железо или облачные ресурсы: это сисадмин
— Не проектировать базу данных: это DBA
— Не заниматься выкладкой кода в бой и обновлением: это dev-ops
— Не тестировать и не писать тестовые сценарии: это QA
— и даже не настраивать себе софт на рабочем месте
А просто писать код. И всё.
К сожалению, в 95% случаев всё заканчивается на уровне «тыжпрограммист? вот иди и сделай!» и ни о каком разделении ролей внутри команды говорить не приходится. А нет разделения ролей — нет и ответственности, получается, что ответственность «коллективная», за ошибочные решения как бы никто не отвечает, виноватых нет.
Либо разбиение внутри команды идет бюрократическими методами и не учитывает специфики работы, т.к. за назначение ролей ответственен менеджер, которому надо иной раз подсказывать как пользоваться Word (и такие случаи бывали. Встречалось на предприятиях с низкой з/п)
Есть такой классный документ, называется «должностные обязанности». Так вот, там можно писать примерно так: «Выполняет роль инженера QA, включая следующие обязанности:… „
Только не говорите, что это “бюрократия», просто банальный порядок.
P.S. Проект, кстати, тогда взлетел и проработал, пока не померла газета :)
К сожалению слепое следование подобному подходу порождает до ужаса однобоких специалистов.
Я бы сказал что так должно быть в идеале в крупных проектах с большими командами (и обычно так и есть),
однако, если программист "только пишет код" и никогда даже не пытался "во все остальное", это чаще всего крайне посредственный программист.
Специалист должен знать смежные области, чтобы быть специалистом в своей.
Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора
Программисту необходимо понимать почему был выбран именно этот фреймворк.
в зависимости от политики и размера команды и состояния проекта (например в начале) — принимать участие в обсуждении выбора оного вместе с архитектором.
Не закупать железо или облачные ресурсы: это сисадмин
Закупать железо не должен, но как минимум должен иметь представление на каких мощностях и платформах его код может/должен работать.
Не проектировать базу данных: это DBA
Очень спорно что программист не должен принимать в этом участия, выделенные DBA — это больше удел "у нас половина бизнес логики в БД", а обычно же бизнес-логика БД сильно переплетена с приложением (во всяком случае приложения рассчитывают на те гарантии что дают им БД), и знать реляционную теорию и принципы работы с массивами данных — прямая обязанность программиста, также как и принимать участие в проектировании процессов работы с данными.
Не заниматься выкладкой кода в бой и обновлением: это dev-ops
Да, хорошо когда этим занимаются отдельные люди, но понимание должно быть и приложения должны быть написаны таким образом, чтобы упрощать этот процесс, а это уже обязанность программиста а не dev-ops.
Не тестировать и не писать тестовые сценарии: это QA
Смотря что подразумевать под тестированием: автотесты (юнит, апи, интеграционные), само понимание того как сделать софт "тестируемым", проверка функциональности того что программист непосредственно пишет, да и вообще всяческий самоконтроль — это только в плюс, очень тяжело работать с людьми которые даже базово не пытаются проверять что пишут.
Я сталкивался с подобным, когда на ревью / к тестерам / в сборку отправляли вообще никак не работающий и не проверенный код, и это в больших компаниях, а в малых то и тестер не всегда есть.
и даже не настраивать себе софт на рабочем месте
Вот это, простите уже перебор, я бы даже не стал работать в месте где не могу настроить себе машину так как мне нужно, а человека который не может себе настроить рабочее окружение, никогда не возьму на работу.
Да, могут быть всякие штуки по безопасности которые настраиваются централизованно, и контролируется это отделом безопасности, но — рабочее окружение — это не их водчина.
В заключении скажу, что по моему опыту, огромная доля профессионального роста происходит как раз за счет понимания смежных областей. Огромное количество хороших практик разработки пришло как раз из понимания как облегчить жизнь себе и другим.
Программист должен знать те инструменты с которыми он работает.
Статья как раз о том — что нужно понимать почему мы выбираем тот или иной инструмент, нужно понимать как он работает изнутри, чем он нам поможет, а чем может навредить. А что бы хоть на каком то уровне это понимать нужно хоть немного (а чем больше тем лучше) "мочь в смежные области" — это и для себя хорошо и для работодателя. Без понимания этих вещей, которыми программист вроде бы не должен заниматься, невозможно грамотно этот самый инструмент выбрать и избежать тем самом казусов описанных автором.
Заодно такое понимание может привести вас к возможности исполнять те самые роли, которые "должны" этим заниматься, а иначе откуда же возьмутся все те "разбирающиеся в технологии" консультанты и крутые архитекторы которые подскажут что же надо выбрать и почему.
В сообщении, на которое вы ответили, вообще не предполагается, что человек из одной области может в другую перейти — какие-то дискретные непересекающиеся области получаются. А в реальности стать, к примеру, devops нельзя, никогда не программировав, имея только опыт развертывания чего-то в вакууме или какие-то системные понятия. Очень сомнительные советы.
В технике выделяются: средняя техническая квалификация техник-программист (ранее «программист-лаборант») и высшая техническая квалификация инженер-программист. Предметом деятельности специалистов с соответствующей квалификацией (техников и инженеров) является проектирование, разработка и производство программного обеспечения, как промышленной продукции, удовлетворяющей заданным функциональным, конструктивным и технологическим требованиям (результатом деятельности является программное обеспечение).
Замечательная статья!
Особенно смешно слышать рекомендации о том, какие использовать инструменты, только вдумайтесь, — в экспериментах! Даже не в серьезной разработке!
При выборе инструмента исхожу из доступных сроков (при дедлайне через неделю не до новых инструментов, которые могут потребовать куда больше времени на изучение), работоспособности инструмента (минимум велосипедописания для типичных операций), целевой платформы.
Если в качестве целевой платформы выступает ПК с параметрами типа для WinXP x32 (192 МБ оперативы DDR1, HDD 20гб) для преусловутой «бабушки с блокнотом», то и современные инструменты типа .NET будут под очень большим вопросом, а сейчас так вообще из-за отказа от поддержки WinXP многие инструменты просто не заведутся.
С другой стороны:
США, один достаточно средний из мелких интернет-магазинов со специализированным предложением страдает от падений сервера при обновлении карточек товаров бэкендом Magento с допиливанием каких-то разрабов. Страдает до полной падучей и последующего внешнего ребута виртуалки. Заглядываю вовнутрь: две виртуалки (веб-сервер и MySQL) в Amazon. Обе с 32 ГБ ОЗУ и по 16 каких-то ядер. В системе постоянно уходит в полный даун MySQL из-за нехватки памяти, летят индексы и дальше по тексту. Хорошо что в минимум нагрузки на их сервер (глубокая ночь в Калифорнии) у меня разгар рабочего дня — запустил этот пересчет и просматриваю логи MySQL и данные session manager. Проблема нашлась просто: в карточке каждого товара надо внизу вывести 6 подобных товаров, которые выбираются из номенклатурного справочника одним селектом: в данной категории товаров сделать выборку, исключив текущий товар, рандомно ее отсортировать и выбрать первых 6 результатов. Этот единственный запрос возвращает готовый результат, содержащий в т.ч.наименование товара (поле varchar(512) и краткое описание (поле TEXT)… Этому модулю никогда не хватает памяти и он начинает свопить результаты через диск. Некоторые свопы могут длиться более 40 секунд…
Неделю с ними развлекался постоянно предлагая разработчикам только одно решение: запрос должен возвращать только id карточек похожих товаров, а потом уже по ним подтягивать все эти поля-монстры. Знакомый аутсорс-администратор сказал, что через месяц они перешли на более производительный хостинг…
PS
У вас есть 3 попытки угадать из какой страны происхождение фамилий владельца этого интернет-магазина и разработчиков :)
Проблема нашлась просто: в карточке каждого товара надо внизу вывести 6 подобных товаров, которые выбираются из номенклатурного справочника одним селектом: в данной категории товаров сделать выборку, исключив текущий товар, рандомно ее отсортировать и выбрать первых 6 результатов. Этот единственный запрос возвращает готовый результат, содержащий в т.ч.наименование товара (поле varchar(512) и краткое описание (поле TEXT)… Этому модулю никогда не хватает памяти и он начинает свопить результаты через диск.
Что-то я не очень понял, почему 6 записей с полями varchar(512) и TEXT должны что-то там нагружать и свопить?
Итоговые поля возвращаемые для такого мизерного количества записей вообще не должны ничего стоить, здесь надо было оптимизировать то, как эти записи отбираются, смотреть план запроса.
И самое главное — в таком запросе присутствие текстовых полей вредно независимо от текущего плана выполнения запроса.
А план запроса нормальный был — 3 индекса и последующий «file sort».
Все же действительно непонятно. То что вы предложили (если я правильно понял) это антипаттерн за который хороший DBA вас казнит: вместо одного селекта вы сделали 7. Проблема была явно в чем-то другом.
Опять ничего не понял. Давайте без эмоций. Есть таблица:
id, name (varchar), param1 ... paramN, description(text)Фактически вам надо сделать по ней select
select * from table where <filter(param1 ... paramN)> limit XОсновная трудность здесь в наборе фильтров, которые приходят с интерфейса. Фактически у вас получается динамический sql. C этим будут определенные технические трудности, но они решаемы разными методами в разных DB. Вторая особенность которая мне видится: вам врятли нужен весь description. Скорее всего его нужно подрезать некой ограничевающей размер функцией.
Теперь я пытаюсь играть в угадайку. Похоже у вас сделано так:
-- Не делайте так - это антипатерн. Индексы не используются!
select * from table
<фильтр на стороне клиента BD>А вы предложили так:
-- Не делайте так - это антипатерн.
select id,param1...paramN from table
<фильтр на стороне клиента BD>
foreach id in <filter_result>:
select name, text from table where id=idВы так сделали?
в карточке каждого товара надо внизу вывести 6 подобных товаров, которые выбираются из номенклатурного справочника одним селектом: в данной категории товаров сделать выборку, исключив текущий товар, рандомно ее отсортировать и выбрать первых 6 результатов.
Полагаю, проблема здесь именно в рандомной сортировке, которая, очевидно, не будет использовать индексы, соответственно сложность будет сильно расти с ростом количества товаров данной категории и запрос будет тормозить даже есть вернет только идентификаторы товаров.
Ну тогда не понятно, почему рандомная сортировка приводит к чтению текстовых полей. Особенность Mysql или баг?
У клиента таблица номенклатурного справочника, где для каждой записи, в т.ч. есть поле с name товара типа varchar(512) и поле с description товара типа TEXT. Названия товаров примерно от 100 символов и более, описания — от 2к. В справочнике более 2 млн записей в нескольких десятков групп товаров и тьме подгрупп.
У клиента для каждого товара из справочника выполняется один селект по данной таблице примерно такого вида:
SELECT * FROM t1 where cat_id = 1 and subcat_id in (2, 3, 4) and id <> 12346 ORDER BY RAND() LIMIT 6;
И на такой большой таблице с объемными строками Мускул естественно уходит в своп…
Результаты этого селекта (точно используются поля parent_id (id товара, для которого используется этот список), id, cat_id, subcat_id, name, description) записываются в отдельную таблицу. Поэтому я им настойчиво предлагал сделать так:
SELECT id FROM t1 where cat_id = 1 and subcat_id in (2, 3, 4) ORDER BY RAND() LIMIT 6;
Результат записать в итоговую таблицу, а потом отдельным селектом подтянуть в эту таблицу значения cat_id, subcat_id, name, description. Делать это заполнение после каждого основного селекта или по итогам всей работы — решать разрабам, т.к. в заказ, а соответственно и оплату, не входило ковыряние в их Magento и допилах в нем. Я им указал на то, из-за проблем с чем они оплачивали мою работу. Но даже если существующий СЕЛЕКТ разбить на предлагаемые мной две части, то все равно имеем колоссальное уменьшение объема операций чтения-записи данных.
Независимо от размера таблицы объясните мне смысл тащить в СЕЛЕКТ с рандомной сортировкой результатов поля varchar(512) и text?
Ну мало ли — может Мускул примитив, а летящие в облаках Oracle и MS SQL это щелкают как орешки? Задал вопрос о существующей реализации у клиента сертифицированному и практикующему DBA ORACLE — его ответ не привожу по соображениям цензуры. :)
PS
Отдельный респект заминусившему мой предыдущий коммент — это однозначно был «хороший» DBA :)
А на самом деле надо делать вот так:
SELECT * FROM t1 where cat_id = 1 and subcat_id in (2, 3, 4) ORDER BY subcat_id, id LIMIT /* тут случайное число */, 1;И так 6 раз.
Не очень вариант.
limit n,k делает чтение из нисходящего итератора n раз, плюс k раз делается выборка результата. Т.е. если у вас 1м позиций, то в пределе вы можете получить 6М-1 чтений. Да, если все пойдет нормально, то вы не будете читать те самые текстовые поля, но крутиться по максимальной выборке будете.
Лишняя сортировка — хуже, в моем же варианте от нее можно избавиться, если правильно подобрать индексы и то, что стоит в ORDER BY. Главное — даже при дальнейшем росте базы никакого случайного filesort уже не случится.
Кстати, если использовать оконные функции — то можно и вовсе ограничиться одним проходом, так, наверное, будет еще лучше.
Странно, что в вашем случае этот запрос дает чтение description и name больше 6 раз. В нормальном движке план выполнения строится так, что столбцы не участвующие в where/group/order выбираются на финальном (самом верхнем цикле), а limit не является фильтром, он тупо обрывает выполнение построенного итератора. Ну, т.е. по факту этот запрос в Oracle прочитает поля name, description только 6 раз.
Если взлезть глубоко, то есть еще проблема блоков. Т.е. так может сложится, что name окажется в одном блоке (8k — default) с id и тогда они всегда будут читаться одновременно, что вы не делайте, но это уже проблема другого масштаба.
Я щас не возьмусь сказать, почему эта ерунда просиходит с mysql, но небольшой опыт с этой базой наводит меня на мысль, что дело в функции RAND(), точнее в её применении с order by, возможно именно она корёжит план выполнения. Ибо limit в этой базе работает как надо.
У клиента для каждого товара из справочника выполняется один селект по данной таблице примерно такого вида:
Вот это место тоже непонятно. Почему не join? Зачем плодить запросы над одними и теми же данными, когда можно написать один запрос?
Проблема тут не в самой RAND(), а в том, что делается сортировка по выражению, по которому не построен индекс. А если уж СУБД решила делать сортировку — то упорядочиваться будут записи целиком. Отсюда и filesort — в память такие объемы не влезают.
Не уверен что даже Oracle знает, что в такой ситуации можно прочитать только часть полей, потом выполнить сортировку, применить LIMIT и уже потом дочитать оставшиеся поля. По крайней мере, я о таких алгоритмах не читал ни разу.
прочитать только часть полей, потом выполнить сортировку, применить LIMIT и уже потом дочитать оставшиеся поля.
Не, не так. Там, насколько я понимаю работать будет так (адовый псевдокод):
iterator=function (filter) {
for rowid in (<тот самый селект>){
yield rowid
}
}
i=0
while (rowid = next(iterator)) {
i++
if (i>6) break
select * from table where rowid=rowid
}Т.е. там будет не <тот самый селект> а select rowid from table where <то самое условие>
Вы написали то же самое, что и я (только про сортировку забыли). Повторюсь — я ни разу не слышал про такие эвристики.
Это не эвристика, это дефолт. Т.е. он всегда так делает.
Всегда = при любом запросе или всегда = при любой сортировке?
Хороший вопрос. Я бы его конкретизировал до "при сортировке по индексу или без". Поскольку при сортировке по индексу я в этом алгоритме уверен. Это видно в плане выполнения. А вот что происходит при сортировке по безиндексоному полю я понять не могу однозначно.
Опыт почти 10-летней эксплуатации высоко нагруженного Oracle 9i показывает, что даже у него на достаточно простых и массовых запросах вдруг съезжает статистика и он их начинает выполнять через одно место. Поэтому в критичных для общего здоровья системы местах у нас в тяжелых запросах используются все эти nls() и т.д.
Сортировка тут — лишняя сущность. Если используется индекс, в котором нет каких-то полей, нужных для выполнения запроса — в плане появляется операция загрузки этих полей из таблицы.
И эту операцию оптимизатор запросов может передвинуть в плане выполнения так, чтобы уменьшить стоимость. Это особенность работы индексов, а не сортировки.
Но разбивать одну операцию сканирования таблицы на две чтобы одну из них передвинуть в другое место — это именно дополнительная эвристика, и про нее я не слышал.
Сортировка добавит ещё одни итератор, который будет читать сортируемое поле и возвращать rowid.
Вот это место тоже непонятно. Почему не join? Зачем плодить запросы над одними и теми же данными, когда можно написать один запрос?
Я не знаю. Это индийцы, живущие в Калифорнии, а 2 из 3-х разработчиков в переписке живут в Индии, если следить за временем их ответа. Зачем мне рыться в их архитектуре сверху вниз, когда стоит простая задача оживить магазин и сказать почему он сдох? Оживил, указал на причину, предложил пути решения, они выбрали другой вариант — больше платить за хостинг… Магазин вырастет по оборотам, упадет — я опять подниму денег на них :)
Вот это место тоже непонятно. Почему не join? Зачем плодить запросы над одними и теми же данными, когда можно написать один запрос?
Вот это место как раз понятно. Запрос, который содержал join, уже падал раньше :-)
SELECT * FROM t1
where cat_id = 1
and subcat_id in (2, 3, 4)
and id <> 12346
and RAND() < 100 / (SELECT count(*) where cat_id = 1 and subcat_id in (2, 3, 4))
ORDER BY RAND() LIMIT 6;
Я давно не работал с базами, а с MySQL вообще почти никогда, не уверен будет ли подзапрос на выборку количества записей выполняться один раз для всех, или для каждой записи свой, но его всегда можно вынести наружу, если что.
Идея такая: изначально ограничиваем выборку примерно сотней случайных записей, а уже потом для этих 100 записей делается случайная сортировка и выборка ровно 6-и штук.
Разве в MySQL orderby не является блокирующим? То есть мы взяли и посортировали 2млн записей
SELECT id FROM t1 where cat_id = 1 and subcat_id in (2, 3, 4) ORDER BY RAND() LIMIT 6;Чтобы потом достать 6 штук в случайном порядке...
Разве в MySQL orderby не является блокирующим?
Так, чиста с потолка:
Если можно выбрать что отсортировать: 2ГБ байтов или 10МБ байтов, то так уж принципиальна разница в механизмах блокировок? Ведь каждый байтик надо считать в память, подвигать его туда сюда, выгрузить потом… Данный запрос валится из-за колоссального объема ввода-вывода.
Тут вообще непонятно, почему движок так поступает. В том же MSSQL выгрузка всех полей не производится до непосредственной выдачи результатов. То есть там движок выдал бы что-нибудь в духе:
SELECT * FROM t1 where id IN (
SELECT id FROM t1
where cat_id = 1 and subcat_id in (2, 3, 4) ORDER BY RAND() LIMIT 6
)Нашли 6 айдишек, достали для них поля, вернули.
Проблема на самом деле очень распространненая и на том же StackOverflow не один топик есть.
Суть в том, что ORDER BY RANDOM() начинает безбожно тормозить на хоть сколько-то больших объемах данных, даже на 100к записей это заметно. И самый простой способ оптимизирвать это «в лоб», первым запросом выбрать id записей, а потом уже выбрать нужную информацию по этим id.
В идеале, конечно, делается это через подзапросы к БД с более сложными штуками для оптимизации, но даже это примитивное решение джуниора, которое гуглится за 5 минут дает ощутимый прирост производиетльности.
Вот тут-то — и последующий «file sort» и зарыта собака.
— это решает бизнес-задачи;
— бизнес устраивают сроки и «качество», которое получается.
Нужно ли что-то лучше, если это работает?
Думаю нет!
— А представьте, что вот на эту вашу архитектуру придёт миллион rps?
— Откуда они возьмутся?
— Ну неважно, вдруг так случилось? Что тогда? Как масштабироваться будем?
Смотрю на собеседника и не понимаю — то ли он шутит, то ли серьезно рассуждает, что его планово-убыточный магазин никому не нужной обуви должен работать в условиях миллионов реквестов в секунду…
Совет стартапам, вас больше должен интересовать вопрос, как по скорей выкатить нечто работающее и где взять бабло на его продвижение (я не видел, чтобы что то выстрелило само, без толкания паровоза). Вопрос о масштабировании, в ближайшие два года вас интересовать не должен :)
Что характерно, ни один из проектов где подобные вопросы задавали, не то что до миллионов, а даже до просто хотя бы одного запроса в секунду в среднем не доходил.
но в стартапах это более комично.
В стартапах как раз не комично.
Стартап это по-определению нечто, что дико-бешено растёт, и за несколько месяцев аудитория может вырасти до миллионов посетителей.
Иначе это не стартап, а просто некий бизнес, возможно даже предпринимательство, на просторах интернета.
Проблема в том, что если на стартап набегают юзеры вдруг и резко, то он крякает и получается потеря аудитории, что для стартапа критично, т.к. кроме аудитории у него зачастую ничерта и нет.
Беда только в том, стартап ты или нет, выясняешь уже постфактум, когда миллионы юзеров что-то не набежали и ты не стартап =(
Стартап это по-определению нечто, что дико-бешено растёт, и за несколько месяцев аудитория может вырасти до миллионов посетителей.
Стартап, это кучка энтузиастов, которая имеет идею, которая по их мнению выстрелит. Вырастить аудиторию стартапа за несколько месяцев до миллионов, это
если на стартап набегают юзеры вдруг и резко
Это заблуждение, извините за категоричность, но на вас никто не нападет. Это будет большой успех, если за первые месяцы вы заинтересуете хотя бы несколько тысяч.
А представьте, что вот на эту вашу архитектуру придёт миллион rps?
Я очень часто задаю этот вопрос коллегам. Дело не в том что я хочу map-reduce и кластеризацию, а просто потому, что я хочу, чтоб паджинация на списках была сразу, а не когда припечет. Или чтоб индекс на таблице появился заранее в очевидных местах (селектим товар по цене — индексируем цену). Или чтоб вся статика на сайте кешировалась (это требует соблюдения определенных правил), а jquery был заменен в проде на jquery-mini.
Таких примеров привести можно много. Именно они дают реальный результат, а стоят копейки. Но обычно все происходит не так: "приждевременная оптимизация вредна", "эта таблица никогда не вырастет"
Очередная статья в стиле «давайте кушать суп ложкой, это лучше, чем кушать рукой… давайте, переходя дорогу, смотреть по сторонам, это лучше, чем не смотреть по сторонам...»
Вроде бы это всё относится к таким вещам, которые идут нулевым шагом: это само собой подразумевается.
Но каким-то образом индустрия попала в эти рамки, и если, скажем, по рынку труда пошла очередная волна моды на фреймворк или архитектурный подход, ты хошь-не хошь, а выучишь. Чтобы участвовать в том, что не имеет особого смысла.
/* pechal' mode off */
как только они решили, что MapReduce недостаточно хорошо работает для построения поискового индекса, они перестали его использовать.
а что они сейчас используют? где можно об этом прочесть?
Вопрос на засыпку: Нужен ли Kubernetes если вы не Google? Несколько раз присматривался, но каждый раз решал, что слишком сложно и не даёт ощутимого профита для оркестрации небольших (20-30 сервисов) SOA-приложений в контейнерах на пятке серверов в одном ДЦ — вполне достаточно docker swarm, docker-compose и bash.
Есть другие мнения?
Вы — не Google