Каждый, кто хотя бы по колено погрузился в фотографию, знает о существовании треугольника экспозиции: диафрагма, выдержка и светочувствительность (ISO). В зависимости от того, какого художественного эффекта вы хотите добиться, вы регулируете эти три параметра, понимая, что у каждого изменения есть своя цена. Проработав несколько реальных случаев и предложив решения заказчикам, я начал думать о настройке производительности Postgres схожим образом. Существуют базовые параметры, которые можно настраивать, и у каждого выбора администратора баз данных есть свои последствия:
Распределение памяти (Memory Allocation)
Дисковый ввод-вывод (Disk I/O)
Конкурентность (Concurrency)
Каждый из этих факторов (в общих чертах) влияет на пропускную способность — то есть на то, какой объём работы ваша система успевает выполнить.
Оговорка: Я понимаю, что с академической точки зрения понятие «пропускной способности» не полностью отражает суть баланса между этими концепциями, но, пожалуйста, отнеситесь к этому снисходительно!
Давайте поговорим о том, как каждый из этих трёх аспектов взаимодействует со всей системой и как выглядят сопутствующие компромиссы.
(Эта статья написана применительно к PostgreSQL 9.3. Если вы используете более новую версию, пожалуйста, проверьте, остались ли описанные ограничения в силе.)
PostgreSQL предлагает несколько инструментов для поиска и сопоставления текстовых шаблонов. Сложность заключается в выборе подходящего инструмента для конкретной задачи.
В течение долгого времени я работал с разными компьютерными языками и кодирование бинарных данных было необходимо в первую очередь потому, что требовалось передавать данные на другой компьютер.
Функции кодирования: BASE64_ENCODE и BASE64_DECODE
В язык T-SQL были добавлены две новых функции: BASE64_ENCODE, BASE64_DECODE . Эти функции взаимно обратны, подобно функциям шифрования. Одна функция возвращает вспять действия другого, и они предназначены для совместного использования. Continue reading "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, известны своей неуклюжестью и часто имеют проблемы с некоторыми типами данных, настройками времени, и т. д.
При работе со схемами реляционных баз данных вы можете предполагать, что удаление столбца физически удаляет его из табличного хранилища. В PostgreSQL это не всегда так.
Начиная с PostgreSQL 11, операция ALTER TABLE ... DROP COLUMN стала выполняться быстрее, поскольку PostgreSQL больше не переписывает всю таблицу сразу. Напротив, он:
Помечает столбец как удаленный (невидимый и недоступный).
Временно оставляет его данные на диске.
Освобождает хранилище, только когда таблица переписывается (VACUUM FULL, CLUSTER или pg_repack).
Такой подход позволяет избежать долгого выполнения переписывания таблицы и делает изменения схемы менее деструктивными для больших таблиц.
Иногда миграция оказывается более сложной, чем ожидалось. На первый взгляд определение функции STR в SQL Server является простым: она возвращает символьное представление числовых данных, выровненные по правому краю с заданной длиной и точностью до десятичных знаков. Однако при попытке конвертации вы обнаруживаете огромное число пограничных случаев, большинство из которых плохо документированы.
Одним из самых полезных инструментов отладки в современном PostgreSQL является система событий ожиданий (wait events). Когда запрос замедляется или база данных становится ограниченной по процессору, естественно возникает вопрос: «Чего на самом деле ожидают сеансы?» Postgres предоставляет эту информацию через представление pg_stat_activity с помощью двух столбцов:
wait_event_type — тип события ожидания
wait_event — само событие ожидания
Эти поля показывают, на чём именно заблокирован фоновый процесс в данный момент. Среди различных типов ожидания одна категория часто вызывает путаницу:
LWLock
Если вы когда-либо видели панели мониторинга, полные ожиданий LWLock, вы не одиноки в своих сомнениях о том, что они означают и являются ли они проблемой.
Несколько дней назад Шон Томас (Shaun Thomas) опубликовал статью в блоге pgEdge под названием «Контрольные точки, лавинная запись и вы». К сожалению, на многих корпоративных блогах больше нет возможности комментировать. Я оставил несколько комментариев в LinkedIn, но в целом позвольте мне сказать, что эта статья — отличное чтение, и я всегда рад, когда кто-то погружается в важную и обойдённую вниманием тему, даёт хорошее техническое описание и включает реальные результаты тестов для иллюстрации деталей.
У меня сегодня нет воспроизводимых реальных результатов тестов. Но у меня есть хорошая история и немного реальных данных.
Даже сейчас, в 2025 году, при наличии мощных инструментов баз данных и облачных платформ разработчики все еще допускают элементарные ошибки при проектировании схемы. Они вызывают проблемы производительности, несогласованности данных и другие технологические проблемы.
В этой статье рассматриваются наиболее общие ошибки проектирования баз данных, способы их избежать и то, как графические инструменты типа Dbschema могут помочь создать лучший проект с самого начала:
Отсутствующие внешние ключи.
Отсутствующие или неверно спроектированные индексы.
Использование JSON и JSONB в реляционных базах данных.
Игнорирование нормализации (или её чрезмерное применение).
Каждая база данных должна примириться с двумя неприятными истинами: память быстра, но энергозависима, а диск медленен, но долговечен. Postgres справляется с этим противоречием с помощью журнала предзаписи (Write-Ahead Log, WAL), который регистрирует каждое изменение до того, как оно произойдёт. Но WAL не может расти бесконечно. В какой-то момент Postgres должен сбросить все накопившиеся грязные страницы на диск и объявить чистую начальную точку. Этот процесс называется контрольной точкой (checkpoint), и когда он идёт не по плану, пропускная способность может упасть до нуля.
