Глава 4
Базы данных
Вэтой главе мы рассмотрим:
•иерархию объектов СУБД;
•кластербазданных,табличныепространства,базыданных,схемы,таблицыииндексы;
•отношения;
•служебные структуры отношений — TOAST, карты видимости и свободного пространства;
•рабочую нагрузку в отношении таблиц и индексов;
•избыточное последовательное сканирование таблиц;
•ошибки и нежелательные события в кластере баз данных;
•функции для определения размеров объектов;
•функции вывода содержимого служебных каталогов кластера баз данных.
Впредыдущей главе мы рассмотрели запросы как основу любой рабочей нагрузки, а также связанные с ними статистику и мониторинг активности. Другой стороной рабочей нагрузки являютсяпользовательскиеданные.Взапросахуказываютсяконкретныетаблицы,изкоторых читаются и в которые сохраняются данные. В этой главе мы рассмотрим статистику активности сточки зрения обращений к объектам СУБД и проследим события,которые происходят в контексте именно этих объектов—баз данных,таблиц и индексов.
4.1. Иерархия объектов СУБД
Одной из главных задач СУБД является надежное хранение данных и обеспечение доступа к этим данным. На уровне СУБД средствами организации и хранения данных являются таблицы и другие типы объектов, каждый со своим предназначением. Все эти средства являются логическим слоем организации данных. Однако СУБД не является вещью самой в себе и вынуждена опираться на средства операционной системы, на ее собственные абстракции и ресурсы.СточкизренияоперационнойсистемыданныеСУБДразмещаютсявфайловойсистеме и используютблочные устройства.На физическом уровне всетаблицы,индексы и многие другие абстракции СУБД—это всего лишь файлы и каталоги на диске.
Дальше мы рассмотрим, как в СУБД организовано хранение данных. Это поможет лучше понять качественный состав рабочей нагрузки (на какие объекты СУБД приходится нагрузка)
100Глава 4. Базы данных
и более осознанно подойти к созданию мониторинга рабочей нагрузки сточки зрения использованияобъектовиданных.Опытныеадминистраторы,хорошопредставляющиевнутреннюю структуру хранения,могут сразу перейти к разделу 4.2.
Кластер баз данных
Первое, что мы рассмотрим, — это концепция кластера баз данных (database cluster). Кластер представляет собой единый и неделимый набор баз данных и общий для них набор глобальных объектов. Свойство единости и неделимости означает, что весь набор существует вместе в рамках одного экземпляра СУБД (instance)—группы процессов,запущенных в пространстве операционной системы и имеющих область общей памяти. На одном сервере могут работать несколько экземпляров СУБД, если их TCP-порты не конфликтуют. Кластер баз данных не следует путать с кластером репликации. Кластер репликации обычно состоит из нескольких экземпляров СУБД, запущенных в независимых средах (отдельные физические, виртуальные серверы или контейнеры).
С точки зрения операционной системы кластер баз данных представляет собой набор каталогов и файлов. Инициализация кластера осуществляется командой initdb с указанием целевого каталога. Полученный каталог принято называть каталогом данных (data directory), он содержитв себедругие каталоги и файлы кластера.Исключением могутбытькаталогитабличных пространств и WAL-журнала, которые могут быть вынесены за пределы каталога данных и связаны с основным каталогом через символические ссылки. Таким образом, каталог данныхивсевозможныевнешниекаталоги(табличныепространстваиWAL)образуютхранилище данных кластера.
Ниже приведен пример каталога данных из тестового окружения. Каждый подкаталог играет своюзначимуюрольвфункционированиикластера.Администраторуважнознатьназначение каждого подкаталога и его роль в работе СУБД.
# ls -l /var/lib/postgresql/data/ |
|
|
|
|
|
||
total 132 |
|
|
|
|
|
|
|
-rw------- |
1 |
postgres postgres |
3 |
Jul 31 08:52 |
PG_VERSION |
||
drwx------ |
7 |
postgres postgres |
4096 |
Jul 31 08:53 |
base |
||
-rw------- |
1 |
postgres postgres |
46 |
Aug |
2 00:00 |
current_logfiles |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul 31 08:55 |
global |
||
drwx------ |
2 |
postgres postgres |
4096 |
Jul 31 08:52 |
pg_commit_ts |
||
drwx------ |
2 |
postgres postgres |
4096 |
Jul 31 08:52 |
pg_dynshmem |
||
-rw------- |
1 |
postgres postgres |
4991 |
Jul 31 08:52 |
pg_hba.conf |
||
-rw------- |
1 |
postgres postgres |
1636 |
Jul 31 08:52 |
pg_ident.conf |
||
drwx------ |
4 |
postgres postgres |
4096 |
Aug |
2 |
04:13 |
pg_logical |
drwx------ |
4 |
postgres postgres |
4096 |
Jul 31 |
08:52 |
pg_multixact |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul 31 |
08:52 |
pg_notify |
|
drwx------ |
3 |
postgres postgres |
4096 |
Jul 31 |
08:53 |
pg_replslot |
|
|
|
|
|
|
|
4.1. Иерархия объектов СУБД |
101 |
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:52 pg_serial |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:52 pg_snapshots |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:53 pg_stat |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:53 pg_stat_tmp |
|
drwx------ |
2 |
postgres postgres |
4096 |
Aug |
2 |
04:08 pg_subtrans |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:52 pg_tblspc |
|
drwx------ |
2 |
postgres postgres |
4096 |
Jul |
31 |
08:52 pg_twophase |
|
drwx------ |
3 |
postgres postgres |
4096 |
Aug |
2 |
04:13 pg_wal |
|
drwx------ |
2 |
postgres postgres |
4096 |
Aug |
2 |
01:13 pg_xact |
|
-rw------- |
1 |
postgres postgres |
88 |
Jul |
31 |
08:52 postgresql.auto.conf |
|
-rw------- |
1 |
postgres postgres |
30146 |
Jul |
31 |
08:52 postgresql.conf |
|
-rw------- |
1 |
postgres postgres |
24 |
Jul |
31 |
08:53 postmaster.opts |
|
-rw------- |
1 |
postgres postgres |
94 |
Jul |
31 |
08:53 postmaster.pid |
|
pg_wal и pg_xlog
Зачем же нужно знать внутреннюю структуру каталога данных? Хорошим примером является история подкаталога WAL-журнала. Этот каталог критически важен для функционирования СУБД. При некоторых обстоятельствах его содержимое может неконтролируемо расти и занимать все больше и больше места на диске, но удаление каталога может привести к непредсказуемымпоследствиям.Доверсии 9.6 включительно каталогжурнала WAL назывался pg_xlog,и неопытные администраторы нередкоудаляли его,считая,чтотам хранятся какие-то «обычные текстовые логи», которыми можно пожертвовать, чтобы освободить место.В итоге удаление каталога приводило к печальным последствиям1.
Вверсии10каталогWALбылпереименованвpg_walвпопыткеустранитьдвусмысленность ипредотвратитьслучайныеудаления2.Заранеезнаярольиназначениеотдельныхподкаталогов внутри основного каталога данных,можно избежать попадания в подобные истории.
Подробнее об организации физического хранения баз данных можно узнать из официальной документации3.
Табличные пространства
Следующей (внешней) частью каталога данных являются табличные пространства. С их помощью можно объединять независимые каталоги (размещенные на разных файловых системах и блочных устройствах) и использовать для нужд СУБД. После инициализации initdb
вСУБД присутствуетдва табличных пространства:
•pg_default — табличное пространство по умолчанию, где будут создаваться все базы, таблицы, индексы. Это пространство размещается внутри основного каталога кластера. При инициализации в этом пространстве создаются две служебные базы — template0
1 stackoverflow.com/questions/36900462/postgres-wont-start-after-deleting-pg-xlog-files
2 www.depesz.com/2016/10/25/waiting-for-postgresql-10-rename-pg_xlog-directory-to-pg_wal 3 postgrespro.ru/docs/postgresql/current/storage
102Глава 4. Базы данных
и template1, которые используются как шаблоны для создания новых баз (см. команду
CREATE DATABASE1);
•pg_global— служебное пространство, которое также размещается внутри основного каталогакластера.Здесьразмещаютсяобщиедлявсегокластераобъектысистемногокаталога.
Получитьсписоквсехтабличныхпространствможноспомощьюметакоманды\db+илиизтаб-
лицы pg_tablespace:
# \db+ |
|
|
|
|
|
|
|
|
|
|
List of tablespaces |
|
|
|
|
Name |
| Owner |
| Location | Access privileges |
| Options | Size |
| Description |
|||
------------ |
+---------- |
+---------- |
+------------------- |
+ |
---------+-------- |
|
+------------- |
pg_default | postgres |
| |
| |
| |
| 372 |
MB |
| |
|
pg_global |
| postgres |
| |
| |
| |
| 556 |
kB |
| |
В выводе команды интерес представляет поле Location, которое содержит путь до каталога табличного пространства. Для пространств по умолчанию это поле содержит NULL (поскольку оба находятся в основном каталоге данных). Все остальные подключаемые пространства (как правило) находятся вне основного каталога данных. Они связаны с основным каталогом посредством символических ссылок,определенных в подкаталоге pg_tblspc.
Табличные пространства могут использоваться для размещения как баз данных,так и отдельных таблиц и индексов. Отдельно стоит отметить базы данных: размещение в конкретном табличном пространстве фактически означает, что в нем размещаются объекты системного каталога этой базы, а остальное содержимое может размещаться и в других табличных пространствах.Например,вполнедопустимосуществованиебазывпространствеpg_default,вкоторойможетнаходитьсябольшаясекционированнаятаблица;приэтомсекцииииндексыэтой таблицы за последние три месяца могут находиться в пространстве, размещенном в быстром SSD-хранилище,а более старые,архивные секции и индексы—в медленном HDD-хранилище. Таким образом,база размещена в одном пространстве,а часть ее данных—в двух других пространствах.
Табличные пространства и стоимость обслуживания
Практика показывает, что использование дополнительных пространств усложняет обслуживание СУБД. Следует помнить о существовании этих пространств и учитывать их в задачах обновления, настройки физической репликации и многих других. Также добавляются дополнительные операции при миграциях данных между табличными пространствами. Лучше до последнего избегать использования пространств и серьезно оценивать плюсы и минусы от их внедрения. На практике в большинстве систем достаточно тех табличных пространств,что создаются по умолчанию.
1 postgrespro.ru/docs/postgresql/current/sql-createdatabase