Каждый специалист по SQL Server рано или поздно достигает точки, когда внутреннее устройство хранения перестаёт быть абстракцией. Вы узнаёте, что таблица — это не просто логический контейнер, а физическая структура, и эта структура определяется кластерным индексом. Строки находятся на листовом уровне B-дерева, ключ кластеризации определяет физический порядок, и каждый некластерный индекс в конечном итоге ссылается обратно на этот ключ. Как только эта модель укореняется, настройка производительности начинает казаться почти интуитивной. Сканирование диапазона ведёт себя предсказуемо, поиск по закладкам (bookmark lookups) обретает смысл, а фрагментация становится ожидаемым следствием того, как хранятся данные.
Вот почему первое знакомство с PostgreSQL часто вызывает чувство дезориентации. Вы ищете кластерные индексы, потому что, исходя из вашего опыта, серьёзная система управления базами данных просто обязана их иметь. В конце концов вы обнаруживаете команду CLUSTER и предполагаете, что нашли аналог. Затем вы понимаете, что это не постоянно, не автоматически и не принудительно. В этот момент PostgreSQL кажется неполноценным, словно в нём отсутствует фундаментальный механизм оптимизации.
Правда же заключается в том, что в PostgreSQL не отсутствуют кластерные индексы. Он сознательно выбрал иную основу.
Планировщик запросов PostgreSQL полагается на статистику таблиц для оценки количества строк (предполагаемое количество строк), которое будет обрабатывать каждая операция, а затем выбирает оптимальный план выполнения на основе этих оценок. Когда предполагаемое количество строк значительно расходится с фактическим, планировщик может выбрать неоптимальный план, что приводит к серьёзному снижению производительности запросов.
В этой статье рассматриваются четыре подхода, которые я использовал для снижения ошибок оценки количества строк, упорядоченные от наименее до наиболее вмешивающихся в систему. Из-за ограничений конфиденциальности я не могу делиться фактическими SQL-запросами или планами выполнения, поэтому основное внимание уделяется диагностике и применяемым методам.
Тема настройки контрольной точки часто обсуждается в многочисленных блогах. Тем не менее, я постоянно сталкиваюсь со случаями, когда эта настройка остаётся неоптимизированной, что приводит к огромной растрате серверных ресурсов, борьбе с низкой производительностью и другим проблемам.
Поэтому настало время снова подчеркнуть её важность, но уже с большим количеством деталей, особенно для новых пользователей.
Подобно XML, JSON является открытым стандартным форматом хранения данных, метаданных, параметров или других неструктурированных или полуструктурированных данных. Из-за его активного использования в современных приложениях он обречен попасть в базы данных, где его необходимо будет хранить, сжимать, изменять, выполнять поиск и извлекать.
Несмотря на то, что реляционные базы данных не являются идеальным местом для хранения и управления мало структурированными данными, требования, предъявляемые приложениями, могут зачастую преодолевать "оптимальный" проект базы данных. Это удобно иметь данные JSON рядом со связанными с ними реляционными данными и эффективная организация хранилища с самого начала может сэкономить значительное время и ресурсы в будущем.
При планировании миграции баз данных в PostgreSQL именно мелочи часто становятся причиной самых серьёзных сбоев в рабочей среде. Одна из самых распространённых ловушек для разработчиков — это различная обработка значений NULL и пустых строк ('') в разных СУБД.
Хотя они могут казаться схожими концепциями, обозначающими отсутствие значения, то, как механизм базы данных их интерпретирует, может изменить результаты ваших запросов, нарушить уникальные ограничения или привести к сбоям загрузки данных. В этом руководстве мы сравним поведение Oracle, SQL Server и PostgreSQL, чтобы помочь вам избежать распространённых ошибок миграции.
Блокировки на уровне строк часто являются узким местом в производительности в среде баз данных с высокой конкуренцией. Когда транзакция ожидает блокировку на конкретную строку, это может привести в действие цепь задержек, которые трудно диагностировать. К счастью, PostgreSQL предоставляет мощный инструмент в модуле contrib, чтобы вытащить на свет эти неуловимые блокировки: pgrowlocks.
В этом руководстве мы представим практический подход к использованию pgrowlocks. Мы начнем с установки расширения с последующей имитацией блокировки, чтобы увидеть ее в действии и, наконец, построим мощную глобальную функцию для идентификации блокировок уровня строки по всей базе данных с данными о пользователе, запросе и продолжительности. Продолжить чтение "Как обнаружить и устранить конфликты на уровне строк в PostgreSQL с помощью pgrowlocks"
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)); (индексы должны быть выровнены).
