Архитектура

Внутреннее устройство

12

Авторские права

© Postgres Professional, 2020 год.

Авторы: Егор Рогов, Павел Лузанов

Обратная связь

Отзывы, замечания и предложения направляйте по адресу:

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за

любые повреждения и убытки, включая потерю дохода, нанесенные

прямым или непрямым, специальным или случайным использованием

материалов курса. Компания Postgres Professional не предоставляет

каких-либо гарантий на материалы курса. Материалы курса

предоставляются на основе принципа «как есть» и компания Postgres

Размер страницы составляет 8 Кбайт. Это значение можно увеличить

(вплоть до 32 Кбайт), но только при сборке. И таблицы, и индексы,

и большинство других объектов, которые в PostgreSQL обозначаются

термином relation, используют одинаковую структуру страниц, чтобы

Версии строк содержит те самые данные, которые мы храним

в таблицах и других объектах БД, плюс заголовок. «Версия строки» по-

английски называется tuple; иногда мы будем говорить просто «строка».

Указатели имеют фиксированный размер (4 байта) и составляют

массив, позиция в котором определяет идентификатор строки (tuple id,

tid). Указатели ссылаются на версии строк (tuple), расположенные

в конце блока. Такая косвенная адресация удобна тем, что во-первых,

позволяет найти нужную строку, не перебирая все содержимое блока

(строки имеют разную длину), а во-вторых, позволяет перемещать

Формат данных на диске полностью совпадает с представлением

данных в оперативной памяти. Страница читается в буферный кеш

«как есть», без преобразований.

Поэтому файлы данных на одной платформе (разрядность, порядок

байтов и т. п.) оказываются несовместимыми с другими платформами.

Кроме того, многие архитектуры предусматривают выравнивание

данных по границам машинных слов. Например, на 32-битной системе

x86 целые числа (тип integer, занимает 4 байта) будут выровнены по

границе 4-байтных слов, как и числа с плавающей точкой двойной

точности (тип double precision, 8 байт). А в 64-битной системе значения

100

xmin xmax данные

100 0 42,FOO

committed

aborted

XACT

Рассмотрим, как устроены версии строк (tuples) и как выполняются

операции со строками на низком уровне. Начнем со вставки.

В нашем примере — таблица с двумя столбцами (число и текст).

При вставке строки в табличной странице (heap page) появится

указатель с номером 1, ссылающийся на первую и единственную

версию строки. Каждый такой указатель помимо ссылки содержит длину

версии строки и несколько бит, определяющих ее статус.

Версии строк кроме собственно данных имеют также заголовок,

занимающий минимум 23 байта. Помимо прочего он содержит:

- xmin и xmax — поля, определяющие видимость данной версии строки

в терминах начального и конечного номеров транзакций;

- карту неопределенных значений (в ней отмечены поля, равные NULL);

- ряд признаков, показывающих, например, статус транзакций xmin и

xmax, если он уже известен (зафиксированы или оборваны).

В нашей версии строки поле xmin заполнено номером текущей

обращать внимание на этот номер, поскольку установлен признак, что

эта транзакция оборвана.

100

xmin xmax данные

100 0 42,FOO

committed

aborted

XACT

Пусть также имеется индекс B-дерево, созданный по текстовому полю.

И даже у одного типа индекса бывают разные виды страниц. Например,

у B-дерева есть страница с метаданными и «обычные» страницы.

(так же, как и в табличной странице).

индексирования и ссылку (ctid) на соответствующую строку таблицы

(структура B-дерева разбирается в теме «Классы операторов» и

как правило он все равно будет содержать ссылки на версии строк.

В нашем примере в индексной странице также создается указатель

с номером 1, который ссылается на индексную строку, которая, в свою

очередь, ссылается на первую строку в табличной странице. Чтобы не

загромождать рисунок, указатель и строка объединены.

индекса, невозможно определить видимость этой строки, не заглянув

в табличную страницу (для оптимизации служит карта видимости).

Мы видели, что в страницах данных физически могут находиться

несколько версий одной и той же строки.

Транзакции работают со снимком данных, который определяет, какие

версии должны быть видны, а какие — нет, чтобы обеспечить

согласованную картину данных на определенный момент времени

(на момент создания снимка — показан на рисунке синим цветом).

Согласованность здесь понимается в обычном ACID-смысле: данные

должны быть корректны, что, по сути, означает, что видеть нужно

только те данные, которые были зафиксированы на момент создания

снимка. Это полностью исключает аномалию грязного чтения на любом

На уровне Repeatable Read (и Serializable) снимок создается один раз

Будет или нет данная версия строки видна в снимке, определяется

двумя полями ее заголовка — xmin и xmax, — то есть номерами

создавшей и удалившей транзакций. Такие интервалы не

пересекаются, поэтому одна строка представлена в любом снимке

Точные правила видимости довольно сложны и учитывают различные

«крайние» случаи. Чуть упрощая, можно сказать, что версия строки

видна, когда в снимке видны изменения, сделанные транзакцией xmin,

и не видны изменения, сделанные транзакцией xmax. Иными словами,

создание строки должно быть видно, а удаление (если оно было) —

нет.

В свою очередь, изменения транзакции видны в снимке, если либо это

та же самая транзакция, что создала снимок (она сама видит свои же

изменения), либо транзакция была зафиксирована до создания снимка.

На рисунке черные отрезки показывают транзакции. Нам известен

момент начала транзакции (xid = xmin или xmax из заголовка версии

строки), но момент завершения транзакции нигде не записывается. Мы

лишь можем узнать текущий статус транзакций при создании снимка.

Если транзакция завершилась фиксацией до создания снимка (имеет

статус committed в XACT), то ее изменения должны быть видны

в снимке (транзакции 1 и 3 на рисунке).

Если транзакция началась после создания снимка, то ее изменения не

должны попадать в снимок (транзакция 5).

Изменения транзакций, которые были начаты до создания снимка, но

в момент создания снимка еще не завершились, также не должны быть

транзакций активна в момент создания, необходимо заранее

Итак, снимок данных определяется несколькими параметрами:

Номер самой ранней из активных транзакций (xmin снимка) имеет

важный смысл — он определяет «горизонт событий» транзакции.

А именно, за своим горизонтом транзакция всегда видит только

актуальные версии строк.

Действительно, видеть неактуальную версию требуется только в том

случае, когда актуальная создана еще не завершившейся транзакцией,

и поэтому не видна. Но за «горизонтом» все транзакции уже

гарантированно завершились.

Существует и «горизонт событий» на уровне базы данных. Для его

определения надо взять все активные снимки и среди них найти

минимальный (самый ранний) xmin. Он и будет определять горизонт,

за которым неактуальные версии строк в этой БД уже никогда не будут

Если какая-либо транзакция удерживает снимок в течении долгого

времени, она тем самым удерживает и горизонт событий базы данных.

Более того, незавершенная транзакция удерживает горизонт самим

фактом своего существования (даже на уровне Read Committed).

Рисунок иллюстрирует такую ситуацию.

быть очищены. При этом совершенно не важно, какие данные читала

или изменяла «долгоиграющая» транзакция. Она может вообще никак

не пересекаться по данным с другими транзакциями — горизонт базы

данных один на всех.