В последнее время я как-то подозрительно часто наблюдаю примитивнейшие однотипные и довольно легко решаемые проблемы на самых разных web-проектах. Разные базы, разные языки, разные сферы деятельности и схемы монетизации. Всех их объединяет одно — лозунг «бизнес не дает переписать». Продолжающийся или только-только оконченный этап рапид-разработки растущего и агрессивно отжимающего у конкурентов долю рынка проекта родил огромную кучу т.н. «говнокода». Сомнительные архитектурные решения либо уже приносят кучу проблем, либо обещают их в будущем, но работают. Поток новых требований не дает времени навести порядок даже в инфраструктуре, не говоря уже о коде. Если вам такая ситуация знакома — добро пожаловать под кат поностальгировать, поучиться чему-то новому и/или поучить нас. Кому поржать, а кому и поплакать.
«Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.
Проблемы №1: база.
Самые неприятные проблемы на любом web-проекте всегда связаны с базой данных. Все остальное мы легко умеем скейлить — от DNS-balancing до директивы upstream в конфиге nginx. «А как же кластеризация?» — спросит вдумчивый читатель. В этом-то и проблема. Я в третий раз наблюдаю кластер насилуемых баз данных. Дважды MySQL и однажды MongoDB. Индексы не настроены, таблицы (коллекции — какая разница?) не чистятся, зато проплачены недешевые серваки под кластер. И в основном эти серваки заняты разгребанием непроиндексированных данных и построением неиспользуемых индексов во имя энтропии.
Особенно распространена эта группа проблем в конторах, практикующих модную нынче тенденцию отделения backend-разработчиков от админов/DevOps/NOC.
Почему страшно держать базу в уставшем состоянии? Да потому что потеряете к чертям все: заказы, клиентов, SEO page rank. Да и зачем хостеру переплачивать?
Лично у меня, испорченного нищим детством, сразу же возникает крик души: не платите хостеру, заплатите лучше мне.
Еще из прекрасного: при наличии под ногами штормящей уставшей базы, и как следствие — несколькосекундный response у веб-сервера практически на всех страницах — проводить перформанс импрувмент, старательно не трогая базу.
Проблема «n+1»
Оказывается, есть два крупных типа изнасилования базы, хотя еще пару месяцев назад об этом, самом смешном из них, лично я и не подозревал. Вы слышали о «проблеме n+1»? Я вроде припоминаю что-то такое в глубоком юниорском детстве. В жизни бы не поверил, что что-то такое может прорваться на прод коммерческого проекта. Проще всего проблему можно характеризовать псевдокодом:
list = db.query('SELECT * FROM products;')
for (item in list){
orders = db.query('SELECT * FROM orders WHERE product_id = ?;', {product_id: product.id});
...
}
Идентифицируется проблема легко. Берем полный access log веб-сервера и query log базы данных за один и тот же период, и тупо сравниваем по объему. Если 50MB access log превращаются в 20GB query log — проблема идентифицирована. Из плохих новостей — вам придется модифицировать код, а там врядли вас ждет что-то хорошее, при таком-то отношении к базе.
Лозунг проблемы: webdev — это всего лишь преобразование действий пользователя в запросы к базе данных и вывод результатов. Все.
Наиболее сильно проблемой страдают go-программеры со своими горутинами. В меньшей степени она присуща адептам рельс, видимо привыкшим, что ActiveRecord на себя обычно берет такие проблемы. И встречается у php и js кодеров.
Сюда же можно отнести запросы вида:
SELECT p.*, ( SELECT count(*) FROM comments WHERE product_id = p.id) comment_count FROM products p WHERE author_id = ?;
Господа, это — не один запрос. Это тоже «n+1». Особенно прекрасный отсутствием LIMIT. Менять на JOIN (подзапрос с GROUP BY) — тоже не сахар, но если с индексами — жить можно. А вообще — это два запроса и сджоивание на уровне кода. Руками, если ваш ORM этого не умеет. Хотите — я дам либу для этого.
Проблема с индексами
Почему-то коллеги веб-разработчики отличаются завидным упорством в презрении к правильной индексации данных.
Идентифицируется проблема тоже просто: качаем, например, dev.mysql.com/doc/mysql-utilities/1.5/en/mysqlindexcheck.html или www.percona.com/doc/percona-toolkit/2.1/pt-duplicate-key-checker.html, запускаем, смотрим на длину списка лишних индексов. Если их много — база на проекте неухоженная, обязательно нужно проверять запросы. Если не нашли — включаем unindexed query log (в зависимости от типа базы по разному, гугл в помощь) и смотрим его. Если и тут ничего криминального — можем условно считать индексы проставленными аккуратно и перескакиваем к следующему шагу. Хотя опыт подсказывает что принцесса в большинстве случаев именно в этом замке.
Если же хоть один из вариантов дал выхлоп — готовьтесь к тяжелой и кропотливой работе. К сожалению, придется не только проставлять индексы где возможно, но и модифицировать код. Для MySQL, у которого в EXPLAIN SELECT нельзя получить «ROWS examined», вам понадобится полный query log (long_query_time = 0). Если эти данные грамотно агрегировать, то можно получить приятную статистику. Мне, например, нравится параметр sum(Rows Examined) — он показывает насколько данный тип запросов штормит базу. И еще — соотношение 95-х персентилей по параметрам «Rows Examined» vs «Rows Sent». Он показывает насколько данный тип запросов может быть оптимизирован. Аггрегатор можно написать самим или заюзать www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html. Но будьте предельно внимательны и аккуратны — ошибки в аггрегации приведут к куче потраченных впустую усилий. Применяйте декартов принцип универсального сомнения — любой механизм агрегации, в корректной работе которого вы не убедились лично, дОлжно считать потенциально глючным.
И не забывайте о ненулевой стоимости пересчетов индексов. Иногда лишний индекс страшнее отсутствующего. Минимизация количества используемых индексов — это первая задача, с которой столкнется, например, игнорирующий закон «если вы хотите использовать RDB таблицу для организации очереди — не используйте RDB таблицу». Но не последняя. Очередь прекрасно строится на механизмах
SELECT FOR UPDATE ... SKIP LOCKED; Наиболее часто непонимание индексов встречается именно среди php-разработчиков. Если мне не будет лень — я таки закончу обучающую статью на тему «чего не могут индексы и почему» для любителей PHP.
Оптимизация размеров таблиц
Еще помните утверждение, что недешевые серваки заняты исключительно увеличением энтропии — пересчетом неиспользуемых индексов и разгребанием непроиндексированных данных? Добавьте сюда безосновательно разросшиеся таблицы — и вы получите картину, соперничающую своей безжалостной дорогостоящей бесполезностью со Сколково или с оруэловской войной с целью утилизации перепроизводства. Позицию №1 в рейтинге самых очевидных и технически бездарных из всех известных мне причин разрастания таблиц занимает желание хранить устаревшие данные вечно. Например, в соцсети почему-то хранят удаленные сообщения вечно. Почему-то в основной, далеко не низконагруженной, таблице. И да, в той же самой базе.
Решение: как насчет дополнительной базы c префиксом zip? таблиц? mysqldump? backup?
Страшное: я встречал проекты, на которых из-за принципа «хранить вечно», нельзя было сделать ALTER TABLE из-за раздутости высоконагруженных централизованных таблиц. Как можно обеспечивать работу такой таблицы? Выдать штатным экстрасенсам бубны и истово молиться за здравие таблицы всем остальным? Зачем так жить?
Джоины
Запрос к 10 таблицам в вебе в продакшне может служить поводом для увольнения его автора и ревьювера, ИМХО. Господа, юнион, джоины и подзапросы 3-го уровня вложенности — это неплохой способ повыпендриваться. Или поискать что-то для себя в базе. Но никак не способ общения с бд хоть сколько-нибудь нагруженного проекта.
В том числе и из-за локов. Локи становятся проблемой задолго до того, как вы увидите дедлок в error логе. Да, количество локов можно сократить при единообразной сортировке условий типа parent_id IN(сортированный список id).
Ваша СУБД гарантировано не знакома с бизнес-логикой вашего же приложения и может только попробовать догадаться как именно будет лучше всего вытащить вам данные из десятка запрошенных таблиц. Знаете это только вы. Что, построить хеш-индексы в php и сджоинить два массива данных в памяти не сможете? А с библиотекой? Если не найдете — я покажу свою.
Проблемы с централизацией таблиц
В достаточно сложной асинхронной системе, в которую превращается любой крупный веб-проект, база и/или ее таблицы становятся ресурсами, поскольку являются блокерами для одних типов операций во время выполнения других типов. Например — пересчет индекса блокирует использование этого индекса и уж точно блокирует еще один пересчет.
Словом «ресурс» почему-то принято обозначать исключительно хардварные характеристики используемых систем — CPU, bandwidth, RAM. Но определить постоянный или пиковый недостаток таких ресурсов достаточно просто, корректные инструменты — munin/monit/sa+sar/htop и/или умеющий этим всем пользоваться грамотный админ — расскажут вам о ситуации все за небольшие деньги и в весьма приемлемые сроки.
Но вот относиться к таблицам в реляционной бд как к ресурсам никто почему-то не пытается. А ведь это — очевидное решение. Если UPDATE-запрос на таблице приводит к пересчету индекса, то ни один использующий этот индекс SELECT до окончания пересчета (ну или во время переключения, если вы верите в ровные руки авторов своей СУБД) выполнится, увы. В PostgreSQL при использовании immutable tuples любой UPDATE приводит к пересчету всех индексов таблицы.
UP1: по утверждению terrier PostgeSQL хорош для тех, кто умеет его готовить. Uber ошиблись и злобствуют. Не так чтобы очень удивительно. Помните утверждение Эйнштейна о бесконечности Вселенной?
В MySQL на первый взгляд все не так страшно. Но грамотно организованная высоконагруженная таблица несет в себе именно один-два важнейших индекса, и большинство апдейтов все равно приводит к их пересчетам. Зачем вам одна таблица на все типы продуктов?
Решение: создайте таблицу products2, обеспечьте непересечение значений ее первичного ключа с исходной таблицей. Наслаждайтесь. Если же какой-либо более-менее массовый тип продукта отличается по структуре от остальных — сама нормализация бд требует от вас всунуть его в отдельную таблицу.
Страшное: люди, любящие централизовывать таблицы, отличаются тягой к цетрализации (микро)сервисов при построении архитектуры. Не для них, видите ли, сказано «не инкапсулируйте в сервисы, инкапсулируйте в классы». На выходе получается то же самое — куча bottleneck с неочевидными причинами существования мешают скейлить систему при увеличении объемов данных и/или нагрузки.
Лозунг: не инкапсулируйте в сервисы, инкапсулируйте в классы
Проблемы №2 — код
На любом проекте любой программист всегда считает весь код говном, кроме того, который он пишет прямо сейчас. И то — не всегда.
Видимо, количество хорошего кода во Вселенной — величина неизменная. Какой-нибудь закон сохранения, как с массой-энергией или с деньгами. Поэтому когда программист пишет хороший код — какой-нибудь код в этот момент становится плохим.
Так что сверх минимума заморачиваться на качестве кода не стоит. CodeSniffer плюс code review на первом уровне code quality должны удовлетворить любые субъективно-оценочные критерии «читабельности» кода.
Глубже — хуже: лишние слои абстракции почему-то не отсекаются на этапе code review. Так же как и over-pattern-usage. Вы знаете когда нужен синглтон? Чтобы ограничить доступность ресурса, доступ к которому уже организован через создаваемый неуникальный экземпляр класса. Если синглтон пишется с нуля — вы получите в итоге антипаттерн в большинстве случаев. Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн. Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код. Скорее всего причиной можно считать то, что репозитории используются в stateless режиме — как группа функций схожего назначения. В отличии от конкурирующего с ним паттерна ActiveRecord, в котором сразу ясно что именно является состоянием.
При этом, на удивление, более простые и реально помогающие правила SOLID не используются. Да что там SOLID — не используется даже инкапсуляция из определения OOP. Такое ощущение, что веб-девы помнят что такое инкапсуляция только на собеседованиях.
Решение: показать, как правильно выстроенная иерархия именно интерфейсов (помните, проектируй на уровне абстракции?) позволяет создавать гибкие и легко дописываемые приложения.
Лозунг проблемы: лишние слои абстракции — это отстой. Думать надо не паттернами, а головой.
И да, вы же сами программисты. Вы верите, что бывают программы без багов? Все используемые вами инструменты — это тоже слои абстракции, только архитектурно-сервисные. Webdev — это превращение действий пользователя в запросы к бд и вывод результатов. Объясните мне где в этой формуле прячется apache? Вам действительно нравится видеть рассеянный по куче .htaccess-файликов роутинг?
Проблемы №3 — фронт
Самый презираемый класс программистов — яваскриптовики. Шутки про this. Отличительные признаки проектов, у которых фронтенд в стиле а-ля нулевые — куча подключаемых файликов и/или JQuery в смеси c ExtJS, и/или свой MVC велосипед, навевающий на мысли о раннем backbone.js. То есть — абсолютно неподдерживаемый код, неоправданно дорогостоящий на любых модификациях, априори глючный и костыльный.
Решение: нормальный, es2015 javscript. Одностраничное приложение с роутингом, а не куча конфликтующих jQuery плагинов и условий. Единая точка входа. Постепенный эволюционный перезд, начиная с роутинга. Обоснованный и вдумчивый выбор архитектуроопределяющих технологий. Например, TypeScript противоечит самой идее JS: анархия, раздрай и полный бардак высококачественной рапид-разработки. ИМХО конечно же.
Проблемы №4 — окружение
Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки. Ну так мы ж и не дизайнеры. Ну тут продолжать не стану, не холивара ради статью кропаю.
Я не понимаю как можно разработчику настраивать свое дев-окружение не самому. Да, пусть новичок пару дней сам пострадает с установкой проекта. Ну так сразу будет виден его уровень: по задаваемым вопросам и нерешенным самостоятельно проблемам. Точно так же новичок и сам многое о проекте поймет.
Я не понимаю как можно кодить с выключенными ворнингами. Бесплатное раннее обнаружение ошибок не нужно? Неужели действительно проще нанять еще один отдел тестеров?
Я не понимаю как можно жить без бета-площадки. Где же будут пастись эти лишние отделы тестировщиков? Как обеспечить zero-time-deployment без беты я не представляю тем более.
Я не понимаю как можно без zero-time-deployment. Контору че, не штрафуют за downtime сайта?
Я не понимаю как можно держать проект в продакшне, не имея настроенной системы интеграционных тестов. Что, сложно поставить Jenkins и всунуть скрипт, который раз в час будет логиниться / регистрироваться / проверять почту / покупать / продавать и паниковать при ошибке на почту / смс / хипчат? Неужели не хочется узнавать о проблемах не от клиента? Ах, да не штрафуют.
Я не понимаю как можно держать весь код вместе с конфигами в веб-руте? А вы точно везде deny from all прописали? Не тянет перепроверить?
Я не понимаю как можно раскручивать сайт, у которого несколько секунд время загрузки страницы. Это же дорого!
На этом перечень решаемых с технической точки зрения проблем заканчивается. Дальше начинаются…
Проблемы организационного характера.
Далеко не все из них решаемые, к сожалению.
Проблема №0: коммуникации.
С бизнесом можно разговаривать только на языке бабла. Он не восприимчив к красоте решений, нормализации базы, CAP-теоремам и прочим IT-ценностям. Он понимает деньги и сроки.
Решение: подобрать из беклога несколько таких задач, чтобы можно было и обосновано и честно заявить клиенту, что эти задачи будет дешевле имплементировать на переделанной системе, даже с учетом переделки. Если ты не можешь подобрать и обосновать перечень задач — уйди мальчик, тебе еще рано переписывать систему. Задачи, если что, лучше подбирать посвежее — клиента к ним тянуть будет сильнее. Да и не придется отвечать на вопрос «почему решились только сейчас?».
Лозунг: бизнес никогда не дает переписать. Пишите сразу нормально.
Проблема №1: управленчество
Говнокод сам по себе не рождается. Посмотрите на микромягких — авторитарный стиль управления Билла, позволяющего себе орать на подчиненных и срывать им сроки, родил настолько идиотские архитектурные и/или технологические решения, что даже конечные пользователи понимают, что страдают от их последствий. Отличителным признаком проблемы можно считать фразу «все программисты всегда хотят все переписывать. Мы не будем».
Что делать: убеждать. Например, через статьи на хабре. Или уходить. Это — единственная проблема, которую нельзя решить системно без топора.
К этим же проблемам можно отнести «централизацию людей» — самые толковые люди настолько заняты и контролируют столько вещей, что не могут вникнуть ни в одну из них. И вечно надо ждать принятия ими решения. Ну чем не bottleneck?
Решение: микрокоманды.
И да, продолжая параллели с архитектурой приложения — лишние слои абстракции здесь тоже sucks. Back in USSR, когда на каждого работягу два управленца. Ну так у них труба нефтегазовая была. И есть.
Чем меньше ушей на пути информации от источника требований до их осуществителя — тем лучше. А то получается как картинка-история с качелькой. И пара отделов лишних нахлебников — менеджеров, занятых войной с JIRA / Redmine и/или выполнением распоряжений других менеджеров.
Самое главное — не опускать руки. Ведь, возможно, вы в самом интересном этапе — написание платформы устаканившегося денежного проекта. Прекрасная строка в резюме если что, а пока — замечательная финансовая подпитка. Предаставляете, например, как поднимет вашу ставку небрежно брошенная на собеседовании фраза «избавился от несколькотерабайтной базы»?
И конечно же все, кому есть чем дополнить и/или подкорректировать данный список — добро пожаловать в комментарии.
Комментарии (173)
Odrin
25.05.2017 18:18Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн.
Слабая связанность, гибкость и расширяемость, лучшая читаемость и переиспользуемость — это теперь зовется «атипаттерн»? SOLID, не?
Самый презираемый класс программистов — яваскриптовики
У Вас какие-то комплексы на этот счет? Так-то адекватные люди не разделяют коллег по языку программирования.
Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки.
А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать? Или только «мы ж и не дизайнеры»?Shifty_Fox
25.05.2017 19:50+1Я бы даже сказал, есть не очевидный плюс windows платформы. После всех набиваний шишек, в вашем git репозитории точно уже не будет:
— внезапных проблем с \r \n
— проблем с путями "\"
— проблем с путями, отличающихся лишь регистром
и даже больше, на ходу вспомнилось пока это
phgrey
25.05.2017 20:16+2Я бы отнес это к минусам, но холиварить отказываюсь, если что.
rdifb0
31.05.2017 11:12+1Какие-то двойные стандарты получаются на мой взгляд.
Вот вы ниже в ответ на
А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать?
пишете
А линукс заставляет думать. И уметь.
А тут получается если нужно задумываться про разные разделители путей, новой строки и регистрозависимость файловой системы — это минусы.phgrey
31.05.2017 13:55разделители путей и тип новой строки — это такие смешные проблемы, что я, простите, о них уже и не вспомню. надеюсь, никогда.
посыл изначально был о том, что под линухами даже конечным пользователям приходится решать проблемы, достаточно сходные с деплоем web проекта, к примеру. как мимнимум тренирует навыки StackOverflow-driven-development.
Ruckus
29.05.2017 13:23Простите, но какие из этих проблем у вас возникали не под Windows?
Я вот с переходом на Windows испытываю проблемы:
1) С кодировкой (да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866 на выдаче VC компилятора)
2) Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
3) После шиндовспрограммистов приходится долго и муторно править регистры путей, а бэкслэши вместо слэшей у всех остальных ОС добавляют смеху, ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет.
Итого: если у вас сервера на винде — могу вам только посочувствовать, а если на *nix, то вы огребёте проблем при деплое после разработки на винде. Где тут профит я не вижу.Shifty_Fox
29.05.2017 14:21В этом и плюс, после Windows у вас в проекте не будет таких проблем, когда будут приходить другие Windows программисты, т. к. вы сами эти проблемы и решите.
Ruckus
29.05.2017 15:17Ещё раз — проблемы будут на деплое. Или я должен следить за всеми? Или код под диктовку писать чтоб никто не косячил? Да и невозможность таких «ошибок» явно лучше их исправления.
Я вообще негативно отношусь к Windows и Windows программистам так как считаю, что хорошее ПО должно быть кроссплатформенно и для этого сейчас есть всё, что необходимо, а разрабатывать под виндой это как кактус есть хотябы потому, что консоль и кодировки.Shifty_Fox
30.05.2017 03:31+1Хуки на гите, отсутствия в проекте файлов вида *.lua и прочее — вот это всего не будет, потому что наличие windows разработчика означает что проект собирается и работает под windows.
Не очень понял чем работа в Windows мешает кроссплатформенности. Наоборот, если вся команда на linux, кто тогда делает порт на Windows?
Консоль… вы можете поставить любую консоль. Bash, powershell, etc
Как и окружение. Все прекрасно настраивается, кастомизируется. Заметьте, Linux из коробки тоже не огонь.phgrey
30.05.2017 09:23-1К сожалению, наличие windows-разработчика на проекте чаще означает корявые коммиты в CVS и прочие проблемы, чем их отсутствие.
Ruckus
30.05.2017 09:59Ну то есть вы говорите «давайте будем снисходительны к программистам под виндой». Ну как бы ок, я понял. Вы даже вероятно правы по поводу того, что в кроссплатформенном ПО проблемы всё равно придётся решать.
Чтож, пусть каждый пишет где ему нравится, я как и прежде буду считать, что это АД.
А Linux из коробки (без GUI) для серверов норм.Shifty_Fox
30.05.2017 16:17+1Ну вот я снисходителен к Linux разработчиком, чьи проекты не запускаются на Windows из репозитория, хотя должны, т. к. используют кроссплатформенные инструменты. Логично ожидать подобного.
Ruckus
30.05.2017 16:39Лучше пинать обоих, может начнут писать нормально =)
Вообще смотря на чём, я сталкивался только с C++, так вот кто-то мне уже тут говорил, что если писать в соответствии со стандартом, то никаких проблем не будет, а платформозависимые функции стандартом не назовёшь, не говоря уже о неопределённом поведении.
mayorovp
30.05.2017 11:01-2да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866
А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных? Если хоть выбрать любую из них, то потом в крокозяблы превращаются даже маны… Интересно, зачем вообще в настройки добавляют опцию, которая не работает? :-)
Что же до проблем с кодировкой на винде — то на самом деле проблема не в винде, а в американских разработчиках, которые эти кодировки игнорируют. Почему-то мои программы проблем с кодировками не испытывают.
Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
Не путайте Windows и Notepad. Это немного разные программы.
ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет
На самом деле понимает, только надо не забывать заключать пути в кавычки.
Ruckus
30.05.2017 16:25+1А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных?
Ниразу не видел, увы. В любом случае есть возможность «сделать хорошо», в винде такой возможности нет совсем.
Почему-то мои программы проблем с кодировками не испытывают.
Мне сложно говорить за всех, я тут в установщиках стабильно наблюдаю кракозябры. И повторюсь про VC компилятор, IBM866 ни в какие рамки, пришлось использовать английский, иначе не лечится.
Не путайте Windows и Notepad. Это немного разные программы.
Я вас, вероятно, огорчу, но разработчик один и Notepad входит в стандартную поставку без возможности выпилить. Да и были программы (за давностью лет не помню какие), которые делали то же самое.
На самом деле понимает, только надо не забывать заключать пути в кавычки.
К сожалению часто берутся относительные пути, а комбинации '\' и '/' винда не приветствует даже с кавычками. Во всяком случае у меня не вышло, но может руки неоттуда?
Вообще всё это холивар, который по факту не приведёт к моей любви к этой ОС или вашей ненависти. Вы либо работаете только с Windows, либо не программист, ну я не знаю других причин почему её можно любить.
TSR2013
30.05.2017 16:41На самом деле есть еще вариант кросс платформенного приложения под Win/OS X + веб сервисы. Разрабатывать под винду из под Wine то еще "удовольствие". Для комфортной разработки под OS X так или иначе желателен мак. Зато весь веб стек заводится с полпинка на Windows. Вопрос c консолью тоже закрывается очень легко. У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие. Сейчас вот появилась еще Windows Subsystem for Linux. Вопрос \n vs \r\n тоже закрывается прямо при установке git (checkout \r\n push \n). Раньше еще был плюс в виде Notepad++ — на глаз один из самых быстрых редакторов в плане открытия файла. С выходом VSCode это уже не так актуально.
Правда есть один нюанс. win10 ужасно не стабильная и тормозящая ось. А вот win7 была вполне себе ничегоRuckus
30.05.2017 16:51-1Зато весь веб стек заводится с полпинка на Windows
Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
А если это был упрёк, что веб-стэк трудно завести где-то ещё, то вы снова сильно ошибаетесь, на windows его завести по моему опыту сложней всего в сравнении с другими ОС. И да, win10 невозможно пользоваться, я уже второй месяц в этом убеждаюсь.
Раньше еще был плюс в виде Notepad++
Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.
У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие
Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.mayorovp
30.05.2017 17:20-1Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.
Ну и в чем в таком случае проблема?
Ruckus
30.05.2017 17:58Вы это к чему написали? Проблемы описаны выше — наличие у Windows ряда исключительно собственных решений, которые приводят к конфликтам при разработке и не только. А IDE и редакторы тут вообще не при чём.
mayorovp
30.05.2017 18:01К тому, что вы вольны не использовать эти решения, если они приносят больше проблем, чем пользы.
Если вы используете JetBrains или Sublime — то наличие в винде кривого Notepad вашей проблемой не является.
Ruckus
30.05.2017 18:04Если бы в команде работал только я проблем бы не было вообще, но крайне редко над продуктом работает один разработчик.
mayorovp
31.05.2017 07:02Этот разработчик волен не использовать эти решения, если они приносят больше проблем, чем пользы.
Если он выбрал такие решения, а сопутствующие проблемы перегружает на других разработчиков — это проблема не винды.
TSR2013
30.05.2017 17:21А если это был упрёк, что веб-стэк трудно завести где-то ещё
Нет как раз наоборот. Веб стэк легко завести на чем угодно OS X/Win/Ubuntu/CentOS итд
Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
Я лично без проблем заводил под Win node.js, php/nginx, php/apache, golang, rust(правда на ранних версиях была проблема с openssl), java бэкенд. Мне кажется это покрывает процентов 80 всех вариантов
Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе.
JetBrains тяжеловат, плюс к тому будучи написанным на java работает на любой оси. Sublime — да, неплох
Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.
мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
Ruckus
30.05.2017 17:54мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
Вы не в ту сторону подумали. Права, согласовать, заставить с этим работать всех разработчиков (когда ты один на Маке, целевая Android, но тестовый интерфейс на Qt должен работать на винде, ибо частично тебе с базой «помогает» Windows-программист). Не тривиальная задача настроить сборку в три платформы с минимумом доп утилит и одним методом, ещё и чтоб это работало у каждого в своей IDE.TSR2013
30.05.2017 18:00+1По вашему комментарию (https://habrahabr.ru/post/329478/?reply_to=10241628#comment_10241608) понял о чем Вы говорите. Да с C++ есть проблемы в области кроссплатформенности. Есть какие то подвижки в правильном направлении (например при использовании CMake) к унификации, но в плане организации сборки, нормального кроссплатформенного решения я не нашел. Хотя мне кажется здесь проблема глубже. В С++ не хватает общего пакетного менеджера и нормального управления зависимостями. Может быть если бы приняли модули в 20 стандарте стало бы проще организовать сборку
mayorovp
30.05.2017 17:17а комбинации '\' и '/' винда не приветствует даже с кавычками
Ничего подобного, они работают в любых сочетаниях.
Ruckus
30.05.2017 17:48C:\Users\rucku>Xcopy /Y /E "../rucku/SDK.h" «F:/»
0 File(s) copied
C:\Users\rucku>dir
…
07.04.2017 13:34 204 709 SDK.h
…
C:\Users\rucku>Xcopy /Y /E "..\rucku\SDK.h" «F:\»
..\rucku\SDK.h
1 File(s) copied
Конечно, работает, только не везде видать.TSR2013
30.05.2017 19:50Если Вас интересует именно вопрос копирования можно использовать http://gnuwin32.sourceforge.net/
c:\GnuWin32>cp ../GnuWin32/readme.txt ./var c:\GnuWin32>cp ..\GnuWin32\readme.txt .\var
Обе команды делают одно и то же
Есть еще cygwin, MinGW32 и WSLRuckus
30.05.2017 21:19Мы говорили про консоль Windows или как поставить линуксовый софт/виртуалку? Накатив кучу софта все могут, а вы попробуйте убедить пяток разработчиков, которым это всё до лампочки, что надо это ставить. Или пользуйтесь тем, что есть по умолчанию.
Я серьёзно сталкивался с этой проблемой и серьёзно решал её через родные средства (за исключением make/cmake).
phgrey
25.05.2017 20:12+1«У меня нет комплексов, я просто хочу делать это только с тобой» (с) «От 180 и выше».
А вообще-то имелась в виду ситуация, когда бекенд-разработчики презрительно относятся к фронтенд-разработке. Особенно это комично в случаях, когда последние получают больше.
По поводу Dependency Injection — покажите как вы его используете. И сколько программистов и пилят именно тот код, в котором используется DI?
Lailore
26.05.2017 07:14+3Мы например используем одну доменную область для веба и для мобилок. Без ди это был бы угар, ад и содомия. А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу. И без ди очень трудно отслеживать общие объекты. Хотя может это и не так заметно в пхп, где все живет только с запросом.
+ очень удобно подцеплять, отцеплять декораторы и перехватчикиnightwolf_du
26.05.2017 13:24+1А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу
это отсылает к аргументу phgrey —и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x.
.
Если потратить на solid немного больше времени — начинаешь замечать, что часть принципов противоречит друг другу, и тянет архитектуру приложения в разные стороны. D тянет в слабую связанность, но на связность влияет скорее отрицательно. S повышает связность, но может негативно сказываться на связанность.
D+S+O дают много лишних интерфейсов, связанных с абстракцией реализации, а не абстракцией предметной области.
D+S+O+I легко нарушают kiss & yagni. Всё равно приходится идти на некоторые компромиссы.
А еще DI одинаково легко развязывает слои приложения и превращает код в di-лапшу из интерфейсов и реализаций, наследующих друг друга.mayorovp
26.05.2017 13:32Зачем конфиг-то? Достаточно настраивать DI в Composition Root.
Lailore
27.05.2017 10:45+1Конфиги это наследие прошлого, и тех кто везде хочет поздного связывания. Хотя это надо очень и очень маленькому функционалу и в редких случаях.
Я напримар использую автоконфигурирование, после явную регистрацию через код для сложный моментов. После идет конфигурация через конфиг файл, но мне это потребовалось всего один раз за всю карьеру(по сути это было больше для тестера, что бы он мог сравнивать несколько конфигураций кода, когда ему нужно было. когда было принято решение это улетело в автоконфигурацию)
Lailore
27.05.2017 10:28Безусловно каждый принцип можно довести до сумашествия. В этом и задача, что бы найти баланс и не проседать по любому из пунктов.
phgrey
31.05.2017 14:20вы абсолютно правы, DI обретает дополнительные плюсы при использовании в долгоживущем приложении.
phgrey
25.05.2017 20:20-1А линукс заставляет думать. И уметь.
Psih
25.05.2017 22:04+2Vagrant :)
И никаких проблем. Вообще. И шрифты в IDE приятные, да и в прочих программах тоже :) Ну да, нужно всего-лишь хотеть чуть чуть разобраться и может быть где-то потратить час на то что-бы исправить какую-то шероховатость один раз потому что разработчики оголтелые маководы и на линуксе у вас будет та же самая проблема :D
Серьёзно, оголтелые маководы последнее время становятся хоть и мелкой, но назойливой проблемой.phgrey
25.05.2017 22:11+2Маководы — братья по unix. Я там kernel panic вот этим вот глазом видел. И GNU tools там в норме. И brew есть. И путь нормальный.
Если пользователь Windows разобрался с vagrant — то это наш человек, просто зачем-то насилующий себе разум.
Линуксоиды, по какой-либо причине юзающие иногда Окошечки — игры, фотожаба, мультимедиа, ie — не в счет.
chupasaurus
25.05.2017 23:38Пришлось однажды «братьям по UNIX» передавать пинок в Slack с подписью
потому что они умудрялись в одной директории называть файлы с однотипными префиксами а-ля OneTwo* в названии всеми возможными комбинациями заглавных букв.git config --system core.ignorecase falsephgrey
26.05.2017 00:00не совсем понял проблему:
OneTwoABBASD — рандом или цикл, не? к /tmp не приучены?
или OneTwoCamelCase в именах файлов напрягает?chupasaurus
26.05.2017 20:05+1Все яблочные ФС — case-insensitive, в отличии от + git init/clone по умолчанию на маках включает ignorecase. Начинаешь сборку или хуже — деплой, и удивляешь товарищей об отсутствии файлов.
Viknet
26.05.2017 21:30Тут надо отметить, что HFS+ имеет режим case-sensitive и система вполне нормально на ней работает.
Есть очень небольшое количество приложений, которым от этого сносит крышу (например Steam).
phgrey
25.05.2017 22:22по поводу «разобраться» — согласен на 300 процентов. Просто к некоторым проблемам привыкаешь и однажды при dist-upgrade просто лень гуглить.
Aingis
26.05.2017 21:29-4Линукс заставляет тратить много времени. И это дорого. Очень дорого.
Бизнес понимает только язык денег, не так ли? Как вы обоснуете удорожание разработки минимум в два раза?
Для веб-разработчиков на Виндах есть родной (читай: не тормозящий в виртуалке) IE/Edge. На маках Safari. А?ещё там всякий фотошоп, и куча утилит, большая часть которых на линуксе не работает или не поддерживается. Что веб-разработчику искать на линуксе не представляю.
Aingis
28.05.2017 17:41-4Типичный хабр: обоснованных возражений по сути нет.
phgrey
31.05.2017 14:21+1ага. глупцам и наглецам тут грустно
Aingis
31.05.2017 20:54-4Однако, это не мешает таким фанатикам минусовать комментарии со здравым смыслом, когда аргументов у них совсем нет (самих заминусуют).
vyrkmod
01.06.2017 09:50+2Установка серверного софта — одна команда в консоли, правка пары конфигов (обычно разработчику даже не нужна) и ещё команда на перезапуск сервисов. Если понадобится что-то специфичное — можно в процессе установки инструкцию админу писать, благо на сервере тот же линукс. Браузеры — лис и хромиум, никаких виртуалок под них не надо. IDE нынче кроссплатформенные; psd открывается gimp'ом, для вёрстки этого вполне хватает, если очень нужен именно фотошоп — под вайном он работает; что за «куча утилит, большая часть которых на линуксе не работает» — ума не приложу. А ещё рабочее место выходит дешевле, поскольку не нужно покупать лицензию на винду.
Лучше обоснуйте свой тезис про потраченное время, я как-то не замечаю чтоб из-за выбора оси я тратил по четыре лишних часа в день.Aingis
01.06.2017 10:43-4Вы ветку вообще читали? Какое это отношение имеет к фронтент-разработчикам?!
Браузеры — лис и хромиум
А-ха-ха, тра раза!
psd открывается gimp'ом
Сразу видно, что вы не открывали типичный PSD гимпом. Он половину информации теряет.
А ещё рабочее место выходит дешевле, поскольку не нужно покупать лицензию на винду.
Разработчик, умеющий в линукс обходится куда дороже.
Покажите реальный баланс, а не рассуждения диванного теоретика.
Лучше обоснуйте свой тезис про потраченное время…
Вы это про какой?
phgrey
01.06.2017 10:46frontend в ветке не упоминался. только в вашем профиле
Aingis
01.06.2017 14:22-2Ветка началась с [комментария](https://habrahabr.ru/post/329478/#comment_10234706):
Веб-разработка — синоним фронтенд-разработки. Зайдите на любой сайт вакансий и вы это увидите. Если вы называете бэкендеров, которых обычно называют соответственно языку разработки, то у вас каша в голове. Надо чётко говорить, что вы имели в виду.Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки.
А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать? Или только «мы ж и не дизайнеры»?
Потому что изначальный тезис опровергается всей практикой. Почему если это так круто и дёшево никто так не делает? Именно потому, что невыгодно иметь админа на каждого веб-разработчика.
vyrkmod
01.06.2017 11:27Везде вижу «веб-разработчиков», и не вижу «фронтенд».
Вы это про какой?
Линукс заставляет тратить много времени. И это дорого. Очень дорого.
Aingis
01.06.2017 12:09-4Это синонимы, если вы не в курсе.
vyrkmod
01.06.2017 12:19+2То есть если я пилю серверную часть для SPA или приёмник платежей от paypal/qiwi/whatever — я не веб-разработчик? Вот те раз! И мне по-прежнему интересно, куда же меня «линукс заставляет тратить много времени».
Aingis
01.06.2017 18:54-3Нет, вы бэкенд-разработчик. Откройте любой сайт вакансий и посмотрите кого там ищут на веб-разработчиков. Фронтендеров. На бэкенд так и пишут: или бэкенд, или конкретный стэк. Ну и да, уровень вашей аргументации типично-хабровский: ни одного обоснования и факта, одни домыслы.
baldrs_asgaardson
25.05.2017 20:43+4Так стек же весь с пол оборота заводится, например docker-compose проект расшарил в команду и у всех одинаковое окружение, все инструменты нативные и работают как надо, костыли никакие не надо. На windows 10 помню пытался настроить окружение для разработки, но там постоянно что-то приходилось подпирать костылями, потому как все работало не совсем так. WSL конечно сглаживает эту проблему, но не до конца.
TSR2013
25.05.2017 18:26+2Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.
Если репозиторий не нагружать лишними функциями, то вполне себе рабочий вариант. Репозиторий должен кэшировать результаты и выполнять запросы в базу. Все остальное лишнее. Мне кажется куда более часто встречающаяся проблема это увлечение god object и не умение найти баланс в делении кода на атомарные логические сущности
phgrey
25.05.2017 20:24Скорее всего причиной можно считать то, что репозитории используются в stateless режиме — как группа функций схожего назначения. В отличии от конкуриющего с ним паттерна ActiveRecord, в котором сразу ясно что именно является состоянием.
При активной работе над кодом нескольких программистов зачастую приходится специально договариваться по вопросу какие функции считать лишними, а какие — нет. В AR действительно получается проще договориться что к чему относить.
VMichael
25.05.2017 19:35Вот же оно — решение всех проблем!
Просто нужно следовать статье.
Ну, в общем то я тоже за все хорошее, против всего плохого.
Поддерживаю в этом.
Но думаю, не стоило все сваливать в одну кучу.
Попробуйте написать по каждому пункту по отдельной статье, с примерами и нормальной аргументацией, тогда может быть гуд.
А в таком виде, это просто метнуть лопатой на вентилятор.phgrey
25.05.2017 20:13это чек-лист тащемта
VMichael
26.05.2017 00:32+3Тащемта — это что означает?
А где, собственно чек лист?phgrey
26.05.2017 00:41+1тут еще один зануда проходил, говорил что правильно — чек-лист.
ну вот же — 1, 2, 3, 4 — списки проблем которые нужно проверить. с пояснениями.
тащемта в основном используется в смысле «вообще-то». И вы так спрашиваете, как будто это что-то плохое.VMichael
26.05.2017 00:52+5Спросил, потому, что встретил первый раз.
Чем ваше «тащемта» лучше «вообще-то» мне не понятно, зачем бессмысленно коверкать язык не понятно. Вроде любители албанского поутихли. Ну это так занудство.
Про чек-лист.
Вот у человека проблема некая, с сайтом (или про что ваша статья?)
Прочитал он ваш «чек-лист» и что сможет сделать?
Да ничего.
Чек-листы они очень конкретны и по очень узкой теме делаются, если вы их использовали, должны понимать. Своего рода памятка.
От слова «чек», галочка.
Проверил, чекнул, поставил галку.
У вас не чек лист.
У вас статья «О наболевшем».
Какую галку человек должен поставить на разделе «Управления»?
Типа, Проверь управление.
Сразу вопросы. Кто этот чел, проверяющий? Владелец бизнеса, программист?
Ага, проверил. Не микрокоманда. Микрософт.
И что?
Бежать к руководству с предложениями изменить разработку?
Или срочно увольняться оттуда?
А куда рвануть? В Гугл?
Самому не смешно?phgrey
26.05.2017 00:57+1это не албанский, а прикольная опечатка. оказывается, ее можно использовать для выявления холиварщиков.
что делать? внимательно перечитать комментарии и искать специалиста. я могу двух показать. договариваться об удаленном аудите за сколько скажут.
не можете? обнять коленки и плакать.VMichael
26.05.2017 01:00-1Так и напишие статью:
У вас косяки с сайтом(или чем там еще), ответ — ищите специалиста.
Коротко и смысла столько же.
Да, впрочем ваше дело, графоманьте дальше, не обращайте внимание, вам всяко лучше знать, как составлять чек-листы.phgrey
26.05.2017 01:05если не холиварить — у специалистов можно учиться. гуглить что там тебе советуют. смотреть, пробовать. понимать. даже спрашивать.
это мне чек-лист если что.
phgrey
26.05.2017 02:01+1что делать неспециалисту? учиться задавать вопросы на английском языке.
в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.
ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.
Acuna
25.05.2017 19:44-1Спасибо за статью. Такие замечания обычно предлагаются в личке, однако я бы хотел оставить его публично, в надежде чтобы его увидело большее количество людей, ничуть не пытаясь задеть чувства автора и прохожих (а вдруг).
Если можно, заголовок бы подправить: «чек-лист» пишется через тире. Это составное слово, такое, как всем известное со школы «диван-кровать», они всегда пишутся через тире, ибо правило гласит:
Сложные существительные, образованные без соединительной гласной, каждая часть которых может употребляться как самостоятельное слово, пишутся через дефис.
Замечаю просто сейчас в последнее время какую-то нездоровую тенденцию к их употреблению исключительно в таком виде, что, если честно, реально вымораживает. Ладно бы если изначально они писались бы верно, то тенденция пошла бы правильная, как это часто бывает, однако кому-то стоило начать писать не верно, с тех времен и клонируется… Заранее благодарен!
leorush
26.05.2017 13:23Разве «чеклист» — не заимствованное из английского слово «checklist»?
В русском с этими дефисами в заимствованных словах что-то странное.
Вот взять хотя бы «дедлайн» вполне можно употреблять отдельные части самостоятельно.
Но дефис не пишут.Acuna
26.05.2017 21:18В правилах увидел и другой пункт, касающийся уже непосредственно заимствованных слов, который точно в кассу: «сложные существительные с иноязычными элементами», но время редактирования коммента уже истекло к тому времени.
А насчет дедлайна — да, согласен, так уж завелось, так все и пишут. Но в любом случае, никак не раздельно)
KTF
25.05.2017 20:15Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.
Автор, можете аргументировать более развернуто? Согласен с предыдущим комментарием: если не пихать в репо все подряд методы, код получается вполне чистым.
Fen1kz
25.05.2017 22:42+2Запрос к 10 таблицам в вебе в продакшне может служить поводом для увольнения его автора и ревьювера, ИМХО. Господа, юнион, джоины и подзапросы 3-го уровня вложенности — это неплохой способ повыпендриваться.
Не очень понял альтернативу. Вот есть данные, лежат в 10 таблицах, надо их всех показать.
Вместо запроса к 10 таблицам делать 10 запросов?
phgrey
25.05.2017 22:44да. хотите сравнительные результаты нагрузочного тестирования?
TSR2013
26.05.2017 00:01+2А можно какие то пруфы данного утверждения? Просто если с подзапросами я согласен, то join при правильном проектировании БД обычно проблем не вызывает. Обычно на мускуле самая большая проблема group by. Уже на 20млн записей посчитать статистику становится проблемой
darthunix
26.05.2017 07:28+7Простите, я правильно понимаю, что вы предлагаете вытащить данные из 10 таблиц, передать их по сети, реализовать через сторонние библиотеки на другом сервере хеш соединение в памяти… и утверждаете, что это быстрее, чем нативная реализация СУБД? Я пользуюсь PG и могу точно сказать, что соединения в базе быстрее. И слабо верю, что в MySQL оно работает сильно хуже
phgrey
26.05.2017 09:01Абсолютно правильно понимаете. Более того — я уже наблюдал результат такой оптимизации. Дважды. Про постгрес верю, но хочу спросить — на каких объемах данных и нагрузках?
Не сразу понял про соединение.
OlehR
26.05.2017 09:58+4Даное утверждение бред. Движки БД заточены на join. У mysql были проблеми с подзапросами (спигнул с него в достаточно давно на более взрослие БД. Поетому не скажу на сегодня, надеюсь исправили. Но и ето легко решалось временними таблицами). Но если правильно написать запрос и план будет логичним — никакой внешний движок не получит прироста при прочих равных условиях.
Положительний результат можно било получить только в условиях полного «топорного» использования БД.
darthunix
26.05.2017 13:57+2Могу сказать, что у меня идут запросы с агрегациями по соединениям таблиц, в каждой из которых около миллиона записей. Соединяются от трех до пяти таких таблиц. Соединение идёт по покрывающим индексам и почти не трогает сами таблицы, то речь менее чем о сотне мс. Суть в том, что агрерация идёт в pipeline mode по покрывающим индексам и на клиент уходит компактная свертка результатов в пару сотен строк. Если же делать по-вашему, то нужно выкачать несколько миллионов строк с дисков, отослать их на другой сервер и там повернуть ту же самую свертку в памяти в компактную таблицу, но без кучи оптимизаций по работе с общими буферами PG и буферами ОС. Если хотите, напишите предложение по тесту, я его прогоню по-своему и по-вашему.
mayorovp
26.05.2017 14:26+1По-хорошему, такие агрегаты должны храниться и обновляться отдельно если они действительно часто запрашиваться.
Напомню, речь шла не о редких аналитических запросах, а об основных запросах веб-приложения к базе. Такие запросы нельзя держать настолько сложными.
darthunix
26.05.2017 18:49У вас в статье не шла речь про веб приложение, вы давали общие рекомендации. Я же вам привёл данные из работающей системы медицинских заказов на целый край. И это не редкий аналитический запрос, а типовая проверка для заказа направления между медицинскими учреждениями. Такие данные нельзя хранить отдельно и обновлять, они должны быть актуальны на любой момент времени. И они как то держатся настолько сложными и отлично работают в продакшене. Если вы пишите практики для простых веб приложений, то и указывайте об этом. Реальные промышленные системы обычно на порядок сложнее.
mayorovp
26.05.2017 18:59У меня в статье?
И, кстати, не вижу никаких причин, по которым данные, хранящиеся отдельно, не могут быть актуальными в любой момент времени.
darthunix
26.05.2017 19:13Приношу извинения, автор не вы — пятница вечер))
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
phgrey
26.05.2017 19:59это моя статья и там в названии сказано что она про сайт))))
система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.
и какая, если не секрет, нагрузка на систему?
Cubus
26.05.2017 13:03+5Могу сказать за Oracle, что там сджойнивание таблиц за пределами базы — немыслимо чудовищный антипаттерн. Подозреваю, что и в PostgreSQL тоже.
yorick_kiev_ua
26.05.2017 14:06+7Да это антипатерн для любой ДБ. Если быстрее делать join «руками» чем стандартными средствами БД, то, простите, зачем вообще такая БД нужна?
Вообще «никогда не делайте join руками, умные дяди-разработчики движкоа баз даных потратили миллион человекочасо что-бы делать это максимально эффективно» — это совершенно капитанский совет, референом звучащий в абсолютно любом «проблемы перформанса для детсадовцев».phgrey
28.05.2017 10:09-1улыбнудо про «умных дядь-разработчиков».
вам, простите, приходилось поддерживать что-то со сходным с mysql-query-plan-builder legacy? Или с его же переменчивым набором требований? Как вы думаете, много там багов?
хотите влет пример JOIN, который я руками гарантированно сделаю быстрее, чем используемая на проде версия MySQL сервера?mayorovp
28.05.2017 13:02Если вы даете советы относительно MySQL — то так и пишите, а не пытайтесь обобщать их на любую СУБД.
PS
простите, зачем вообще такая БД нужна?
phgrey
31.05.2017 05:02холиварщики… они везде.
такая бд нужна для хранения данных привычным команде разработчиков способом. для получения из нее данных. для записи.
phgrey
28.05.2017 10:18-1Самое страшное во взрослении не то, что мы теперь взрослые, а то, что «умные дяди-разработчики» — это теперь мы.
OlehR
26.05.2017 10:26+1Я же не спорю что вы получили пруф.
Но ето возможно только если вы неправильно «готовите» БД.
О обемах с которими работаю > 600 Gb OLTP база с некоторими елементами DW редологов за сутки около 50-80Gb. Да и вся бизнес логика >500 000 строк в БД. И ето все крутитца всего на 2 ядрах Power 7+. При етом некоторие запросы на несколько екранов и десятки таблиц. Перед етим я работал с MYSQL с базами > 50Gb правда и сервера были послабее. Но я не могу представить ситуацию когда обединение таблиц будет быстрее вне БД. ( ведь будут накладние расходы — сеть, преобразование)
phgrey
26.05.2017 10:470.5M строк — это не показатели
CWN
26.05.2017 11:33+1это бизнес логика, а не строки в таблицах =)
Судя по "… редологов..", имеется ввиду Оракл, это его термин для бинарных логов.
А так да, join вне базы, это антипаттерн сравнимый с характеру с вашим примером «Проблема «n+1»»
Такая бомба замедленного действия.
coh
26.05.2017 11:41Интересно, шардинг тоже антипаттерн?
CWN
26.05.2017 12:10Теплое с мягким не путаем =)
Я так понимаю Вы имеете ввиду, что у вас есть большая зашарденная табличка, а справочники лежат все на одном инстансе в одном месте, и вот потом Вы пытаетесь на клиенте сопоставить данные вытащенные с шардов с данными из справочников. И тут надо смотреть насколько эффективно Вы это делаете, может оказаться так, что дублирование справочников по шардам — может оказаться эффективнее централизованного хранения, а может и хуже.
Тут ведь проблема с JOIN на клиенте в объемах, которые вы пытаетесь обрабатывать. Грубо говоря, вы сделали запрос с фильтрацией (WHERE) в БД из основной таблицы, а потом начинаете в полном объеме (без WHERE) подтягивать справочники чтобы сделать ручной JOIN. И, ВДРУГ, в какой-то момент оказывается, что у справочники то большие, а в результате фильтрованного запроса часть данных справочника вообще не используется. И в итоге вы нагибаете базу заставляя её уходить в чтение с дисков на больших справочниках, нагибаете сеть — заставляя гонять кучу данных, нагибаете клиента — отъедая ОЗУ и проц на ручной JOIN.
А можно было сделать JOIN в БД и сразу отфильтровать только нужные данные.
В общем, складывается впечатление, что автор не смог разобраться с БД и почему там хреновый план выполнения запроса, и решил в лоб на клиенте сделать JOIN, потому что лень переписывать неэффективный SQL.coh
26.05.2017 13:14-1Про справочники — это ваши фантазии, как и про полный объем данных по связям без фильтрации.
На эту и смежные темы написаны сотни статей, подготовлены презентации для десятков конференций Highload и прочих
Если лень гуглить:
http://www.myshared.ru/slide/9793/ (слайд 38)
http://highload.guide/blog/sharding-patterns-and-antipatterns.html (к тезису про справочники, и вашему предположению, что все нужные данные на одном шарде)
CWN
26.05.2017 16:38Ох, мы опять про ежей и ужей. Вот эти вот «фантазии» почему то очень часто приходится разгребать, когда система «внезапно» перестает отвечать за вменяемое время.
http://www.myshared.ru/slide/9793/ (слайд 38)
Поглядел. И не понял почему они вообще решили при этом использовать реляционную БД. Выключить все что дает движок, и использовать СУБД как Key-Value хранилище к которому можно писать запросы на SQL, что выглядит мягко говоря странным, так как SQL это еще один дополнительный слой, который можно в такой системе выкинуть.
Давайте сразу определимся, есть хайлод в котором данные не важны, ну в некоторой степени не важны — потеряем мы комментарий пользователя, или данные сессии похерим, ничего страшного — пользователь перенаберет/перезайдет.
А есть хайлод в котором транзакции, ACID, нормализация и вот это вот все называемое реляционной моделью данных. А данные там критически важные — как самый яркий пример — финансовые транзакции. А теперь попробуйте объяснить заказчику системы, почему у вас данные не консистентны из-за того, что Вы не используете механизм транзакций. Или данные пропали, потому что не успели зафиксироваться на дисках. Или топовое серверное железо загибается, из-за того, что программер решил всю базу к клиенту гонять и обратно, вместо работы с данными в самой базе. И таких примеров много.coh
26.05.2017 16:50Видимо мы разговариваем на разных языках…
Статья «Чек-лист по выживанию сайта».
Я про join и шардинг (не всегда данные влазят в одну базу и обилие join серьезно усложняет шардирование), а вы мне про справочники и транзакции.
Почему вы решили что я не использую транзакции, опять фантазия?
Не вижу смысла продолжать обсуждение.CWN
26.05.2017 17:31+1Видимо да. Вы почему то уперлись в утверждение, что join на шардинге это плохо. И приводите в качестве аргумента вырванные из контекста слайды (отсюда и предположение что не используете транзакции, все таки презентация про конктретный случай, а не про общее состояние дел).
Просто Вы не хотите посмотреть шире, и рассматриваете шардинг как размазывание одного объекта по кучи хостов из которого «магическим» образом вытаскиваются данные, и накладывание не который JOIN чревато проблемами.
Но если посмотреть на шардинг как на комплекс независмых хостов, в каждом из которых есть все необходимые данные для работы хоста — то проблема джойнов исчезает. Вы просто заранее решаете какой хост предпочтителен в данном конкретном случае, для доступа к конкретным данным.
coh
26.05.2017 17:42Ну наконец-то появился конструктив.
JOIN на шарде — вполне годная тема, особенно если архитектура изначально предрасположена к шардированию. Это не отменяет того, что возможно придется сделать довыборку данных из другого источника и в этом нет ничего страшного. Транзакции нужно использовать для финансовых операций с этим никто не будет спорить.
Есть другая крайность с которой мне приходится часто сталкиваться — 1 сервер БД который не в состоянии переварить все данные и запросы, блокировки и прочее. Когда приложение написано с огромным кол-вом объединений. Чтобы растащить такую базу нужно очень сильно поднапрячься. Именно поэтому в вебе join больше зло. Потому как даже просто вынос конкретной таблицы на отдельный сервер представляет сложную задачу.
OlehR
26.05.2017 11:43Ну да 0.5M строк кода на PL/SQL — не показатель :)
наибольшая табличка > 550 000 000 строк ежедевно увеличиваєтся 300 000 строк и ето не логи а таблица влияющая на остатки.
AslanKurbanov
26.05.2017 12:09При работе с MySQL примитивно помогает увеличить скорость простановка LIMIT к запросам и fetch_assoc вместо более медленного fetch_array, создающего доп.элементы. По-моему, тюнинг баз — это отдельная тема, стоит ли веб-программистов за это сильно ругать?
vyrkmod
31.05.2017 08:38+2Стоит, иначе ваяют чушь, которая запросами в таблицу на 150к строк умудряется ронять движок бд
phgrey
31.05.2017 08:40-2я бы сказал, что стоит их за это пинать ногами. ибо оптимизация базы удешевляет хостинг в разы
saipr
26.05.2017 16:57-2
С бизнесом можно разговаривать только на языке бабла. Он не восприимчив к красоте решений, нормализации базы, CAP-теоремам и прочим IT-ценностям. Он понимает деньги и сроки.
Попытка спросить какую нормальную форму использкует разработчик или ваша БД приведена к третьей нормальной форме — как правило ставит в тупик. Люди не знают кто такой Эдгар Кодд!!! Поэтому есть СУБД, но баз данных нет. Отсюда все проблемы и так называемым электронныи правительством, госуслугами и т.д.
Movimento5Litri
30.05.2017 21:20-1Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн.
Святые, слова.
Расскажите это разработчикам Angular
Kasheftin
31.05.2017 13:30+1Отличный материал, спасибо. Особенно согласен в плане взаимодействия с базой.
Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.
В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.
5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.
Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.
s_e_t
31.05.2017 13:56Пять копеек к проблеме большого количества select-update и локов.
Такая нагрузка на таблицу предполагает, что это явно не последняя таблица в проекте. И для оптимизации этих запросов вы готовы потратить времени чуть больше, чем просто создать пару индексов.
Тогда возможно стоит добавить микросервис (простой рест сервис) над этой таблицей, через который пойдут наиболее тяжёлые и частые запросы (select), пусть даже не все, и пусть там данные кэшируются хотя бы секунд 5-10 (20), и пусть он выполняет какие-нибудь несложные фильтрации с этими данными — разве это не стандартное решение для микросервисной архитектуры?
От мастер-слейв это решение отличается объёмом используемых ресурсов (микросервис будет сильно скромнее и более интегрированным в ваш проект и бизнес логику) и тем что вы получаете механизм регулирования нагрузки через изменения времени кеша.
phgrey
31.05.2017 14:00поставить микросервис — одно из любимых решений сегодня. модно, красиво. но есть одно слово — дорого))))
terrier
Непонятно, что вы имеете в виду. Что такое «пересчет» индекса? UPDATE, конечно же апдейтит индекс, но это вполне уживается с SELECT'ом.
https://www.postgresql.org/docs/9.6/static/index-locking.html
Если под «пересчетом» вы понимаете REINDEX, то нет, конечно же при UPDATE никакой REINDEX не делается.
phgrey
Под пересчетом индекса я подразумеваю ситуацию, в которой большое количество SELECT запросов при встрече с большим количеством UPDATE-запросов создают затык. Если вы расскажете как этого затыка избежать — вы мне окупите все усилия на написание этой статьи.
TSR2013
Насколько я понимаю обычно путь джедая к светлой стороне такой
1) Замена update -> insert & delete
2) Если первый пункт не помог, аккумулирование изменений в очереди/кэше и отложенный multi insert/ multi update
3) Если же объем модифицирующих запросов на столько велик, что ничего не помогло, надо уходить с MySQL. Здесь сложно что то посоветовать куда уходить. Для примера можно посмотреть Cassandra, Click House итд
phgrey
INSERT не приводит к пересчету индексов? То есть поток INSERT на таблицу не замедлит поток SELECT?
И перед сменой основной СУБД я бы все-таки попытался выжать поболе из используемой. А то все технологии со своими минусами, а с минусами этой мы вроде хоть знакомы.
phgrey
У INSERT… DELETE vs UPDATE откуда преимущества вообще? Кроме меньшего количества самих запросов. Uber по-моему свалила с PostgreSQL из-за иммутабельности tuples и вытекающих из этого проблем с оверпересчетом индексов при апдейтах даже непроиндексированных полей. И зашкаливания объемов бинарного лога, что увеличивает стоимость синхронизации серверов в кластере.
TSR2013
Сейчас погуглил, не нашел подтверждению пункту 1, так что можно его считать не актуальным. Если не хочется возиться с новой технологией можно рассмотреть вариант репликации master/slave. Пишем в master читаем со slave. Правда при большом объеме модификаций возможно отставание реплик. В 5.7 появился cluster https://dev.mysql.com/doc/refman/5.7/en/faqs-mysql-cluster.html
phgrey
да-да-да. именно о таком подходе я писал
terrier
Это не так. По неизвестной причине уберовцы написали просто вызывающе неверную информацию в своей статье и она, к сожалению, пошла в народ. При апдейте непроиндексированных полей срабатывает HOT-оптимизация и индекс не трогает ( с 2007 года так). Вообще в той статье убера, наряду с несколькими действительно разумными аргументами, есть несколько просто WTF-points.
phgrey
any proof? я читал об этом не у них.
terrier
sure.
https://wiki.postgresql.org/wiki/Index-only_scans#Interaction_with_HOT
Ну и собственно, все что угодно по запросу «hot-optimisation postgres», это же не какой-то секрет
phgrey
Спасибо! делаю UPDATE.
А по умолчанию опция выключена? Или они там в Uber совсем тормозят?
terrier
По умолчанию включено, но оптимизация срабатывает тогда, когда новая строка находится на той же странице, что и старая ( помним, что при апдейте создается новая строка, так как они иммутабельны ) и возможно для повышения вероятности срабатывания нужно пошевелить параметр fillfactor ( подробнее здесь)
В случае убера мы можем попытаться предположить, что у них там большое количество индексов на таблице и большинство апдейтов все-таки затрагивают проиндексированные колонки, но это догадки.
phgrey
помогает?
я правильно понял что Uber уехали с PostgreSQL из-за проблем с пересчетом индексов? не разобрались как настроить? Такая очевидная справка?
или системные проблемы с пониманием СУБД?
terrier
Безусловно.
В убере, по-моему, отдел БД просто любит движуху, вот и мигрируют туда-сюда. Не удивлюсь, если завтра они начнут переезжать куда-нибудь на VoltDB.
phgrey
Resume-Driven-Development?
Lailore
преимущество в том, что ненадо делать поиск по всей таблице. Это огромное преимущество
AlexTest
Скорее всего ситуация, когда большое количество SELECT запросов встречается с большим количеством UPDATE-запросов в одной и той же таблице — архитектурный просчет на этапе проектирования конкретной БД.
Нужен практический пример, когда вы столкнулись с такой ситуацией в реальной жизни.
Скорее всего можно предложить другую архитектуру хранения и использования данных для такого случая.
phgrey
Вы уверены что это именно ошибка? Есть конкретные примеры решения такой архитектурной ошибки? Ну кроме уже предложенного выше способа «пишем в мастер, читаем со слейва».
AlexTest
Я ни в чем не уверен, до тех пор пока не понимаю сути конкретной, а не абстрактной проблемы — и я об этом написал. Сначала дайте конкретный практический случай этой проблемы (именно это я предложил выше), а уже потом спрашивайте какие есть варианты ее решения!
phgrey
Площадка-интернет-магазин с редактированием товаров продавцами онлайн. Как архитектурно верно избежать встречного потока SELECT — UPDATE и связанного с встречей замедления обоих потоков?
Lailore
Вделать журнал обновлений, а не модифицировать саму строчку
rPman
Какие фреймворки поддерживают прозрачную работу с данными в базе и еще находящимися в журнале? Потому что если такой поддержки нет, все бонусы от использования этого фреймворка нивелируются и начинается тотальный изврат.
Lailore
Незнаю, работу с журналом я делал руками
phgrey
INSERT в журнал обновлений встречается с SELECT по тому же журналу.
Стоимость развязки SELECT — INSERT чуть выше, чем SELECT — UPDATE, не согласны?
Lailore
Insert происходит в другую таблицу, и в результате у нас селект не страдает
phgrey
Кому нужен журнал, по которому не делается селект?
Ваше предложение пока что конкуриет по своей непродуманности с развязкой через кластер: UPDATE на мастере, SELECT со слейва. Надеюсь, не надо рассказывать почему такая развязка не развязка?
Lailore
Всем кто может позволить себе задержку актуальности списка. Интернет магазин отличный пример
mayorovp
Как в такой схеме реализовать, к примеру, поиск товара по описанию, если описание — в журнале?
Lailore
у меня поиск был отдельным сервисом, со своей базой, которая обновлялась асинхронно. Тоесть поиск отставал от актуальной информации, но апдейт элементов в нем происходил сразу пачками, тоесть вместо 10 апдейтов был всего один.
AlexTest
Так вроде же все очевидно — надо разделить потоки на две таблицы.
Выборка товаров для покупателей должна происходить из одной таблицы (user_table), а изменение-добавление продавцами в другой (main_table).
Периодически, по мере накопления изменений в main_table данные программно компилируются в один большой запрос типа:
для синхронизации таблиц main_table и user_table.
AlexTest
На всякий случай добавлю — подразумевается конечно, что в запрос синхронизации попадут только данные последних изменений в товарах требующих синхронизации, а не вся таблица полностью. И как уже писали выше, небольшой лаг между внесением изменений и их появлением на фронте — для интернет магазина совершенно не критичен.
phgrey
просто bunch?
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
AlexTest
Да, но я не стал бы ее называть журнальной, скорее это основная таблица, а user_table — просто ее копия и желательно, чтобы она была вообще на другом сервере для изоляции буферов БД.
Да. Особенно если запустить его в отдельной транзакции. Такой подход даст существенную экономию на операциях слива буферов изменений в сравнении с кучей отдельных запросов «однострочных» изменений.
phgrey
Куча однострочных UPDATE в отдельной транзакции при отключенной переиндексации сработает не так же?
phgrey
Я правильно понимаю суть идеи — мы создаем вторую точку встречи на промежуточной таблице main_table и размазываем «нагрузку встречи» между двумя точками?
Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.
Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
Lailore
Кхм. Это практически стандартное решение, когда у нас множество апдейтов и селектов. Вы наверное не понимаете насколько insert дешевле update. insert просто вставляет запись, update же сначала ищет запись и т.п.
phgrey
да-да-да, я вааще не понимаю чем INSERT… ON DUPLICATE KEY UPDATE… дешевле UPDATE. И в этой ветке обсуждается не журнальная таблица, а промежуточная.
А насчет дешевизны INSERT в контексте пересчета индексов уже отписывался
Cubus
Почему? Вполне обычное OLTP. Тут главное, чтобы SELECT и UPDATE были короткими.