Серия «ITшное»

В дополнении к старой записи Мысли вслух - 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 так происходит?

1. Невероятная гибкость и настраиваемость. PostgreSQL — это не черный ящик. Это конструктор с тысячами винтиков и гаек (параметров конфигурации). Такая свобода требует глубокого понимания, но на практике приводит к тому, что люди начинают крутить ручки наугад.

2. Огромное количество расширений (extensions). Каждое расширение — это новый пласт потенциальной магии и алхимии. Специалист становится «заклинателем», который приручает эти расширения, не всегда имея возможность заглянуть в их исходный код.

3. Сложность внутренних механизмов. Такие вещи, как MVCC (Multiversion Concurrency Control), — это очень сложно. Многие используют их, но далеко не все понимают до конца, как именно работает управление версиями строк, транзакциями и их номерами.

Где же ученые и исследователи в мире PostgreSQL?

Они есть, и их работа фундаментальна:

• Команда разработчиков ядра PostgreSQL. Это именно ученые и инженеры, которые проводят исследования, докапываются до сути, пишут академические работы и реализуют новые функции (например, новые типы индексов, улучшения оптимизатора запросов).

• Авторы научных статей и докладчики на крупных конференциях. Люди, которые анализируют производительность на уровне дисковых подсистем, памяти, процессоров и строят математические модели работы СУБД.

• Эксперты по теме, пишущие книги. Такие авторы, как например, Ханс-Юрген Шёниг (Hans-Jürgen Schönig), разбирают сложные концепции и переводят их с «магического» языка на язык инженерии.

Вывод:

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

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

Каждый пункт - в точку ! Особенно про автовакуум это 100%.

Мне больше интересно быть ученым и исследователем. За 38 лет наремесленичался с избытком.

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

Вопрос непраздный:
Открыть ли код?
Ответ неясный:
Да, может, вот.

Исходник в общем
Свободен весь.
В открытом коде
Полезность есть.
-------
💫 Создано с помощью GigaChat

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

Когда программное обеспечение публикуется под открытой лицензией (например, GPL, MIT, Apache), разработчики получают множество значимых преимуществ, которые способствуют повышению эффективности работы команды, снижению рисков и созданию конкурентоспособных решений. Рассмотрим подробнее основные преимущества такой стратегии.

▌ 1. Ускоренная разработка и привлечение сообщества разработчиков

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

▌ 2. Повышение надежности и безопасности продукта через коллективный аудит

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

▌ 3. Формирование активного сообщества поддержки

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

▌ 4. Положительное влияние на репутацию компании-разработчика

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

▌ 5. Снижение расходов на инфраструктуру и инструменты разработки

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

---
▌ Выбор между открытым и закрытым подходами

Перед принятием окончательного решения о публикации проекта стоит учесть следующие факторы:

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

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

Итого, прежде чем выбрать путь развития своего проекта, необходимо чётко понимать цели компании, состояние продукта и возможные после
-------
💫 Создано с помощью GigaChat