- •Предисловие
- •Об этой книге
- •Глава 1. Обзор статистики
- •Внутреннее устройство PostgreSQL
- •Установка соединений и работа сеансов
- •Запросы как базовая единица рабочей нагрузки
- •Планирование и выполнение запросов
- •Ввод-вывод при выполнении запросов
- •Журнал сообщений СУБД
- •Репликация изменений
- •Архивирование журнала предзаписи
- •Фоновая синхронизация данных
- •Автоочистка
- •Интерфейс статистики
- •Статистика как отправная точка инструментов мониторинга
- •Особенности статистики
- •Тестовое окружение
- •Глава 2. Статистика активности
- •Ключ к пониманию происходящего в СУБД
- •Взаимодействие клиента и сервера
- •Источники информации об активности
- •Представление pg_stat_activity
- •Представление pg_locks
- •Особенности pg_stat_activity и pg_locks
- •Представление pg_stat_database
- •Подключенные клиенты
- •Отслеживание клиентских сеансов
- •Транзакционная активность
- •Статусы завершения сеансов
- •Состояния сеансов
- •Отслеживание состояний
- •Ожидания и блокировки
- •Отслеживание состояний с учетом ожиданий
- •Взаимоблокировки
- •Бездействующие транзакции
- •Время выполнения запросов и транзакций
- •Отслеживание времени ожидания блокировок
- •Использование pg_locks.waitstart
- •Использование pg_stat_activity.state_change
- •Дерево блокировок
- •Глава 3. Выполнение запросов и функций
- •Зачем нужен мониторинг запросов
- •Расширение pg_stat_statements
- •Метаданные запроса
- •Планирование запроса
- •Исполнение запроса
- •Сквозная идентификация с queryid
- •Построение отчетов на основе pg_stat_statements
- •Представление pg_stat_statements_info
- •Выполнение процедур и функций
- •Глава 4. Базы данных
- •Иерархия объектов СУБД
- •Кластер баз данных
- •Табличные пространства
- •Базы данных
- •Схемы
- •Таблицы и индексы
- •TOAST
- •События в кластере баз данных
- •Рабочая нагрузка в отношении таблиц и индексов
- •Ошибки и нежелательные события
- •Функции для работы с объектами СУБД
- •Определение размеров объектов СУБД
- •Размещение объектов в файловой системе
- •Глава 5. Область общей памяти и ввод-вывод
- •Анализ общей памяти
- •Представление pg_buffercache
- •Представление pg_shmem_allocations
- •Анализ памяти клиентских процессов
- •Оценка использования SLRU-кешей
- •Ввод-вывод в контексте объектов СУБД
- •Базы данных
- •Ввод-вывод в контексте выполнения запросов
- •Временные файлы
- •Уровень баз данных
- •Ввод-вывод при выполнении запросов
- •Отслеживание в журнале сообщений
- •Отслеживание активных временных файлов
- •Ввод-вывод фоновых процессов
- •Глава 6. Журнал упреждающей записи
- •Отслеживание активности в журнале
- •Представление pg_stat_wal
- •Представление pg_stat_statements
- •Архивирование журнала
- •Представление pg_stat_archiver
- •Очередь архивирования
- •Глава 7. Репликация
- •Обзор репликации
- •Инструменты отслеживания репликации
- •Представление pg_stat_replication
- •Представление pg_stat_wal_receiver
- •Cлоты репликации и pg_replication_slots
- •Публикации и подписки
- •Конфликты восстановления
- •Глава 8. Очистка
- •Введение в очистку
- •Особенности очистки на практике
- •Когда выполняется автоочистка?
- •Статистика выполнения очистки
- •Счетчик транзакций и предотвращение ошибок, связанных с его зацикливанием
- •Раздувание таблиц и индексов
- •Отслеживание активных процессов очистки
- •Представление pg_stat_activity
- •Представление pg_stat_progress_vacuum
- •Глава 9. Ход выполнения операций
- •Представление pg_stat_progress_analyze
- •Представление pg_stat_progress_basebackup
- •Представление pg_stat_progress_cluster
- •Представление pg_stat_progress_create_index
- •Представление pg_stat_progress_copy
- •Предметный указатель
4.1. Иерархия объектов СУБД |
103 |
Базы данных
Базы данных являются своего рода контейнерами для данных и обеспечивают их изоляцию. Таблицыииндексыоднойбазынедоступнывдругихбазах(дляобходаэтогоограниченияможно использоватьтакие средства,как postgres_fdwи dblink).Отдельные базы используютсядля логического разделения данных внутри одного кластера — данные нескольких не взаимосвязанных между собой приложений можно разделить и хранить в отдельных базах, но в рамках одного кластера баз данных.
Посмотреть список баз можно с помощью метакоманды \l (или в таблице pg_database):
# \l |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
List of databases |
|
|
|
|
Name |
| |
Owner |
| Encoding | Collate |
| Ctype |
| ICU Locale | Locale Provider | Access privileges |
|
|||
----------- |
+ |
---------- |
+---------- |
+------------ |
+------------ |
+------------ |
+----------------- |
+----------------------- |
|
pgbench |
| |
pgbench |
| UTF8 |
| en_US.utf8 |
| en_US.utf8 |
| |
| libc |
| |
|
postgres |
| |
postgres | UTF8 |
| en_US.utf8 |
| en_US.utf8 |
| |
| libc |
| |
|
|
template0 | |
postgres | UTF8 |
| en_US.utf8 |
| en_US.utf8 |
| |
| libc |
| =c/postgres |
+ |
||
|
| |
|
| |
| |
| |
| |
| |
| postgres=CTc/postgres |
|
template1 | |
postgres | UTF8 |
| en_US.utf8 |
| en_US.utf8 |
| |
| libc |
| =c/postgres |
+ |
||
|
| |
|
| |
| |
| |
| |
| |
| postgres=CTc/postgres |
|
При инициализации кластера создаютсятри базы данных.Две базы—template0 и template1— используются самой СУБД в качестве шаблонов при создании новых баз, а третья база — postgres — является обычной базой, пригодной для создания в ней таблиц. Как правило, БД postgres не используется для прикладных бизнес-задач, администраторы обычно устанавливаютв нее вспомогательные скрипты и инструменты.Для размещения пользовательских данных рекомендуется создавать отдельные базы и давать им имена,которые ясно указывали бы на назначение БД или на суть хранимых там данных.
Все базы данных внутри основного каталога размещены в подкаталоге base. Каждая база размещена в каталоге,имя которого соответствует идентификатору в pg_database.oid.
Схемы
Внутри отдельной базы можно дополнительно разделить данные по схемам (schema). Схемы, посути,являютсяпространствамиимен(namespace)ипозволяютзадействоватьдополнительный уровень изоляции и хранения объектов,но не предусматриваютвложенности.Например, с помощью схем можно организовать хранение таблиц согласно разным предметным областям, версионирование функций и представлений. Массу интересных вариантов использования схем можно найти в презентации Б.Момджяна,посвященной микросервисам1.
Любая база создается со схемой public,которая является схемой по умолчаниюдля всех создаваемых таблиц и индексов.Часто на практике достаточно одной этой схемы.
1 momjian.us/main/writings/pgsql/microservices.pdf
104 |
|
Глава 4. |
Базы данных |
|
|
|
|
|
Посмотреть список схем можно метакомандой \dn+ (или в таблице pg_namespace): |
||||
# \dn+ |
|
|
|
|
|
|
|
|
|
|
List of schemas |
|
|
Name |
| |
Owner |
| |
Access privileges |
| |
Description |
-------- |
+ |
------------------- |
+ |
---------------------------------------- |
+ |
------------------------ |
public |
| pg_database_owner | |
pg_database_owner=UC/pg_database_owner+| standard public schema |
||||
|
| |
|
| |
=U/pg_database_owner |
| |
|
Схемы являются внутренней абстракцией СУБД для логической группировки объектов. Они не имеют ассоциированных с ними файлов или каталогов в файловой системе.
Таблицы и индексы
Таблицы являются основными, можно даже сказать, главными объектами для размещения пользовательских данных, представленных в виде строк. Индексы являются дополнительной к таблице структурой и позволяют ускорить поиск отдельных строк таблицы.
Получить список таблиц можно с помощью метакоманды \dt+ или представления pg_tables:
# \dt+ |
|
|
|
|
|
|
|
|
|
|
List |
of relations |
|
|
|
Schema | |
Name |
| Type |
| Owner |
| Persistence | Access method | Size |
| Description |
||
--------+ |
------------------ |
+------- |
+--------- |
+------------- |
+--------------- |
+--------- |
+------------- |
public | pgbench_accounts |
| table |
| pgbench |
| permanent |
| heap |
| 256 MB |
| |
|
public | pgbench_branches |
| table |
| pgbench |
| permanent |
| heap |
| 40 kB |
| |
|
public | pgbench_history |
| table |
| pgbench |
| permanent |
| heap |
| 0 bytes |
| |
|
public | pgbench_tellers |
| table |
| pgbench |
| permanent |
| heap |
| 48 kB |
| |
|
В выводе представлены только пользовательские таблицы. Для просмотра всех таблиц, включая системные,следует указать модификатор S: команда примет вид \dtS+.Для индексов есть аналогичная метакоманда \di и представление pg_indexes (на основе таблицы pg_index):
# \di+ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
List of relations |
|
|
|
|
|
Schema | |
Name |
| Type |
| Owner |
| |
Table |
| Persistence | Access method | Size |
| Description |
|||
--------+ |
----------------------- |
+------- |
+--------- |
+ |
------------------ |
+------------- |
+--------------- |
+------- |
|
+------------- |
public | pgbench_accounts_pkey | index |
| pgbench | pgbench_accounts |
| permanent |
| btree |
| 43 |
MB |
| |
||||
public | pgbench_branches_pkey |
| index |
| pgbench | pgbench_branches |
| permanent |
| btree |
| 16 |
kB |
| |
|||
public | pgbench_tellers_pkey |
| index |
| pgbench | pgbench_tellers |
| permanent |
| btree |
| 16 |
kB |
| |
|||
Отдельноможноотметитьтаблицуpg_class,котораясодержитсписоквсехобъектоввтекущей базе и часто используется как вспомогательная при получении статистики по объектам базы. Далее в некоторых запросах мы будем обращаться к этой таблице.
4.1. Иерархия объектов СУБД |
105 |
Отношения и кортежи
Отношение (relation) — это обобщающий термин для любых объектов в базе данных, которые имеют имя и список атрибутов.Таблицы и индексы,внешниетаблицы,представления (обычныеиматериализованные),последовательности(sequence),составныетипы—всеэто можно назвать отношениями. Также в PostgreSQL существует термин класс — это устаревший синоним отношения,который остался со времен увлечения объектной ориентированностью. В самых ранних версиях PostgreSQL существовала таблица pg_relation, которую быстро переименовали в pg_class,а вот префикс rel у атрибутов так и остался.
В более общем виде отношение — это множество кортежей (tuple); например, результат запросатакже является отношением.Кортеж представляет собой упорядоченный набор атрибутов. Порядок атрибутов задается при определении таблицы (или другого отношения), которая будет содержать кортежи. В этом случае кортеж часто называют строкой таблицы.Он также может определяться структурой результирующего множества; такие кортежи иногда называют записями. Часто этот термин принимает смысл «версия строки», так как относится скорее к физическому представлению данных внутри страницы, чем к логическому понятию строки.
И таблицы,и индексы (и некоторые другиетипы отношений) представлены в виде отдельных файлов в каталогах БД. Если таблица содержит большое количество строк, файл таблицы (или индекса) автоматически сегментируется на файлы по одному гигабайту. Каждый такой файлсегмент нумеруется по возрастанию.
Каждая таблица или индекс представлены несколькими файлами, так называемыми слоями
(fork):
•Основной файл таблицы (main fork) содержит пользовательские данные в виде строк.
•Карта видимости (visibility map) предназначенадля отслеживания страниц,строки в которых видны всем активнымтранзакциям.Карты видимости существуюттолькодлятаблиц. Файлы карт видимости имеют суффикс _vm. Карты видимости обновляются при очистке
иобычно занимают немного места. Более подробное описание можно найти в документации1.
•Карта свободного пространства (free space map) предназначена для отслеживания свободного места в таблице (или индексе) и тех страниц, что доступны для вставки новых строк. Так же как и карты видимости, карты свободного пространства обновляются при очистке
изанимают немного места. Файлы этих карт имеют суффикс _fsm. Более подробное описание можно найти в документации2.
•Файл инициализации (initialization fork) используется только для нежурналируемых таблиц (unlogged table) и индексов, изменения в которых не фиксируются в WAL-журнале. Такие таблицы не восстанавливаются после сбоя и пересоздаются путем копирования
1 postgrespro.ru/docs/postgresql/current/storage-vm
2 postgrespro.ru/docs/postgresql/current/storage-fsm
