PostgreSQL может чрезвычайно хорошо масштабироваться в производственной среде, но многие развертывания работают на консервативных значениях по умолчанию, которые безопасны, но далеки от оптимальных. Суть оптимизации производительности заключается в том, чтобы понимать, что на самом деле контролирует каждый параметр, как параметры взаимодействуют в условиях параллельной работы и как проверять влияние с помощью реальных метрик.
Это руководство проведёт вас через два самых важных параметра памяти:
Начиная с PostgreSQL 17, сообщество базы данных получило долгожданную функцию: инкрементные бэкапы. Наряду с этим появился новый инструмент, pg_combinebackup, который играет важную роль в создании этих резервных копий на практике.
Запрос выполняется всего за 2 миллисекунды, но этап его планирования занимает 500 мс. База данных имеет разумный размер, запрос затрагивает 9 таблиц, а default_statistics_target установлен всего в 500. Откуда такое несоответствие?
Этот вопрос недавно был поднят в списке рассылки pgsql-performance, и расследование выявило несколько неожиданного виновника: статистика столбцов, хранящаяся в таблице pg_statistic PostgreSQL.
Если бы Дарт Вейдер существовал и решил бы сделать с Землёй то же, что он сделал с Алдерааном, все потеряли бы данные.
Мне нравится эта цитата Роберта Хааса, потому что это отрезвляющая реальность, которая нужна всем нам. В мире баз данных нам постоянно продают мечту о «пяти девятках» (99,999% времени доступности) и «нулевой потере данных» (RPO=0). Мы тратим месяцы на построение сложных кластеров, чтобы достичь этого.
Давайте будем честными: это сказки. Красивые для воображения, но они не существуют в рабочей среде. Если планетарная лазерная пушка — или даже просто серьёзный сетевой обрыв — поразит ваш дата-центр, ваши «гарантии» исчезнут.
Моя цель сегодня — не помочь вам поверить в сказки. Моя цель — помочь вам построить архитектуру, которая действительно работает.
Индексы существуют для ускорения доступа к данным. Они позволяют PostgreSQL избегать полного просмотра таблицы, значительно сокращая время выполнения запросов для рабочих нагрузок с интенсивным чтением.
Из реального производственного опыта мы наблюдали, что хорошо спроектированные, целевые индексы могут улучшить производительность запросов в 5 и более раз, особенно на больших транзакционных таблицах.
Однако индексы не являются бесплатными.
И в этой статье мы обсудим, какие проблемы могут вызывать неиспользуемые индексы и как удалить их из производственных систем с планом отката, безопасно.
Усечение таблицы может быть замечательно быстрым - и чрезвычайно опасным при неосмотрительном использовании. Если вы хотите иметь скорость и не разочароваться, тут дается практическое, готовое для интервью руководство по реальным подводным камням TRUNCATE TABLE в SQL Server и то, как избежать их.
Справка
TRUNCATE TABLE является операцией DDL, которая освобождает страницы (эффективно журнализированные) и сбрасывает IDENTITY к начальному значению. При этом триггеры DELETE не срабатывают. Возможен откат при выполнении внутри транзакции.
Завершается неудачно, если на таблицу ссылается внешний ключ (даже если дочерняя таблица пуста), используется в индексированных представлениях, является системно-версионной (временной), опубликованной для репликации или включена для CDC, или на нее ссылается ограничение EDGE графа. Существует специальная возможность для самоссылающихся внешних ключей.
Начиная с SQL Server 2016, вы можете усекать конкретные секции: TRUNCATE TABLE dbo.Fact WITH (PARTITIONS (4 TO 6)); (индексы должны быть выровнены).
Работа над RegreSQL заставила меня уделить много внимания буферам. Если вы иногда работаете с PostgreSQL, то наверняка слышали о настройке shared_buffers и следовали старому доброму совету выставить его на уровне 1/4 от доступной оперативной памяти. Но после того как мы немного слишком увлеклись этой темой в недавнем выпуске Postgres FM, меня спросили, что к чему.
Буферы — одна из тех тем, которую легко забыть. И хотя они являются фундаментальным блоком архитектуры производительности PostgreSQL, большинство из нас воспринимает их как чёрный ящик. Эта статья попытается это изменить.
Секционированные таблицы — это базовая возможность PostgreSQL, но один аспект по-прежнему регулярно вызывает путаницу — даже у опытных пользователей:
Как именно ведёт себя команда ALTER TABLE, когда задействованы секции?
Распространяется ли операция на секции? Влияет ли она на будущие секции? Действительно ли ключевое слово ONLY делает то, что заявлено? Почему некоторые команды работают на родительской таблице, но не на секциях — или наоборот?
Сегодня документация PostgreSQL хорошо описывает отдельные подкоманды ALTER TABLE, но редко объясняет их взаимодействие с секционированными таблицами в целом. В результате пользователи часто узнают о реальном поведении только методом проб и ошибок.
Эта статья обобщает систематическое исследование поведения ALTER TABLE для секционированных таблиц, превращая разрозненные правила в последовательную классификационную модель.
Раздувание таблиц в PostgreSQL — это явление, при котором «мёртвые записи» (dead tuples), образовавшиеся в результате операций UPDATE или DELETE, не собираются процессом VACUUM, что приводит к неоправданному увеличению размеров файлов данных.
Чтобы VACUUM мог освободить мёртвые записи, должна быть гарантия, что эти записи «точно не могут быть использованы какими-либо активными на данный момент транзакциями». Если старые транзакции сохраняются по какой-либо причине, сборка мусора процессом VACUUM останавливается на этой точке.
В этой статье объясняются следующие четыре причины раздувания таблиц: как каждая проявляется, как определить коренную причину и как её устранить.
Длительные транзакции
Незавершённые подготовленные транзакции
Запросы на серверах-репликах с включённым параметром hot_standby_feedback
Когда дело доходит до оптимизации баз данных, разработчики часто хватаются за одни и те же старые инструменты: немного переписать запрос, навесить индекс на столбец, денормализовать, проанализировать, очистить, перестроить кластер и т.д. Традиционные методы эффективны, но иногда творческий подход может принести реальную пользу!
В этой статье я представляю нестандартные методы оптимизации в PostgreSQL.
Когда специалисты по SQL Server начинают серьёзно работать с PostgreSQL, большая часть обучения кажется комфортной. Таблицы ведут себя ожидаемо, транзакции знакомы, а B-деревья выглядят обнадёживающе похожими на то, что вы использовали годами в SQL Server. Затем вы сталкиваетесь с индексами BRIN.
На первый взгляд они кажутся почти безрассудными: нет указателей на строки, нет точной навигации и явное принятие ложных срабатываний. И всё же на очень больших таблицах индексы BRIN часто обеспечивают прирост производительности, для достижения которого в SQL Server потребовались бы кластерные индексы, секционирование или даже columnstore-индексы. Чтобы понять почему, нужно посмотреть не только на то, что делает BRIN, но и на то, как он работает внутри.
Молодые программисты выросли с ASCII и Unicode как единственными способами представления символьных данных в компьютере. Но в тёмные века, до того как мы изобрели грязь и вошли в каменный век, были и другие претенденты.
