Немного оффтоп, но интересно, почему в штат не хотят брать

DBA? Это много где и упорно декларируется. Базы повсюду, ценность данных растёт, но администраторов баз данных нет даже в компаниях с огромными оборотами, где БД, как говорят, mission critical. При этом на любой чих берут отдельного человека (видно по вакансиям). В мире ситуация обратная, а России складывается именно так, хорошо ещё что не везде. Лет 10 назад DBA были востребованы, сейчас в районе статистической погрешности. Почему это происходит, как думаете?

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

надо брать воинственного, чтобы ходил с палокой и бил разрабов за хреновые планы запросов!

Хорошо, но DBA он относится к администраторам, как тот же сисадмин. Его дело обеспечивать стабильность работы и сохранность данных. Сисадмин тоже не мечется, если у него всё работает, и выходит что не догружен работой, хотя должностные обязанности выполняет

А это точно массово происходит (может, Вам так "повезло" наткнуться несколько раз)? А то так долго можно объяснения придумывать. ;)

Я, честно говоря, сисадминов в привычном понимании давно уже не встречал. Это ж те, кто Винду ставит и интернет прокладывает? А тем, что вы описали, часто занимаются девопсы. То есть они отвечают за деплой и т.п., а также умеют шаманить БД на каком-то уровне. Если не справляются - обращаются уже к DBA.

У меня из знакомых dba все ушли из профессии, мне еще 5 лет назад писали, что профессия умерла. Я сужу по вакансиям dba - около 30 на PostgreSQL и столько же на Oracle, в Москве причём

Слышал оракл вообще какую-то технологию самообслуживания для бд внедряют

Oracle ещё с 11 версии говорил, что админы их БД не нужны, с 12 - что просто вредны. До бизнеса эта идея наконец-то дошла

да-да, мои знакомые Oracle DBA тоже самое говорят, мол DBA не нужны с облаками. Осталось только Exadata купить…

Про облака да, на западе это весомый довод, админы стоят дорого. Но у нас то все облака свои, и не все им доверяют

что касается Oracle, там да - всегда есть DBA. а postgres DBA, если честно, ни разу не видел

Ну это я, как мне кажется, вижу, да. А у нас-то почему? devops?

Ну так в этом чате "посмотрите". ;)

С Oracle почти всё кончено, у нас на родине, на западе Oracle DBA востребованы и хорошо оплачиваемы. А Postgres у нас растёт как нигде в мире

да, в этом чате точно есть DBA. достаточно крутые. но я имел в виду в реальной жизни не встречал DBA по Postgres. где их искать...)

их растить надо, как и любых других специалистов…

а зачем их растить, если dba, получается, не нужны?

я не согласен с этим утверждением, прям совсем. даже для Oracle.

мне оно тоже сильно не нравится, но показатель востребованности это вакансии, а их очень мало.

+ все зависит от проекта и нагрузки. кол-во пользователей. IOPS. и собсно сам бизнес и требования. для Oracle можно найти сертифицированных и даже не сертифицированных специалистов, которые смогут чтото на 10-20К пользователей поднять. а вот Postgres чтото страдает. в этом и трабла...

мне кажется, что это не так: (1) они закрываются через поиск кандидатов внутренними способами, не выходя на площадки и (2) они закрываются очень быстро

по п.1 вполне возможно, а вот что закрываются очень быстро - это не совсем так. Я на hh.ru ставлю звёздочки на вакансии для отслеживания, и закрываются они в среднем за пару месяцев, некоторые висят гораздо дольше

> а вот Postgres чтото страдает. Что там страдает-то? > в этом и трабла... "Трабла", IMHO, в том, что PostgreSQL нередко пытаются "поднять" на "железе", которое и на помойку-то выбросить стыдно. А вот когда кто-то купил лицензии Oracle (почём они там сейчас за ядро? 17000$ или больше?), то полный идиотизм покупки под это железа за 400$ вполне очевиден, и покупают адекватное. Отсюда и разница в репутации, мне кажется.

справедливости ради, и на Оракл пытаются экономить (ещё как). там надо очень внимательно читать условия. скажем, не любая система виртуализации позволяет снизить кол-во ядер для лицензирования: вас заставят заплатить по кол-ву ядер на хосте, а не в гостевой ОСи.

"Вас заставят" же только увеличивает стоимость? Я это к тому, что если бы в подобных случаях можно было бы поменять "железо" местами, Oracle бы ничего не "потянул" (fairy dust в нём нет), а вот PostgreSQL — наоборот. ;)

да, увеличивает. “прелесть” Оракл в том, что можно всё. только потом заплатить надо будет. и очень много, т.к. некоторые опции очень неожиданны

ну я вероятно о том же. нет у нас DBA, который все может, или почти все.... и там кстате не только в ресурсах же проблема. попросить заоблачные мощности на сервер СУБД - любой может, много ума не нужно. пару дней с заказчиком поругаться и обосновать почему надо больше. а почему СУБД вдруг начинает "чудить" не с того ни с сего - 2 месяца было норм, а седня вдруг процы под 100%. я бы не преуменьшал роль DBA на проектах

тут надо ещё смотреть на то, что Oracle зачастую идёт как требование вендора к покупаемому продукту, и лицензии сразу закладываются в проект и сравниваются при поиске альтернатив. с Postrges-ом же часто нанимают ребят на разработку софта (и тут даже Postgres возникает, зачастую, случайно), они что-то делают и проект выходит в свет. на этом этапе DBA не рассматривается, ибо дорого и зачем? а через какое-то время начинаются описанные вами проблемы. и приходится искать DBA (или консультироваться). и потом разгребать это всё крайне трудоёмко: в 99% случаев надо перекраивать схему, а т.к. это тех-долг, всё откладывается в долгий ящик. ну и концепция “код важнее данных” тоже бесит!

> и там кстате не только в ресурсах же проблема. Именно в плане "репутации" (впечатлений пользовавшихся) коммерческих СУБД против бесплатных — это существенный фактор, мне кажется. > попросить заоблачные мощности на сервер СУБД - любой может, много ума не нужно Но не любой получит. :) И с PostgreSQL это произойдёт гораздо легче, нет? > а почему СУБД вдруг начинает "чудить" не с того ни с сего Мне кажется, такие истории я слышал "про всё". > я бы не преуменьшал роль DBA на проектах Я к тому, что преувеличивать тоже не стоит — stackoverflow "силами" подержанного PC из 2010-х ни один DBA (и даже все DBA и разработчики PostgreSQL вместе взятые) не поднимет. ;)

> (и тут даже Postgres возникает, зачастую, случайно), И, кстати, тоже да. Мне вот недавно знакомый рассказывал, что их поставщики перевели поставляемый продукт с MS SQL Server Express (бесплатного, но с ограничениями) на PostgreSQL (что было причиной, я так и не понял). И вот именно так: > они что-то делают и проект выходит в свет. и вышло — "первый блин комом". А "виноват", естественно, postgres. ;(

не совсем так. архитектура приложения и архитектура БД - скажем так по феншую построены. но проблемы все же возникают. и тут уже вопрос не в Oracle или не Postgres. вопрос наверно больше сможет ли тот же Postgres на тех же серверных мощностях то же самое сделать

А у меня встречный вопрос — почему PostgreSQL должен быть на тех же серверных мощностях? Может, их можно сильно увеличить, и намного выиграть, например (и, в том числе, по TCO)? ;)

позволю себе поворчать: в 90% случаев “по феншую” — это как удобно в ORM/фреймворке. сколько раз встречал ситуации, когда запрос можно ускорить на 2-3 порядка, но это требует нестандартной конструкции и поэтому рекомендации уходят в долгий ящик. но да, пару раз встречал грамотные проекты, где не было детских проблем, прям совсем. как вы говорите — по феншую…

ну это конечно интересно. а насколько нужно увеличить? на 10-20% или на порядок в 2-3 раза?

Как вообще можно рассуждать о сравнительной производительности неведомой базы данных в вакууме? ;) Это сравнивать нужно, тестировать. > на 10-20% или на порядок в 2-3 раза? А почему не на минус 20-30%, или в 0.2-0.3 раза, а? ;)

да у нас ORM. и как обычно "детские" болезни - это выборка из БД. но это нам не мешает. работало и работало. все тугие запросы в СУБД раньше отладили. но вот раз в 2-3 месяца СУБД начинает "чудить". и тогда DBA очень нехватает...

купите пакет консультационных часов и расходуйте их по необходимости. да, первые 3-4 часа улетят, т.к. надо разбираться в том, что у вас есть. зато потом как по маслу пойдёт!

Тото на моей прошлой работе аккурат на следующий же день после обновления с 11 на 12 все расчеты встали. Серваки тупо начали валиться. За исключением некоторых уже захинтованных запросов все планы встали с ног на голову, пришлось оптимизатор в режим совместимости переводить, а потом ещё долго выцеплять отдельные тормозящие запросы и дополнительно хинтовать. :)

Вот для этого тщательно тестируют миграцию БД и работу после неё, сохраняют старую статистику, иногда нужно пересобирать новую. Но dba для этого, конечно же, не нужен :)

потому что опытные разрабы могут почти все проблемы решить

Свежо предание, я видел как опытный сисадмин с базой работает... на мой взгляд он в ней ничего не понимал, но запуск/остановку освоил на отлично :)

зачем ее останавливать?)

Ну, проблему исправить, файлы rsync забекапить

какую проблему? есть же репликация

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

это разделение труда. каждый занимается своим делом. чем больше гранулярность тем лучше

Так должно быть

А кто её настраивал? Не было реплики, только бэкапы

ну это совсем молодые проекты) разрабы могли бы настроить

не встречал таких и даже не слышал, а судя по распространению orm и баз в докере - сказки всё это :)

любой личный круг знакомств - очень маленькая выборка

Согласен, сужу по этой группе. dba не в счёт, они здесь по-настоящему хорошие

а как вы отличаете DBA от не-DBA?

по вопросам одних и ответам других

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

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