за что точно надо отрывать руки - это когда противники хранимок гоняют гигабайты данных туда-сюда, пропуская их через лес уродливого кода, для работы в таком ключе вообще не приспособленного
Ценность/не ценность ни при чем . Скажу только про себя - на инженерной должности я работаю и создаю реальный ощутимый результат. На руководящей должности основное время был занят объяснением что белое это белое а из навоза и палочек дом не построить. Я продержался 3 года . Но повторюсь , все симптомы выгорания у меня были . Я изменил образ жизни , я повторюсь, сто тысяч раз себе молодец.
А значимость это вообще неважно. Например, то , чем я занимаюсь коллегам не особо то интересно и пока результат не сильно значимый .
Но главное - мне интересно заниматься на работе тем, чем я занимаюсь. Придет время , придет и оценка и значимость.
А пока , как в старые добрые времена - иногда после работы задержаться для свободного творчества или даже выходной можно, это же классно. Imho
P.S.И еще важный момент - я не люблю/не умею играть в манагерские игры и подставы .
У меня в прошлом году было настоящее реальное классическое выгорание по всем симптомам.
Вылечилось изменением должности - ушел с руководящей должности обратно в инженерную. Сто тысяч раз сказал себе - молодец , что решился все таки изменить ситуацию.
Про микросервисы был забавный случай - руководитель разработки гордо рапортует -"мы перевели архитектуру с монолита на микросервисы". Странно , но почему то со стороны СУБД никаких изменений не выполнялось.
Выяснилось они считают отдельным микросервисом - отдельную БД в кластере PostgreSQL.
Какой смысл и выгода от использования отдельной БД в кластере взамен отдельной схемы в одной БД - я пока не понял, хотя особенно данную тему и не копал. Возможно , выгода есть.
К сожалению , современное поколение разработчиков воспринимает СУБД как хранилище данных. Как работает СУБД они не знают и знать не хотят - "зачем вы используете pg_adviser_lock? У нас Фреймворк такой."
Это не исключение это правило. В ходе решения поставленной задачи по импортозамещению и миграции решений с Oracle на PostgreSQL над особенностями и отличием СУБД они не задумываются , берут Фреймворк и ORM и потом классическое "мы уперлись в СУБД".
Они все такие, решение предоставляются разными подрядчиками , и разными командами разработки . Пока , я не встретил ни одного разработчика прошедшего хотя бы DBA-1. Может, это мне не везет, а может это современный тренд такой .
Итог всегда один - перевод в промышленную эксплуатацию , аварийная ситуация , ответ разработчиков "мы не понимаем, что происходит". Это не гипербола , это прямая цитата с конфколла по ходу решения аварийной ситуации.
Иногда доходит до смешного - подрядчик-поставшик решения объясняет вендору СУБД , что СУБД работает неправильно - "а вот в Oracle блокировки обрабатываются по другому и на старой системе все работало". Это было на самом деле, я лично это слышал.
"У нас проблема с СУБД , очень много ожиданий Client read." - это не шутка это мнение руководителя группы разработки. Пришлось собрать нервы в кулак и очень аккуратно , максимально толерантно объяснять и открывать глаза на картину мира и цитировать RTFM. В свое рабочее время и совершенно бесплатно .
Самая главная книга для начинающего архитектора и вообще IT-специалиста - "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте" Эдвард Йордан.
Самое удивительное то, что выросло поколение которое повторяет все ошибки описанные и разобранные лет 30 назад. История сделала поворот по спирали.
Всё повторяется - вплоть до прямых цитат : "а на тестовом стенде у нас все работало быстро ".
Все именно так , согласен по каждому пункту. Тема не для данного топика.
К тому, же - изменить установленные даже не процессы а практики силами DBA -не реально. По крайней мере , я давно бросил попытки спасти этот мир и открыть глаза . Приходится приспосабливаться . Если судьба дала лимон - сделай лимонад. В результате скилы по performance engineering сильно растут . И это хорошо .
Для его повышения я и пишу-пишу статьи - присоединяйтесь!
По мере скромных сил стараюсь добавлять свои пять копеек по темам.
Но , к сожалению это практически не оказывает влияния на процесс разработки ИС. Современное поколение разработчиков воспринимает СУБД как ящик для хранения данных , не зная и не понимая как всё работает(они сами открытым текстом это говорят).
Классическая ситуация - в ходе НТ выясняется - система тормозит и не выдаёт заявленных в ТР показателей . Выяснилось - разрабы используют pg_adviser_lock. На вопрос - а какого болта ? Получен ответ - а у нас Фреймворк такой.
И все, ничего не сделать . Систему сдали в промышленную эксплуатацию, каждую неделю разбор инцидентов с одним и тем же результатом - проблемы приложения . После проведения рефакторинга - проблема прошла.
Или другой случай - огромное количество сессий в состоянии "idle in transaction". На вопрос - зачем вы так делаете ? Получен ответ - приложение открывает транзакцию , проводит изменения , ждет ответа от внешней системы и закрывает транзакцию. Случай "как сделать Highload на ровном месте". Описано в статьях, докладах и конференциях. Но разрабы этих статей не читают, доклады не слушают, конференции не посещают.Это не проблема это особенность логики приложения (с).
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме.
Очень дискуссионная и очень долгая тема . Вопросы возникают к каждому слову данного предложения.
Стандартная ситуация - запрос в psql выполняется за ms , но экранная форма приложения открывается минуты . Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". Стоит больших трудов и нервов объяснить ламерам, что СУБД в данном случае ни при чем. Если вы, чайники гоните на клиента сотни тысяч строк, то это ваши личные проблемы и ваше личное решение , не отдела администрирования баз данных. Мы, DBA, вам в данной ситуации ничем не поможем.
И таких ситуаций практически каждый день . Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA , отвлекая и не давая заниматься темами имеющими непосредственное влияние на СУБД.
Именно по этому , в свое время и начались работы по теме "Производительность СУБД". Сейчас я могу аргументированно , используя цифры , а не ощущения , доказать - "с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры". Это экономит кучу времени и нервов .
В результате - анализ и разбор инцидентов и кризисов в ходе промышленной эксплуатации ИС, проходит сильно по другому , чем буквально пару месяцев назад. Потому, что 99.999% аварий не вызваны причинами в СУБД и не требуют каких либо действий со стороны DBA.
это определяется разделением обязанностей в организации.
Именно. И поэтому данная тема в данном топике - явный оффтопик .
Ответ будет сильно оффтопик и содержать сильно личное предвзятое мнение .
Проблема в следующем:
Можно вложить 100 рублей в выделение больших аппаратных ресурсов, а можно за 1 рубль заставить разработчика добавить индекс, после чего оценить изменение описанных выше метрик
Аппаратные ресурсы сейчас стоят сильно дешевле , особенно одноразовые, особенно совершенно ясно как провести расходы .
Как провести расходы по разработке - сильно другая тема . К тому же , очень острая проблема - удручающе низкий уровень разработки.
Что они творят, это тема отдельного набора статей.
оно может быть полезно, если "везде все хорошо и вдруг где-то становится плохо".
Именно эта ситуация.
можно взять любой хост и какую-нибудь неоптимальность да найти, а раз нашел - стоит устранить.
Вопросы не относящийся к теме данного поста - зачем ? Или другими словами - за счет какого бюджета работы ? И самое главное - какие цифры являются показателем качества выполненных работ ?
Корреляционный анализ для решения инцидентов производительности СУБД
https://habr.com/p/827504/
Подход в принципе другой - не эмпирический , в основе мат. статистика , и весь накопленный опыт статистического анализа. Т.е. по классике - гипотеза , эксперимент , анализ , гипотеза ...
Работы по теме только начались, но первые результаты уже есть.
Например - для анализа причин аварийной ситуации деградации производительности отчеты pgpro_pwr бесполезны .
"В детстве , я таких убивал. Из рогатки".(с)
Я видеть такой кейс(регулярно повторяемый)- backend выгружает весь набор строк и фильтрует на стороне приложения.
Закономерный итог -"а почему в psql запрос отработал миллисекунды а форма открывается минуту ?"
Это ирония и сарказм или юношеская наивность ?
Дальше читать не имеет смысла
Обсуждалось 4 года назад
«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров https://habr.com/p/515530/
Ценность/не ценность ни при чем . Скажу только про себя - на инженерной должности я работаю и создаю реальный ощутимый результат. На руководящей должности основное время был занят объяснением что белое это белое а из навоза и палочек дом не построить. Я продержался 3 года . Но повторюсь , все симптомы выгорания у меня были . Я изменил образ жизни , я повторюсь, сто тысяч раз себе молодец.
А значимость это вообще неважно. Например, то , чем я занимаюсь коллегам не особо то интересно и пока результат не сильно значимый .
Но главное - мне интересно заниматься на работе тем, чем я занимаюсь. Придет время , придет и оценка и значимость.
А пока , как в старые добрые времена - иногда после работы задержаться для свободного творчества или даже выходной можно, это же классно. Imho
P.S.И еще важный момент - я не люблю/не умею играть в манагерские игры и подставы .
Пока со мной лично не произошло, я смеялся и улыбался когда встречался термин "выгорание".
У меня в прошлом году было настоящее реальное классическое выгорание по всем симптомам.
Вылечилось изменением должности - ушел с руководящей должности обратно в инженерную. Сто тысяч раз сказал себе - молодец , что решился все таки изменить ситуацию.
Про микросервисы был забавный случай - руководитель разработки гордо рапортует -"мы перевели архитектуру с монолита на микросервисы". Странно , но почему то со стороны СУБД никаких изменений не выполнялось.
Выяснилось они считают отдельным микросервисом - отдельную БД в кластере PostgreSQL.
Какой смысл и выгода от использования отдельной БД в кластере взамен отдельной схемы в одной БД - я пока не понял, хотя особенно данную тему и не копал. Возможно , выгода есть.
К сожалению , современное поколение разработчиков воспринимает СУБД как хранилище данных. Как работает СУБД они не знают и знать не хотят - "зачем вы используете pg_adviser_lock? У нас Фреймворк такой."
Это не исключение это правило. В ходе решения поставленной задачи по импортозамещению и миграции решений с Oracle на PostgreSQL над особенностями и отличием СУБД они не задумываются , берут Фреймворк и ORM и потом классическое "мы уперлись в СУБД".
Они все такие, решение предоставляются разными подрядчиками , и разными командами разработки . Пока , я не встретил ни одного разработчика прошедшего хотя бы DBA-1. Может, это мне не везет, а может это современный тренд такой .
Итог всегда один - перевод в промышленную эксплуатацию , аварийная ситуация , ответ разработчиков "мы не понимаем, что происходит". Это не гипербола , это прямая цитата с конфколла по ходу решения аварийной ситуации.
Иногда доходит до смешного - подрядчик-поставшик решения объясняет вендору СУБД , что СУБД работает неправильно - "а вот в Oracle блокировки обрабатываются по другому и на старой системе все работало". Это было на самом деле, я лично это слышал.
"У нас проблема с СУБД , очень много ожиданий Client read." - это не шутка это мнение руководителя группы разработки. Пришлось собрать нервы в кулак и очень аккуратно , максимально толерантно объяснять и открывать глаза на картину мира и цитировать RTFM. В свое рабочее время и совершенно бесплатно .
Самая главная книга для начинающего архитектора и вообще IT-специалиста - "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте" Эдвард Йордан.
Самое удивительное то, что выросло поколение которое повторяет все ошибки описанные и разобранные лет 30 назад. История сделала поворот по спирали.
Всё повторяется - вплоть до прямых цитат : "а на тестовом стенде у нас все работало быстро ".
Все именно так , согласен по каждому пункту. Тема не для данного топика.
К тому, же - изменить установленные даже не процессы а практики силами DBA -не реально. По крайней мере , я давно бросил попытки спасти этот мир и открыть глаза . Приходится приспосабливаться . Если судьба дала лимон - сделай лимонад. В результате скилы по performance engineering сильно растут . И это хорошо .
В самую точку !
Tantor и Postgres Pro - прямые конкуренты .
Я например сейчас вживую наблюдаю эксперименты - "а вот на Tantor, 1C будет быстрее работать ".
По мере скромных сил стараюсь добавлять свои пять копеек по темам.
Но , к сожалению это практически не оказывает влияния на процесс разработки ИС. Современное поколение разработчиков воспринимает СУБД как ящик для хранения данных , не зная и не понимая как всё работает(они сами открытым текстом это говорят).
Классическая ситуация - в ходе НТ выясняется - система тормозит и не выдаёт заявленных в ТР показателей . Выяснилось - разрабы используют pg_adviser_lock. На вопрос - а какого болта ? Получен ответ - а у нас Фреймворк такой.
И все, ничего не сделать . Систему сдали в промышленную эксплуатацию, каждую неделю разбор инцидентов с одним и тем же результатом - проблемы приложения . После проведения рефакторинга - проблема прошла.
Или другой случай - огромное количество сессий в состоянии "idle in transaction". На вопрос - зачем вы так делаете ? Получен ответ - приложение открывает транзакцию , проводит изменения , ждет ответа от внешней системы и закрывает транзакцию. Случай "как сделать Highload на ровном месте". Описано в статьях, докладах и конференциях. Но разрабы этих статей не читают, доклады не слушают, конференции не посещают.Это не проблема это особенность логики приложения (с).
Вот такие пирожки с котятами.
К тому, же написание статью это много времени.
Спасибо, что у кого то есть время и возможность .
Очень дискуссионная и очень долгая тема . Вопросы возникают к каждому слову данного предложения.
Стандартная ситуация - запрос в psql выполняется за ms , но экранная форма приложения открывается минуты . Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". Стоит больших трудов и нервов объяснить ламерам, что СУБД в данном случае ни при чем. Если вы, чайники гоните на клиента сотни тысяч строк, то это ваши личные проблемы и ваше личное решение , не отдела администрирования баз данных. Мы, DBA, вам в данной ситуации ничем не поможем.
И таких ситуаций практически каждый день . Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA , отвлекая и не давая заниматься темами имеющими непосредственное влияние на СУБД.
Именно по этому , в свое время и начались работы по теме "Производительность СУБД". Сейчас я могу аргументированно , используя цифры , а не ощущения , доказать - "с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры". Это экономит кучу времени и нервов .
В результате - анализ и разбор инцидентов и кризисов в ходе промышленной эксплуатации ИС, проходит сильно по другому , чем буквально пару месяцев назад. Потому, что 99.999% аварий не вызваны причинами в СУБД и не требуют каких либо действий со стороны DBA.
Именно. И поэтому данная тема в данном топике - явный оффтопик .
Ответ будет сильно оффтопик и содержать сильно личное предвзятое мнение .
Проблема в следующем:
Аппаратные ресурсы сейчас стоят сильно дешевле , особенно одноразовые, особенно совершенно ясно как провести расходы .
Как провести расходы по разработке - сильно другая тема . К тому же , очень острая проблема - удручающе низкий уровень разработки.
Что они творят, это тема отдельного набора статей.
Именно эта ситуация.
Вопросы не относящийся к теме данного поста - зачем ? Или другими словами - за счет какого бюджета работы ? И самое главное - какие цифры являются показателем качества выполненных работ ?
Я извиняюсь , но если на DBA вешать еще и анализ и мониторинг ОС - когда заниматься непосредственно вопросами СУБД ?
Принципиально другая методика
Корреляционный анализ для решения инцидентов производительности СУБД
https://habr.com/p/827504/
Подход в принципе другой - не эмпирический , в основе мат. статистика , и весь накопленный опыт статистического анализа. Т.е. по классике - гипотеза , эксперимент , анализ , гипотеза ...
Работы по теме только начались, но первые результаты уже есть.
Например - для анализа причин аварийной ситуации деградации производительности отчеты pgpro_pwr бесполезны .