Что должен уметь делать администратор postgres?

и ничего про оптимизацию SQL-запросов.

по твоей же ссылке

II. Язык SQL
14. Оптимизация производительности

но никак не на боевой системе, находящейся в промышленной эксплуатации.

если весь твой бизнис зависит от одного одмина, то вообще насрать, эта жадная шарага сдохнет при первом же факапе.

На рынке полно специалистов, которые умеют и субд и не субд, если коротко

Вот именно. И очень странно, мягко говоря, нанимать в проект на Oracle специалиста по MariaDB и наоборот. Более того, из двух соискателей, один из которых имеет поверхностные знания по обеим СУБД (тот самый широкий кругозор), а второй - многолетний опыт администрирования именно той СУБД, которая используется в проекте, любой вменяемый работодатель выберет вторую кандидатуру.

расходы на заработную плату в ИТ самая большая статья расхода и когда бизнесу нужно экономить, будут нанимать универсалов, благо их достаточно.

Ошибаетесь. Простой всего предприятия, вызванного сбоем в информационной системе, обслуживающей бизнес-процессы компании, стоит несоизмеримо дороже зарплат всего IT-отдела. А в некоторых особо тяжелых случаях может вообще к потере бизнеса привести...

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

Никогда не имел дела с этими конторами, так что спорить тут мне сложно. Но я очень сомневаюсь, что соискателю на должность DBA будут задавать вопросы по конфигурированию оборудования Cisco, например. Как, впрочем, и наоборот...

а если знаешь, что тебе мешает делать настройку кластера?

Причем тут настройка кластера? Все, что я хотел сказать тем сообщением, это то, что не дело DBA самому писать SQL-запросы. Это работа разработчиков...

по твоей же ссылке

Если Вы обратили внимание, ссылка приведена на мануал по PostgreSQL. Который предназначен в первую очередь для разработчиков. Задачи DBA сводятся к администрированию СУБД. Поэтому я отдельно процитировал раздел документации, посвященный именно администрированию. Оптимизация производительности вынесена в другой раздел и это явно неслучайно...

что соискателю на должность DBA будут задавать вопросы по конфигурированию оборудования Cisco, например.

конечно не будут, зачем ему это? а вот строение пакета, как пакет по сети ходит и прочее вполне себе могут спросить, как и про работу дисковой подсистемы, также и про работу мьютексов-семафоров. я, конечно же, про приличные организации, там, где от работы айти реально зависит жизнь конторы.

мануал по PostgreSQL. Который предназначен в первую очередь для разработчиков.

откуда ты эту ересь взял? открываем пятый раздел

Часть V. Серверное программирование Эта часть документации посвящена расширению функциональности сервера путём реализации собственных функций, типов данных, триггеров и т. д. Это довольно сложные темы, для освоения которых рекомендуется предварительно изучить и понять всю остальную документацию для пользователей PostgreSQL.

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

что не дело DBA самому писать SQL-запросы.

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

для пользователей, понимаешь?

Я-то понимаю :). А вот Вы меня, судя по всему, не поняли. Под разработчиками я имел ввиду не разработчиков самого PostgreSQL, а программистов, создающих приложения, работающие с PostgreSQL. В противоположность администраторам баз данных (DBA)...

настривать автовакуум

как-то очень специально его настраивать не надо и настройки там тривиальные, специфика только в том, чтобы понимать как и зачем он работает

репликацию

что там специфичного? статья в документации на полчаса вдумчивого чтения

ну хоть не девопс.

для многих это одно и тоже

Как видите, здесь очень много задач, непосредственно связанных с обеспечением сохранности и доступности данных, и ничего про оптимизацию SQL-запросов.

это администрирование сервера, не DBA. еще раз, DBA должен уметь работать с логикой базы, простой админ не должен.

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

ты плохо понимаешь о чем говоришь, потому что для новой версии приложения почти всегда не поднимается новая база, а происходит миграция данных, которая состоит из отдельных запросов. кто на чем стоял? расскажи это людям у которых на одном проекте по 2-3 релиза в день, услышишь много новых шуток.

Под разработчиками я имел ввиду не разработчиков самого PostgreSQL, а программистов, создающих приложения, работающие с PostgreSQL

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

И что, бизнес будет ждать эту неделю? А если на второй день факап?

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

Или все-таки наймете человека, который сможет решить вопрос за один вечер?

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

Но расширять кругозор можно и нужно дома, на курсах, в конце концов, на работе на стенде, но никак не на боевой системе, находящейся в промышленной эксплуатации.

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

да я стебусь, развелось сре-девопсов всяких, нормальному админу ступить некуда :D

Вот именно. И очень странно, мягко говоря, нанимать в проект на Oracle специалиста по MariaDB и наоборот. Более того, из двух соискателей, один из которых имеет поверхностные знания по обеим СУБД (тот самый широкий кругозор), а второй - многолетний опыт администрирования именно той СУБД, которая используется в проекте, любой вменяемый работодатель выберет вторую кандидатуру.

ты с умным видом говоришь очевидные вещи приводя это все в аргумент спора, посмотри на это под другим углом

Простой всего предприятия, вызванного сбоем в информационной системе, обслуживающей бизнес-процессы компании, стоит несоизмеримо дороже зарплат всего IT-отдела.

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

Но я очень сомневаюсь, что соискателю на должность DBA будут задавать вопросы по конфигурированию оборудования Cisco, например. Как, впрочем, и наоборот...

а опытного системного администратора будут, и про то и про это :)

не дело DBA самому писать SQL-запросы. Это работа разработчиков...

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

развелось сре-девопсов всяких

SRE это просто одна из верхних ступенек для админа, а девопс это вообще очень растяжимое понятие. в целом это все админы и есть.

• сидеть на стуле

• пить пиво

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

быть админом не модно и не молодёжно

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

как-то очень специально его настраивать не надо

Что значит «очень специально»?

что там специфичного?

Есть бд в которую все постоянно пишут, но каждый вечер нужно по этой бд делать запрос длительностью 2-3 часа.

На моей прошлой работе, я писал мануалы и FAQ для админов, а чуть что, они прибегали ко мне или другим разработчикам. Так что по-разному бывает. Ну и MySQL мы сами тюнили, в том числе в эксплейны задрачивали, а я так вообще свои триггеры для агрегации профайлил, никаких DBA у нас не было, бекапы тоже сами пилили (тупо по крону, и иногда на тесте разворачивали), ибо админы у нас были не очень.

репликацию

что там специфичного? статья в документации на полчаса вдумчивого чтения

Как показывает практика, вот с этих слов и начинаются проблемы.
Из приведенного выше Serge10
31. Логическая репликация

Это какой-то особо запущеный подвид стартапа.

Ещё забавнее, когда отдел дба исправляет косяки 25 летних сеньор недодевелоперов ака девопс ака сре.

Конторе больше 10 лет, не стартап уже. Там по части софта культура страдает из-за того, что контора в основном зарабатывает на продаже железа, а не софта. И то, что железо нафиг никому не всралось без софта и грамотной службы эксплуатации, до руководства не до конца доходит. Оттуда и проблемы.

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

Ну вы молодцы, коли так, потому что чаще бывает содом и гомора, когда нет дба или хотя бы толковых сисадминов.

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

достаточно написать инструкцию)

переносимость, обеспечение консистентности данных, понимание архитектуры бд

Тебе бы рекламные буклеты писать. «Делает хорошо», «светлое будущее», «гиперконвергентность», а конкретика по делу закончилась три запятых назад.

Вырасту стану как стиви евангелистом всякой херни.

Что значит «очень специально»?

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

Есть бд в которую все постоянно пишут, но каждый вечер нужно по этой бд делать запрос длительностью 2-3 часа.

и чего дальше?

MySQL мы сами тюнили, в том числе в эксплейны задрачивали

дык, если нет дба, то кто-то берет его функцию, или админы или разрабы или вместе, но лучше все-таки админы, так как dba это больше про администрирование все же, ну если могут опять же. тут просто Serge10 пытался доказать, что если есть база, то нужен дба, который должен только чуть-чуть базоньку админить, а если там что с запросами, то это к программистам, которые их писали :)

31. Логическая репликация

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

во-вторых, что именно ты имел ввиду?

25 летних сеньор недодевелоперов ака девопс

Это само по себе смешно, 25 лет считай год после института, а уже SRE/Devops

отдел дба исправляет косяки

ну это их работа в общем-то, всегда спокойнее, когда кто-то может исправить твои косяки)

Л - логика. Что ещё не понятно? Мне не нужна полная репликация, считай бэкап, а нужна только некоторая часть. Например часть в одну сторону, а другая часть в обратную.

всегда спокойнее, когда есть на кого свалить твои косяки

Поправил

Например часть в одну сторону, а другая часть в обратную.

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

вот и мне интересно, что там такого необычного

Ну покажи мне другую бд с автовакуумом.

и чего дальше?

Ну то что стандартный кейс в котором нужно уметь настроить репликацию.

всегда спокойнее, когда есть на кого свалить твои косяки
Поправил

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

Это само по себе смешно, 25 лет считай год после института, а уже SRE/Devops

А что смешного? Про sre вообще шляпа - под рукой готовый плейбук от разрабов, что делать. Про девопс еще более-менее, но какая разница во сколько лет писать скрипты?

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

Ты давно видел простыни по 5000 строк кода на pl/sql?

Ну покажи мне другую бд с автовакуумом.

если у тебя есть опыт работы с любой субд, то выяснить и понять что такое автовакуум в постгресе занимает около 30 минуты, плюс минус в зависимости от твоей соображалки. дальше еще за полчаса можно понять как его можно настроить. это элементарные вещи, для них не нужна дополнительная квалификация

Ну то что стандартный кейс в котором нужно уметь настроить репликацию.

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

Про sre вообще шляпа - под рукой готовый плейбук от разрабов, что делать

не очень понял? sre это человек которые отвечает за весь проект со стороны эксплуатации. да и плейбуки, если их пишут разрабы, то sre должен их читать и править. вообще доверять инфраструктурные скрипты разрабам не стоит.

Про девопс еще более-менее, но какая разница во сколько лет писать скрипты?

потому что девопс это не про скрипты, а про опыт. чтобы делать infrastructure as code, надо очень хорошо понимать как и что работает. в 25 лет редко у кого есть такой опыт.

Ты давно видел простыни по 5000 строк кода на pl/sql?

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

sre это человек которые отвечает за весь проект со стороны эксплуатации. да и плейбуки, если их пишут разрабы, то sre должен их читать и править. вообще доверять инфраструктурные скрипты разрабам не стоит.

Угу, я тоже думал, что это архитектор. Но послушал ребят из гугла на этой позиции. Это просто онкол опс с плейбуком, не более того. Есть вторая честь - когда он может на стадии реализации приложения подсказать стандартные опс паттерны обеспечения отказоустойчивости и прочего, но она не такая большая.

потому что девопс это не про скрипты, а про опыт. чтобы делать infrastructure as code, надо очень хорошо понимать как и что работает. в 25 лет редко у кого есть такой опыт.

Про опыт - это архитектор, а не девопс. Буквально позавчера наблюдал проект с пачкой команд разработки без единого девопс/инженера качества. Неплохо живут в авс, вопросов нет.

Так разрабы постоянно уходят и приходят, это норма жизни. Давно ли в биллинги заглядывал? )

Ну а вторая часть, это возвращение написания логики на SQL в аналитических базах нового поколения - сноуфлейк и иже с ними.