PostgreSQL. День 5

1.

День 5

2.

Системная архитектура PostgreSQL
• Архитектура
• MVCC
• WAL
• Физическая организация БД

3.

Архитектура
Клиент – сервер
• Клиент
• Подключение
• Запросы
• Управления транзакциями
• Сервер
• Аутентификация
• Выполнение запросов
• Поддержка транзакций

4.

Выполнение запросов
Фаза
Что использует
Синтаксический разбор (парсинг)
Проверка синтаксиса команды по правилам языка
SQL
Семантический разбор (объекты БД)
Системный каталог – есть ли объекты в БД
Трансформация
Системные и пользовательские правила (rule) –
переписывают запрос
Оптимизатор (планировщик) запроса
План выполнения запроса, использует статистику
Выполнение запроса
Данные передаются клиенту

5.

Подготовка операторов - PREPARE
• Simple протокол
• Extended протокол

6.

PREPARE
PREPARE создаёт подготовленный оператор.
Когда выполняется PREPARE, указанный оператор разбирается, анализируется и
переписывается.
При последующем выполнении команды EXECUTE подготовленный оператор планируется и
исполняется.
Подготовленные операторы могут принимать параметры — значения, которые подставляются
в оператор, когда он собственно выполняется. При создании подготовленного оператора к
этим параметрам можно обращаться по порядковому номеру, используя запись $1, $2 и т. д.
Подготовленные операторы существуют только в рамках текущего сеанса работы с БД. Когда
сеанс завершается, система забывает подготовленный оператор, так что его надо будет
создать снова, чтобы использовать дальше.
Это также означает, что один подготовленный оператор не может использоваться
одновременно несколькими клиентами базы данных; но каждый клиент может создать
собственный подготовленный оператор и использовать его.
Освободить подготовленный оператор можно вручную, выполнив команду DEALLOCATE.

7.

Общий или специализированный план
Подготовленный оператор может выполняться с использованием либо общего плана, либо специализированного.
Общий план не меняется при последующих выполнениях, тогда как специализированный план строится для определённого
выполнения с учётом значений параметров, переданных при данном вызове.
По умолчанию (то есть когда plan_cache_mode имеет значение auto), сервер автоматически выбирает, использовать ли для
подготовленного оператора с параметрами общий или специализированный план.
это происходит по следующему принципу — первые пять выполнений производятся со специализированными планами и
вычисляется средняя стоимость этих планов. Затем строится общий план и его примерная стоимость сравнивается со средней
стоимостью специализированных. При последующих выполнениях общий план будет использоваться, если его стоимость, по
сравнению со стоимостью специализированных, не настолько велика, чтобы оправдать повторное планирование.
Эту логику можно переопределить, чтобы выбирались только общие или только специализированные планы, установив для
параметра plan_cache_mode значение force_generic_plan или force_custom_plan, соответственно.
Узнать, какой план выполнения выбирает PostgreSQL для подготовленного оператора, можно, воспользовавшись командой
EXPLAIN.
EXPLAIN EXECUTE имя(значения_параметров);
Если применяется общий план, он будет содержать символы параметров $n, тогда как в специализированном плане будут
подставлены фактические значения параметров.

8.

Simple
* exec_simple_query
* ㄴ pg_parse_query
ㄴ raw_parser
Parse (syntactic)
* ㄴ pg_analyze_and_rewrite
ㄴ parse_analyze
Parse (semantic)
* ㄴ pg_rewrite_query
ㄴ QueryRewrite
Rewriter
* ㄴ pg_plan_queries
* ㄴ pg_plan_query
ㄴ planner
Planner
* ㄴ PortalRun
* ㄴ PortalRunSelect
ㄴ ExecutorRun
Executor

9.

Extended
...steps omitted for brevity...
* ㄴ PortalRun
* ㄴ PortalRunMulti
*
ㄴ PortalRunUtility
ㄴ pgss_ProcessUtility
*
ㄴ standard_ProcessUtility
ㄴ PrepareQuery
ㄴ CreateCachedPlan
Initialize memory
ㄴ parse_analyze_varparams Parse (semantic)
ㄴ QueryRewriter
Rewriter
ㄴ CompleteCachedPlan
Finish the plan
ㄴ StorePreparedStatement Store in hashtab

10.

Процессы и память
Postmaster
Клиент 1
Фон
процесс 1
Фон
процесс 2
Бэкэнд 1
(локальная память)
Общая память
Клиент 2
Бэкэнд2
Фон
процессы…

11.

Память и процессы

12.

Кэш и работа с диском
Общая память
Кэш ОС
WAL
БД1
БД2

13.

Память и диск

14.

MVCC - многоверсионность
• Некоторое время хранится нескольких версий одной и той же строки
• версии различаются временем действия
• время определяется номером транзакции (номера выдаются по
возрастанию)
• пишущая транзакция работает со своей версией, а читающая видит
свою версию строки
• Версия отмечается двумя отметками, определяющими «время»
действия данной версии
• При вставке, она помечается номером транзакции, выполнившей
команду INSERT. При удалении — версия помечается номером
транзакции, выполнившей DELETE (но физически не удаляется).
UPDATE это DELETE + INSERT

15.

Снимок данных
PostgreSQL использует изоляцию на основе снимков данных.
• Транзакция должна видеть только одну из имеющихся версий каждой
строки (или ни одной).
• Для этого транзакция использует снимк данных на определенный
момент времени. В снимке видны самые последние версии
зафиксированных данных, а еще незавершенные операции не видны.
• Снимок — это не физическая копия данных, а несколько чисел:
• - номер последней завершенной транзакции на момент создания
снимка (он определяет тот самый момент времени);
• - список активных транзакций на этот момент.
• Список нужен для того, чтобы исключить из снимка те транзакции,
которые начались до создания снимка, но еще не были завершены.

16.

Vacuum
• Старые версии строк хранятся вместе с актуальными и
размер таблиц и индексов постепенно увеличивается
• Процесс очистки (vacuum)
• удаляет неактуальные версии строк (которые не видны ни в одном
снимке данных)
• работает параллельно с другими процессами
• удаленные версии отставляют в файлах данных пустоты, которые
используются для новых версий строк
• Полная очистка
• Полный ребилд файлов данных, они становятся компактнее без
пустот
• Таблица заблокирована на время работы полной очистки

17.

Autovacuum
• Очистка обычно работает автоматически и настраивается
администратором
• Она опирается на активность изменения данных в
таблицах, а не просто очищает все таблицы по расписанию.
• Автоочистка это фоновый процесс autovacuum launcher,
запускающий рабочие процессы autovacuum worker в
различных базах данных.
• Все это конфигурируется админом сервера

18.

Буферный кэш

19.

Буферный кеш
• Буферный кеш состоит из массива буферов, которые содержат
страницы данных и дополнительную информацию
• Размер страницы составляет 8 Кбайт (его можно изменить
только при сборке PostgreSQL)
• Любая работа со страницами данных проходит через буферный
кеш
• Если какой-либо процесс собирается работать со страницей, он
в начале ищет ее в кеше
• Если там страницы нет, процесс обращается к ОС с запросом
прочитать эту страницу и отправляет ее в буферный кеш (ОС
может прочитать страницу с диска, а может обнаружить ее в
своем кеше)

20.

Вытеснение
• при чтении очередной страницы место в буферном кеше
может закончиться. Тогда применяется вытеснение страниц
• Алгоритм вытеснения выбирает в кеше страницу, которая
использовалась реже других, и заменяет ее на новую
• Если выбранная страница изменена, то ее надо записать и
на диск, чтобы не потерять изменения (грязный буфер)
• Этот алгоритм вытеснения называется LRU — Least
Recently Used
• Конфигурирование размеров кеша и мониторинг их
использования это задача администратора

21.

WAL – журнал транзакций кластера
• при сбое теряются данные из оперативной памяти, не записанные на диск
• Журнал фиксирует транзакции и позволяет повторно выполнить потерянные
при сбое операции
• запись всегда попадает на диск раньше, чем измененные данные из буфера
– это гарантирует восстановление транзакции при сбое (при условии что
выживает сам журнал WAL при сбое)
• Журнал защищает
• страницы таблиц, индексов и других объектов
• Системный статус транзакций (xact)
• Журнал не защищает
• временные и нежурналируемые таблицы
• Управление и настройка журнала полностью задача администратора
• Разработчику достаточно знать, что такой журнал транзакций в системе
существует и писать код по правилам управления транзакциями

22.

Кластер и физика БД
• Кластер баз данных это набор баз данных управляемы PostgreSQL
сервером
• Не путать термин с кластером в технологиях отказоустойчивости!
• База данных – набор объектов

23.

Кластер

24.

Физическая структура кластера

25.

Табличные пространства
• Дополнительные папки вне базового каталога кластера
• Позволяют более гибко настраивать размещение баз данных с
учетом особенностей дисков

26.

Табличные пространства

27.

Системные папки сервера версии 13
PGDATA - /var/lib/postgresql/13/main
Каталог установки сервера - /usr/lib/postgresql/13
Лог сервера - /var/log/postgresql/
Конфиг файл /etc/postgresql/13/main/postrgresql.conf

28.

Psql – полезные команды
psql -d database -U user –W
\c dbname username -- подключение к БД пользователем
\conninfo -- проверка текущего подключения
\l --список БД
\dt -- список таблиц в БД
\d table_name --детали по таблице
\dn --схемы БД
\df --функции БД
\dv --представления БД
\du – юзеры БД

29.

Psql
\g -- запуск предыдущей команды
\s -- история команд
\s filename -- сохранить историю в файл
\i filename -- запустить файл скрипта
\? -- помощь
\timing --переключатель отображения времени выполнения команд
\e --переключение в редактор с последующим исполнением
\a -- переключатель выравненивая результата по колонкам
\t — переключатель отображения строки заголовка и итоговой строки
\gx -- вывод по записям
\q -- выход