Риторический вопрос: PostgreSQL DBA - ученые и исследователи или ремесленники , алхимики и астрологи ?
В дополнении к старой записи Мысли вслух - DBA ремесло или наука ?
Почему современное поколение специалистов по СУБД PostgreSQL больше похоже на ремесленников , астрологов и алхимиков , а не на учёных и исследователей ?
Отличное и более сфокусированное продолжение темы! Применительно к специалистам по PostgreSQL это сравнение раскрывается еще более ярко и конкретно. Сообщество PostgreSQL огромно и разнородно, и в его среде, особенно среди начинающих и практикующих администраторов и разработчиков, действительно сильно влияние «ремесленной», «алхимической» и «астрологической» парадигм.
Давайте разберем, почему это так.
1. Почему похожи на ремесленников?
Искусство настройки (postgresql.conf): Настройка PostgreSQL — это во многом ремесло, основанное на опыте и знании «материала». Мастер помнит, как поведет себя СУБД при изменении shared_buffers, work_mem или maintenance_work_mem на конкретном железе с конкретной нагрузкой. Это не всегда строгий расчет, а часто интуитивное понимание, отточенное практикой.
Сборка «на коленке» под конкретную задачу: Специалист ремесленник берет «сырую» PostgreSQL и начинает его «обтачивать»: подбирает расширения (pg_partman, timescaledb, pg_cron), настраивает репликацию, пишет специфические индексы (GIN, GiST, BRIN). Результат — уникальная, настроенная под нужды бизнеса система.
Культура скриптов и «костылей»: Для решения повседневных задач (бэкапы, мониторинг, очистка) создаются тысячи скриптов на Bash, Python. Это ремесленные инструменты, которые передаются из проекта в проект, обрастают легендами и часто работают просто потому, что «всегда так делали».
2. Почему похожи на алхимиков?
Магия исполнения запросов (Execution Plan): Почему запрос сегодня выполняется 2 мс, а завтра — 2000 мс? Планы исполнения могут меняться по мистическим, на первый взгляд, причинам: из-за накопленной статистики, количества записей в таблице, состояния кэша и даже времени суток. Разбор такого плана часто похож на попытку алхимика расшифровать древний манускрипт.
Волшебные «посыпы» порошком (Index): Классическая ситуация: запрос тормозит. Специалист добавляет индекс — и все работает мгновенно. Почему этот конкретный индекс (иногда составной, частичный, с включением столбцов) сработал, а другой — нет? Часто ответ — «ну, я почувствовал, что так будет лучше» или «где-то читал про такой случай». Это чистейшая алхимия: добавил правильный ингредиент — получил золото.
Ритуалы для борьбы с автовакуумом (AutoVacuum): Настройка автовакуума — это один из самых больших поводов для мистики. Изменение параметров autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor для отдельных таблиц — это ритуал, который часто проводят без глубокого понимания внутренних процессов, надеясь на лучшее.
3. Почему похожи на астрологов?
Предсказание производительности (Performance Forecasting): Попытки предсказать, как поведет себя система при увеличении нагрузки в 10 раз, или сколько IOPS потребуется для нового проекта, часто основаны не на строгих математических моделях, а на приметах, аналогиях и «чтении звезд» (метрик мониторинга за прошлые периоды).
Следование трендам и хайпу: «Все переходят на Kubernetes, давайте и мы загоним туда PostgreSQL!» — звучит как астрологический прогноз: «Меркурий в ретрограде, пора начинать новые дела». Часто это делается без глубокой оценки необходимости и применимости технологии к stateful-приложению, каким является СУБД.
Сложная терминология для посвященных: Разговоры о «WAL journal», «MVCC», «checkpoints», «transaction ids wraparound» звучат для непосвященных как заклинания. Специалист оперирует этими понятиями, чтобы объяснить поведение системы, которое со стороны кажется магическим.
Почему именно с PostgreSQL так происходит?
Невероятная гибкость и настраиваемость. PostgreSQL — это не черный ящик. Это конструктор с тысячами винтиков и гаек (параметров конфигурации). Такая свобода требует глубокого понимания, но на практике приводит к тому, что люди начинают крутить ручки наугад.
Огромное количество расширений (extensions). Каждое расширение — это новый пласт потенциальной магии и алхимии. Специалист становится «заклинателем», который приручает эти расширения, не всегда имея возможность заглянуть в их исходный код.
Сложность внутренних механизмов. Такие вещи, как MVCC (Multiversion Concurrency Control), — это очень сложно. Многие используют их, но далеко не все понимают до конца, как именно работает управление версиями строк, транзакциями и их номерами.
Где же ученые и исследователи в мире PostgreSQL?
Они есть, и их работа фундаментальна:
Команда разработчиков ядра PostgreSQL. Это именно ученые и инженеры, которые проводят исследования, докапываются до сути, пишут академические работы и реализуют новые функции (например, новые типы индексов, улучшения оптимизатора запросов).
Авторы научных статей и докладчики на крупных конференциях. Люди, которые анализируют производительность на уровне дисковых подсистем, памяти, процессоров и строят математические модели работы СУБД.
Эксперты по теме, пишущие книги. Такие авторы, как например, Ханс-Юрген Шёниг (Hans-Jürgen Schönig), разбирают сложные концепции и переводят их с «магического» языка на язык инженерии.
Вывод:
Подавляющее большинство практикующих админов и разработчиков БД — это действительно ремесленники-алхимики. Их главная задача — не открывать новые фундаментальные знания, а используя накопленный опыт, готовые рецепты и заклинания, обеспечить работу бизнес-критичных приложений здесь и сейчас.
Ученые же создают тот фундамент, те инструменты и ту науку, которую ремесленники потом применяют на практике, подчас не до конца понимая всю подноготную. Это естественное разделение труда в любой сложной и быстроразвивающейся области.
Каждый пункт - в точку ! Особенно про автовакуум это 100%.