Hacking PostgreSQL. Физическое представление данных

Editor's Notes

1. Прежде, чем говорить о физическом хранении данных в базе, надо сначала понять, какие же собственно объекты могут в ней находиться. Обратимся к нашему любимому каталогу. В этой лекции самым полезным и интересным будет pg_class. В этом каталоге описываются таблицы и практически всё, что имеет колонки или каким-то образом подобно таблице. У каждого relation есть уникальный идентификатор OID.
2. OID или object indentificator, вообще говоря, есть не только у отношений, но у любого объекта PostgreSQL. Объектами являются сами базы данных, отношения, функции, типы данных и так далее. Каждому элементу enum в постгресе тоже присваивается отдельный OID. Глубоко внутри OID это всего лишь unsigned int, но небольшой набор правил превращает его в фундаментальный тип данных постгреса. Итак OID со значением 0 обозначает невалидный OID. Первые 10 тысяч значений зарезервированы для назначения вручну предопределенных OID. Используются они, например, в файлах src/include/catalog Значения от 10 тысяч до 16383 (совершенно необъяснимое магическое число) зарезервированы для назначения в процессе работы initdb. Значения OID начиная с 16384 назначаются генератором OID в процессе обычной работы сервера. Unsigned int содержит много значений, но всё-таки не бесконечно. Поэтому иногда происходит wraparound генератора OID, при этом значения от 0 до FirstNormalObjectId пропускаются.
3. При создания нового объекта (кроме объектов отношений), нужно сначала сгенерировать для него OID. Функция GetNewOid генерирует OID, уникальный в пределах заданного отношения. Например для создания новой базы нужно вызвать GetNewOid от таблицы каталога pg_database. Уникальность обеспечивается тем, что на всех соответствующих таблицах каталога есть уникальный индекс. При создании relation, OID, если нужно, назначается функцией GetNewRelFileNode. Про то, что такое relfilenode чуть позже. Обе эти функции вызывают внутренний генератор GetNewObjectId, который получает значение nextOid из глобального для всего кластера счетчика OID. Зачем я вам всё это рассказываю? С практической стороны глобальные OID — одно из препятствий, которое нужно преодолеть, для реализации бэкапа отдельной базы.
4. Если вы создаете новую запись в системном каталоге вручную, например добавляете функцию в pg_proc, нужно выбрать для неё OID и вписать его в строку самостоятельно. Скрипт unused_oids помогает найти свободные для использования OID. Если для некоторых целей вам понадобился целый набор OID, лучше выбрать последовательные значения. Скрипт duplicate_oids можно использовать для проверки уникальности OID. Например, после merge.
5. Некоторые таблицы каталога содержат системную скрытую колонку OID, чтобы вывести её, надо явно задать её в select. Select * не выдаст вам oid. Для удобства есть различные alias для OID. Например regclass. Помимо regclass есть ещё regproc, regtype и другие типы идентификаторов, которые соответствуют разным таблицам каталога.
6. Если вы создаете новую запись в системном каталоге вручную, например добавляете функцию в pg_proc, нужно выбрать для неё OID и вписать его в строку самостоятельно. Скрипт unused_oids помогает найти свободные для использования OID. Если для некоторых целей вам понадобился целый набор OID, лучше выбрать последовательные значения. Скрипт duplicate_oids можно использовать для проверки уникальности OID. Например, после merge.
7. Postgres работает поверх файловой системы. Данные, относящиеся к одному инстансу postgres лежат в директории data. Её расположение можно задать переменной окружения $PGDATA. Эта директория содержит несколько управляющих файлов и поддиректорий, каждая из которых имеет особое назначение. Сегодня мы будем говорить не про все из них, а только про те, которые содержат непосредственно данные пользователя базы или управляют их физической структурой. Файлы журналов, поддержку транзакционности, статистику и много других интересных разделов отложим до следующих занятий, хотя физически все эти данные также по умолчанию лежат в директории PGDATA. Кстати, недавно найденный баг pg_basebackup в Debian. Конфиги там лежат отдельно, и большинство утилит постгреса умеют это понимать, а вот pg_basebackup что-то делает неправильно. Опять же, когда он создается с шаблонным файлом postgesql.conf, тот ложится в pgdata (как на других системах), а не к остальным конфигам.
8. В директории global лежат данные, общие для всех баз данного инстанса. А именно: pg_control — позиция последнего checkpoint, необходимая для WAL. При запуске восстановления сервер в первую очередь проверяет файл pg_global. Если кому-то интересно, что конкретно там лежит заглядывайте в файл src/include/catalog/pg_control.h pg_filenode.map Для большинства таблиц физическое расположение файла определяется записью в pg_class.relfilenode. Очевидно, что для самого pg_class это не работает. На самом деле не только для pg_class, но и для некоторых других базовых и глобальных relation. Маппингом для них занимается pg_filenode.map. src/backend/utils/cache/relmapper.c pg_internal.init — файл, который используется для ускорения загрузки бэкенда.
9. Давайте узнаем, что за куча файлов лежит в pg_global. Выберем из pg_class всё, что относится к tablespace global. Я не буду подробно говорить про все эти файлы. Это таблицы каталога и индексы на них. Отмечу только, что relfilenode у них равен нулю. Это значит, что маппингом этих файлов занимается тот самый pg_filenode.map, про который мы узнали на предыдущем слайде.
10. Просто продолжение таблички с предыдущего слайда.
11. Табличные пространства позволяют администратору управлять дисковым пространством для инсталляции PostgreSQL. Это полезно минимум по двум причинам. Во-первых, это нехватка места в разделе, на котором был инициализирован кластер и невозможность его расширения. Табличное пространство можно создать в другом разделе и использовать его до тех пор, пока не появится возможность переконфигурирования системы. Even though located outside the main PostgreSQL data directory, tablespaces are an integral part of the database cluster and cannot be treated as an autonomous collection of data files. They are dependent on metadata contained in the main data directory, and therefore cannot be attached to a different database cluster or backed up individually. Similarly, if you lose a tablespace (file deletion, disk failure, etc), the database cluster might become unreadable or unable to start. Placing a tablespace on a temporary file system like a RAM disk risks the reliability of the entire cluster.
12. Давайте наконец вернемся к нашим базам. Они лежат в поддиректории base. Посмотрим её содержимое. Здорово. Но непонятно. Здесь нам на помощь приходит скрипт oid2name. ... Стало значительно лучше. Три стандартных базы, которые есть в любом постгресе и ещё одна пользовательская.
13. Можно развлекаться с oid2name. Можно воспользоваться встроенными функциями для маппинга имени relation в файл.
14. Здорово. Но непонятно. Здесь нам на помощь приходит скрипт oid2name. Рассказать про его работу. Стало значительно лучше. Три стандартных базы, которые есть в любом постгресе и ещё одна пользовательская.
15. Здорово. Но непонятно. Здесь нам на помощь приходит скрипт oid2name. Рассказать про его работу. Стало значительно лучше. Три стандартных базы, которые есть в любом постгресе и ещё одна пользовательская.
16. Здорово. Но непонятно. Здесь нам на помощь приходит скрипт oid2name. Рассказать про его работу. Стало значительно лучше. Три стандартных базы, которые есть в любом постгресе и ещё одна пользовательская.
17. При выполнении некоторых операций, таких как truncate, cluster, relfilenode меняется, в то время как OID остается прежним.
18. В коде есть структура relfilenode, которая содержит всё, что нужно для физического доступа к relation. Здесь мы рассматриваем relation как нечто атомарное, хотя как мы увидим дальше и он разделен на много разных файлов.
19. В Berkley Postgres было реализовано несколько различных storage managers. Они не входили во внешние релизы Postgres. Теперь осталась только одна реализация storage manager - (magnetic disk). Название, впрочем, уже не отражает суть. До сих пор есть возможность написать другой storage manager. Честно говоря, я не очень активно слежу за рассылками, но не слышала, чтобы кто-то этим интересовался. В berkley каждый relation имел тэг, который связывал его с smgr. Сейчас этого нет. И если когда-нибудь будет реализован новый smgr, наверное лучше связывать их с tablespace. smgr.c — переключение между различными smgr, управление кэшем SmgrRelation md.c — реализация слоя между API smgr и API файловой системы.
20. * each data file (heap or index) is divided into postgres disk blocks * (which may be thought of as the unit of i/o -- a postgres buffer * contains exactly one disk block). the blocks are numbered * sequentially, 0 to 0xFFFFFFFE. * * InvalidBlockNumber is the same thing as P_NEW in buf.h. * * the access methods, the buffer manager and the storage manager are * more or less the only pieces of code that should be accessing disk * blocks directly. * this is a storage type for BlockNumber. in other words, this type * is used for on-disk structures (e.g., in HeapTupleData) whereas * BlockNumber is the type on which calculations are performed (e.g., * in access method code). * * there doesn't appear to be any reason to have separate types except * for the fact that BlockIds can be SHORTALIGN'd (and therefore any * structures that contains them, such as ItemPointerData, can also be * SHORTALIGN'd). this is an important consideration for reducing the * space requirements of the line pointer (ItemIdData) array on each * page and the header of each heap or index tuple, so it doesn't seem * wise to change this without good reason.
21. Есть 4 типа форков.
22. Код для создания и удаления физического хранилища для relation. Создается только главный форк, остальные создаются только в момент, когда они нужны. Эта функция транзакционна. Если транзакция отменена, storage будет удален. В то же время, drop table удаляет файлы не сразу, а только после коммита транзакции Since most code wants to access the main fork, a shortcut version of ReadBuffer that accesses MAIN_FORKNUM is provided in the buffer manager for convenience.
23. FSM обновлена в версии 8.4. FSM — бинарное дерево. Для каждой страницы хранится количество свободного места с гранулярностью 1/256. То есть freespace деленное на BLCKSZ/256. Плюсы: Чтобы узнать, что страницы с таким количеством места нет — достаточно проверить root.
24. Если кто-то хочет быстрой славы) Можете поправить выравнивание этого комментария)