Подобно 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)); (индексы должны быть выровнены).
Работа над RegreSQL заставила меня уделить много внимания буферам. Если вы иногда работаете с PostgreSQL, то наверняка слышали о настройке shared_buffers и следовали старому доброму совету выставить его на уровне 1/4 от доступной оперативной памяти. Но после того как мы немного слишком увлеклись этой темой в недавнем выпуске Postgres FM, меня спросили, что к чему.
Буферы — одна из тех тем, которую легко забыть. И хотя они являются фундаментальным блоком архитектуры производительности PostgreSQL, большинство из нас воспринимает их как чёрный ящик. Эта статья попытается это изменить.
Секционированные таблицы — это базовая возможность PostgreSQL, но один аспект по-прежнему регулярно вызывает путаницу — даже у опытных пользователей:
Как именно ведёт себя команда ALTER TABLE, когда задействованы секции?
Распространяется ли операция на секции? Влияет ли она на будущие секции? Действительно ли ключевое слово ONLY делает то, что заявлено? Почему некоторые команды работают на родительской таблице, но не на секциях — или наоборот?
Сегодня документация PostgreSQL хорошо описывает отдельные подкоманды ALTER TABLE, но редко объясняет их взаимодействие с секционированными таблицами в целом. В результате пользователи часто узнают о реальном поведении только методом проб и ошибок.
Эта статья обобщает систематическое исследование поведения ALTER TABLE для секционированных таблиц, превращая разрозненные правила в последовательную классификационную модель.
