PostgreSQL получил широкое распространение благодаря тому, что снимает лицензионные ограничения и даёт таким компаниям, как OpenAI, Lovable и Supabase, надёжную основу для масштабной эксплуатации производственных систем. Однако после развёртывания разговор о стоимости PostgreSQL смещается с лицензирования к тому, насколько эффективно база данных поддерживает выполняемую на ней рабочую нагрузку.
Начальные оптимизации, такие как индексы, дизайн запросов и пути доступа, часто остаются неизменными по мере развития систем. Со временем эти устаревшие решения приводят к неэффективности, вызывая замедления работы и истощение ресурсов. Вместо того чтобы устранять первопричину, команды часто масштабируют инфраструктуру и увеличивают операционные накладные расходы. В результате система продолжает функционировать, но с существенно более высокими затратами, чем необходимо. Если вы понимаете, откуда исходит неэффективность, вы можете исправить её должным образом, а не просто «забрасывать» проблему дополнительными ресурсами.
На практике это часто становится заметным по таким сигналам, как увеличение размеров инстансов с течением времени, повторяющиеся проблемы с производительностью, замедление работы отчётов по мере роста данных или увеличение времени, которое инженеры тратят на исследование поведения базы данных.
Модель хранения в PostgreSQL отличается от многих других баз данных. Вместо переписывания строки по месту, PostgreSQL создает новые версии строк при обновлении данных. Эта схема хороша для безопасности транзакций и параллелизма, но при этом влияет на размер таблицы и VACUUM приобретает важное значение для производительности.
Давайте пошагово пройдем тестовый пример, чтобы увидеть, как это работает на практике.
Отключение autovacuum (только для тестирования)
PostgreSQL обычно выполняет фоновый процесс, который называется autovacuum, для очистки мертвых кортежей и предотвращения раздувания таблиц.
Для реальных приложений выключение autovacuum не рекомендуется, поскольку это критически важно для работоспособности базы данных.
Но в целях тестирования он может быть выключен для конкретной таблицы для гарантии, что ничего не будет происходить автоматически в фоновом режиме.
Таблица MySQL information_schema.processlist предоставляет большой объем информации о текущем состоянии сервера MySQL. Она важна для администраторов и разработчиков баз данных, чтобы мониторить эти данные для обеспечения оптимальной производительности и диагностики потенциальных проблем. В этой статье мы познакомимся с несколькими запросами MySQL, предназначенными для извлечения полезных идей из списка процессов, и обсудим, насколько они могут помочь нам в мониторинге и оптимизации сервера MySQL.
1. Просмотр всех процессов
Чтобы получить исчерпывающий обзор всех текущих процессов на сервере MySQL, вы можете использовать следующий запрос:
Выбор правильного формата резервной копии может составлять разницу между 10-минутным восстановлением и целым днем мучений. Утилита pg_dump в PostgreSQL предоставляет множество форматов вывода, каждый из которых оптимизирован для различных сценариев - от быстрой разработки снимков до восстановления после сбоев производственных баз. Понимание этих форматов помогает построить такую стратегию восстановления, которая сбалансирует эффективность использования хранилища, скорость восстановления и операционную гибкость. В этом руководстве рассматриваются пять ключевых форматов резервных копий с указанием, когда использовать каждую из них.
У меня есть данные, пришедшие в мой SQL Server в формате JSON. Перед началом парсинга, который довольно интенсивный, необходимо проверить, присутствуют ли некоторые значения в этом JSON. Имеется ли функция, которую я могу использовать с этой целью? Давайте посмотрим, что может делать JSON_CONTAINS, новая функция в SQL Server 2025.
В одной из предыдущих статей я описывал, как работает обеспечение целостности внешних ключей в Postgres. Краткая версия такова: каждая команда INSERT или UPDATE в таблицу, ссылающуюся на другую, запускает триггер AFTER, который проверяет, существуют ли значения столбца внешнего ключа (FK) в ссылочной (PK) таблице. Эта проверка проходит через SPI (Server Programming Interface): строится запрос, он планируется, выполняется, а затем всё уничтожается — для каждой отдельной строки.
Это дорогостоящая операция. При массовой вставке (INSERT) миллиона строк в таблицу с внешним ключом вы выполняете миллион мини-запросов к индексу таблицы первичного ключа. Каждый из них открывает отношение первичного ключа, захватывает снимок (snapshot), выполняет проверку прав, делает поиск по индексу и закрывает всё. Стоимость одной строки в абсолютном выражении невелика, но она очень быстро накапливается.
Для Postgres 19 я применил два патча (соавтором обоих является Джунванг Жао), которые полностью обходят SPI для стандартного случая и выполняют пакетную (batch) проверку индекса. Вместе они ускоряют массовые вставки с внешними ключами примерно в 2.9 раза в используемом мною тесте (int первичный ключ, int внешний ключ, 1 миллион строк, таблица первичного ключа и её индекс в памяти).Что деаёт быстрый путь (fast path)
Продолжить чтение "Postgres: более быстрые проверки внешних ключей"
Каждый, кто хотя бы по колено погрузился в фотографию, знает о существовании треугольника экспозиции: диафрагма, выдержка и светочувствительность (ISO). В зависимости от того, какого художественного эффекта вы хотите добиться, вы регулируете эти три параметра, понимая, что у каждого изменения есть своя цена. Проработав несколько реальных случаев и предложив решения заказчикам, я начал думать о настройке производительности Postgres схожим образом. Существуют базовые параметры, которые можно настраивать, и у каждого выбора администратора баз данных есть свои последствия:
Распределение памяти (Memory Allocation)
Дисковый ввод-вывод (Disk I/O)
Конкурентность (Concurrency)
Каждый из этих факторов (в общих чертах) влияет на пропускную способность — то есть на то, какой объём работы ваша система успевает выполнить.
Оговорка: Я понимаю, что с академической точки зрения понятие «пропускной способности» не полностью отражает суть баланса между этими концепциями, но, пожалуйста, отнеситесь к этому снисходительно!
Давайте поговорим о том, как каждый из этих трёх аспектов взаимодействует со всей системой и как выглядят сопутствующие компромиссы.
(Эта статья написана применительно к PostgreSQL 9.3. Если вы используете более новую версию, пожалуйста, проверьте, остались ли описанные ограничения в силе.)
PostgreSQL предлагает несколько инструментов для поиска и сопоставления текстовых шаблонов. Сложность заключается в выборе подходящего инструмента для конкретной задачи.
В течение долгого времени я работал с разными компьютерными языками и кодирование бинарных данных было необходимо в первую очередь потому, что требовалось передавать данные на другой компьютер.
Функции кодирования: BASE64_ENCODE и BASE64_DECODE
В язык T-SQL были добавлены две новых функции: BASE64_ENCODE, BASE64_DECODE . Эти функции взаимно обратны, подобно функциям шифрования. Одна функция возвращает вспять действия другого, и они предназначены для совместного использования. Продолжить чтение "T-SQL в SQL Server 2025: функции кодирования"
Вы выполняете SELECT * FROM orders в одном сеансе psql и видите 50 миллионов строк. Ваш коллега в другом сеансе выполняет тот же запрос в тот же момент и видит 49 999 999. Никто из вас не ошибается, и никто не видит устаревших данных. Вы оба читаете одни и те же страницы кучи размером 8 КБ, одни и те же байты на диске.
В этом заключается обещание MVCC (многоверсионного контроля конкурентного доступа) PostgreSQL, и именно поэтому читатели никогда не блокируют писателей, а писатели никогда не блокируют читателей. Это также одна из самых неправильно понимаемых частей механизма хранения. Люди знают, что «существует несколько версий строки», и на этом останавливаются.
При работе с очень большими таблицами в PostgreSQL традиционные индексы типа B-Tree или GiST могут чрезвычайно вырасти в размерах, что занимает значительное время на их обслуживание. Для временных рядов или последовательно упорядоченных данных PostgreSQL предлагает более разумный и облегченный вариант: BRIN (Block Range Index).
Индексы BRIN группируют данные в диапазоны блоков вместо хранения отдельных записей строк, что делает их компактными, быстрыми в построении и эффективными для запросов на диапазон или упорядоченные данные.
Легко перемещайте данные из SQL Server в Oracle 26ai Free, используя это пошаговое руководство. Узнайте как установить связанный сервер, сконфигурировать FREEPDB1 и избежать типичных ошибок.
Недавно мне пришлось перенести некоторые данные из SQL Server на Oracle 26ai в редакции Free. Я решил проверить, поможет ли связанный сервер сделать эту работу, поскольку зачастую это самый простой способ…
Это позволит мне просто писать операторы INSERT SELECT, но в SQL Server, связанные серверы с Oracle, известны своей неуклюжестью и часто имеют проблемы с некоторыми типами данных, настройками времени, и т. д.
