Comments 13
Иногда стоимость оптимизации кода выше, чем просто докупить ещё ресурсов
Иногда и наоборот, когда ракеты падают.
Чтобы стать успешным программистом, программирование нужно именно любить.
...первые пару лет. Потом вообще пофигу, любишь ты или нет, основной навык уже усвоен, а развиваться дальше можно испытывая абсолютный пофигизм к программированию или даже слегка его ненавидя. Личный опыт)
В компании действовала система отслеживания неоптимальных запросов, которые исправлялись, как ошибка реализации
Немного наивный вопрос - если существует автоматизированная система по отслеживанию неоптимальных запросов, быть может стоило сделать сдедующий шаг и сделать из неё оптимизатор, а не заставлять тысячи программистов переписывать с понятного на оптимальный?)
Тут все не так просто. Кроме времени выполнения запроса там логировался даже план выполнения запроса. В зависимости от плана выполнения запроса очень сильно меняется время его выполнения. Обычно есть несколько разных способов записать в целом один и тот же запрос, на больших и сложных данных время выполнения разных форм одного и того же запроса могут отличаться в сотни раз. Потому, что планировщик и оптимизатор PostgreSQL штука умная, сложная, учитывающая статистические данные, но не всесильная. Иногда план запроса не попадает в нужные индексы, иногда нужного индекса просто нет. Иногда все ломается (оптимальный план запроса) от простого джойна.
То есть здесь именно тот случай, когда машинная оптимизация не справилась и нужно человеческое участие. На самом деле, PostgreSQL здесь не уникален. Похожим образом может происходить оптимизация запросов для MS SQL, Oracle и других реляционных баз данных.
Я скорее имел ввиду, что если у вас была автоматизированная система по обнаружению того, что разработчик написал неоптимальный запрос, а также разметка этого запроса как "ошибка реализации", то очевидно система знала, что именно в этом запросе не так? Или я неправильно понимаю логику работы таких анализаторов?
Понять, что с запросом происходит что-то не то на продуктивных данных, можно только в момент его выполнения. Поэтому мы сейчас говорим о системе логирования времени выполнения запросов и планов их выполнения. И системе мониторинга самых долгих и тяжёлых запросов. Планы же запросов нужны, чтобы понимать, что пошло не так. Не попали в индекс, спровоцировали sec scan либо ещё что-то подобное.
Часто надо рассматривать все SQL-запросы от одной операции как целое, например, классическая N+1 проблема не лечится оптимизацией какого-то одного запроса, а требует переписывания модуля (со стороны SQL-сервера мы даже не знаем, на чём написан клиент — java? python? и поэтому не знаем, как автоматически переписать).
Это действительно так, но реализовать это придётся уже не на уровне PostgreSQL. Хотя есть такая вещь, как транзакция, и можно смотреть общее время её выполнения. Долгими они тоже не должны быть, чтобы не начать ловить дедлоки из-за блокировок на чтение и запись.
Кроме того, информацией о транзакцией обладает сервер с бизнес-логикой (написан на Python и C++). Этот сервер предоставляет API, время которого тоже можно отслеживать. Такие рейтинги тоже были, но контролировались не так плотно.
Ну и частота вызова метода API и SQL-запроса тоже имеет значение. Чем чаще вызывается, тем больше может быть потребность в оптимизации. Суммарное время и потребление памяти тоже отслеживалось.
Немного наивный вопрос - если существует автоматизированная система по отслеживанию неоптимальных запросов, быть может стоило сделать сдедующий шаг и сделать из неё оптимизатор, а не заставлять тысячи программистов переписывать с понятного на оптимальный?)
Выглядит как маленький управленческий шаг для руководителя, и огромный для всего человечества). Когда-нибудь именно так и будет, и автоматические оптимизаторы будут разгребать горы легаси, превращая код в оптимальный. И тысячи программистов останутся без работы. Но пока задачка из области фантастики, и ни в какой бюджет - даже самый фантастический.
Приложение может корректно отрабатывать все необходимые позитивные и негативные сценарии, но из-за ограничений своего быстродействия и потребления ресурсов быть совершенно немасштабируемым либо непригодным к эксплуатации.
Когда вам нужно построить дом, вы кого будете искать? Ежу понятно - строителей (ну не экономистов же, юристов, или там архитекторов). А если софт? Разумеется - тыжпрограммистов. ;)
Функциональные требования определяют "что" приложение должно делать. Но ведь одну и ту же функцию можно написать десятками разных способов?
"Как" приложение должно работать, в большей степени зависит от нефункциональных требований (performance, usability, reliability, maintainability, testability, regulatory и прочие *ty). Они же в основном и _определяют архитектуру_.
Дизайн архитектуры и программирование это два довольно разных аспекта. Много ошибок возникает на стыке этих двух областей, в том числе и чисто управленческих.
Состав и уровень команды определяет уровень сложности проекта, который они смогут вывезти в отведенное время. Функциональный прототип PoC зачастую могут собрать и программисты, MVP уже стоит проектировать, привлекая специалистов из разных областей.
Ещё один важный момент, который нельзя обойти стороной, — быстродействие и ресурсоёмкость выполнения разработанного кода.
О, как владели приёмами оптимизации патриархи отечественного программирования. Как мы, курсанты первого набора программистов в военной академии им. Ф.Э. Дзержинского, восхищались детищем дважды Лауреата Государственной премии СССР М.Р. Шуры-Буры системой обслуживания библиотек стандартных подпрограмм ИС-2 (Интерпретирующая Система). В ИС-2 было всё — и наука, и искусство:
Интерпретирующая система ИС-2 (позднее ИС-22) представляла собой маленький шедевр как по технологии наполнения библиотеки СП, так и по простоте ее использования, по минимуму накладных расходов.
Я сам писал транслятор РПГ-М-220, имея в своем распоряжении 4K оперативной памяти, иагнитный барабан на 28K и восемь лентопротяжек:
Почему ошибаются программисты? Часть 2/2