Задача
Определить причины снижения производительности в период 11:35 - 12:15 .
Ниже предлагается примерный порядок действий по установлению наличия инцидента снижения производительности и определению одной из причин.
В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL. В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов.
Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками.
Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :
Приветствую тебя читатель, я решил написать про ACID и Транзакции PostgreSQL своим языком, с понятными примерами, эта статья ориентирована на людей готовящихся к собеседованию, кто захотел узнать нюансы транзакций в PostgreSQL или про ACID, а также для людей которые знают теорию, но сами ещё ни разу не писали транзакции. Я не ставил перед собой цели рассмотреть и объяснить работу транзакций на очень глубоком уровне. Была цель привести понятные примеры, дать макет работы с транзакциями, а также пощупать основные возможные проблемы при работе с транзакциями в PostgreSQL.
Это пятая, заключительная часть статьи, в которой я скажу пару слов про расширения, мониторинг, а также подведу некоторые итоги по статье в целом.
Это четвертая часть статьи, в которой мы научимся работать с логическими и физическими резервными копиями, а также сравним алгоритмы сжатия.
Это третья часть статьи, в которой мы научимся работать с базами, ролями, консолью, а также политиками подключений.
Это вторая часть статьи, в которой мы разберем процессы очистки и перестроения индексов, журнал предзаписи с чекпоинтами, а также логирование.
Эта статья предназначена для системных администраторов, которые хотят научиться работать с PostgreSQL, но не знают, с чего начать.
Пару дней назад был опубликован пост с решением на MySQL загадки Джиндоша (она же загадка Эйнштейна).
Предложенное решение показалось мне "неспортивным" - помимо необходимости жестко учитывать в структуре запроса количество исходных элементов ("джойнить" нужные таблицы нужное количество раз), так еще и условия в запросе приходилось многократно дублировать.
Поэтому я попробовал решить эту задачу "в общем виде", используя возможности PostgreSQL, и вот что из этого получилось.
Я часто пользуюсь своей утилитой "rucken" по копированию файлов и директорий с кодом, но для генерации конфигураций деплоя по шаблонам я использовал баш скрипты, в которых помимо различных условий происходит копирование через команду "cp" и замена переменных через команду "sed".
На днях подумал и решил что часть с копированием и заменой можно убрать в утилиту "rucken" и тем самым оставить в баш скриптах только логики с условиями.
Однажды нам нужно было уменьшить мастер кластера PostgreSQL по CPU и памяти. План был надёжный: дождаться низкой нагрузки на кластер, сменить мастер на одну из асинхронных реплик, переконфигурировать виртуальную машину с бывшим мастером и сделать switchover обратно. Казалось бы, что могло пойти не так?
Карта видимости - это достаточно простой механизм в СУБД PostgreSQL, но даже он имеет множество интересных тайн, если погрузиться в детали реализации.
В этой статье мы выясним:
1. Какие особенности есть у механизма сбрасывания и установки бита полной видимости.
2. Как Index only scan использует бит полной видимости.
3. Зачем записывать информацию об изменении карты видимости в WAL.
4. Каким образом карта видимости участвует в оптимизации предвыборки Bitmap scan.
5. Зачем механизму оценки селективности нужна карта видимости.
Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".
В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.
Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.
Это вторая часть статьи, в которой обсуждаются вспомогательные функции, использующиеся функциями предназначенными для непосредственного формирования PlantUML-скриптов. Основные процедур и функции обсуждались в первой части статьи. Здесь же присутствует контрольный пример с таблицами, которые использовались для демонстрации функций.
Статья продолжает знакомить с функциями для документирования баз данных PostgreSQL. Но на этот раз речь пойдет о специальных функциях, подготавливающих описания диаграмм классов на языке PlantUML.
В качестве основного средства документирования выбрана система управления проектами TRAC с подключенным плагином plantuml.
В 1970-х годах известный программист Эдгар Кодд разработал математически выверенную теорию организации данных в виде таблиц (реляций). С тех пор утекло немало воды — появилось большое количество различных коммерческих и open-source реляционных систем управления базами данных (РСУБД). Скоро стало понятно, что эффективное получение данных из базы — задача далеко не тривиальная. Если говорить прямо, она нелинейная и в общем случае NP-сложная.
Когда SQL-запрос становится немного сложнее: SELECT * FROM table, у нас появляется огромная вариативность его исполнения внутри системы — и не всегда понятно, какой из возможных вариантов эффективнее как по памяти, так и по скорости. Чтобы сократить огромное количество вариантов до приемлемого, обычно используются так называемые эвристики — эмпирические правила, которые придуманы человеком для сокращения пространства поиска на несколько порядков. Понятное дело, эти правила могут отсечь и сам оптимальный план выполнения запроса, но позволяют получить хоть что-то приемлемое за адекватное время.
В последние годы в связи с активным развитием ML начали развиваться и нейронные оптимизаторы запросов —особенность которых в том, что они самостоятельно, без участия человека, находят необходимые закономерности в выполнении сложных планов исходя из обучения на огромном количестве данных. Тенденция началась приблизительно в 2017 году и продолжается до сих пор. Давайте посмотрим, что уже появилось в этой области в хронологическом порядке и какие перспективы нас ждут.
Приветствую, коллеги!
Я занимаюсь разработкой 1С, поэтому, регулярно, на выходных исоледую различные варианты развёртывания серверов 1С под разработку (различные версии или комбинации)
В этот раз решил провести эксперимент с Rapsberry PI 5. К этому времени у меня был развернут на ней сервер хранилищ данных для нескольких версий 1С, опубликованный через apache2 и база разработки файловая, опубликованная через apache2.
Решил добавить клиент-серверную архитектуру для доступа с рабочего места для импорта проекта в EDT. Для этого развернуть сервер 1С 8.3.24.1548 и сервер PostgresPro-std-16.
В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.
Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.
После выхода релиз-кандидата версии 17 в плане выпуска осталась последняя незакрытая дата: 26 сентября 2024 года. На этот день намечен официальный выпуск PostgreSQL 17.
В этой статье рассказывается о патчах, принятых в ходе последнего мартовского коммитфеста. Предыдущие статьи о коммитфестах 17-й версии: 2023-07, 2023-09, 2023-11, 2024-01.
Все вместе они дают подробное представление о новой версии СУБД.
Возможно ли применить статический анализ структуры базы данных к реальным проектам, которые используют PostgeSQL, какой будет результат? Давайте применим и посмотрим что получится. В качестве реальных проектов возьмем инструменты с открытым кодом, которыми многие пользуются ежедневно - GitLab и Redmine.
