[articles.git] /

## PostgreSQL

PostgreSQL -- мощная современная СУБД со свободным и открытым исходным кодом.
В отличие от предыдущих двух исследуемых проектов то как устроен внутри себя PostgreSQL я знаю не по наслышке.
Поэтому у нас будет возможность сравнить результаты которые покажет Natch с фактическим знанием о том как распространяются данные через подсистемы проекта
В PostgreSQL поддерживаются различные сложные, составные, типы данных.
В рамках данного исследования предлагается взять строковое представление одного их таких типов данных и проследить как строковые константы из этого типа перейдут из текстового представление в представление внутреннее и как это внутреннее представление будет сохранено на диск.

### План эксперимента

* Соберем PostgreSQL с отладочной информацией
* В качестве исследуемого типа данных, выберем тип данных `[tsvector](https://www.postgresql.org/docs/current/datatype-textsearch.html)`, так как он с одной стороны содержит в себе набор отдельных строковых констант, за которыми будет удобно наблюдать в режиме помеченных данных, а с другой стороны тип данных сам по себе не является излишне сложным.
* Сохраним строковое представление константы типа `tsvector` в отдельный файл. Данные из этого файла в нашем эксперименте Natch будет отслеживать как "помеченные"
* Напишем несложный скрипт заворачивающий строку из вышеупомянутого файла в SQL-запрос осуществляющий вставку константы типа `tsvector` в ранее созданную таблицу
* Под контролем Natch, запустим вышеупомянутый скрипт, осуществим вставку, после чего дадим команду `CHECKPOINT`, чтобы принудить postgres сбросить все закешированные страницы хранилища на диск.

### Сборка и установка


Перед началом работы убеждаемся что системный PostgreSQL остановлен:

```bash
$ sudo service postgresql stop
```


#### Установка зависимостей

Как и в пошлый раз установим зависимости используя зависимости сборки пакета `postgres` из debain и добавим несколько пакетов которые необходимы при сборке dev-ветки.


```bash
$ sudo apt-get build-dep postgresql
$ sudo apt-get install libicu-dev bison flex libreadline-dev zlib1g-dev
```

#### Получение исходников

```bash
$ git clone  https://git.postgresql.org/git/postgresql.git -b REL_17_STABLE ~/postgres/REL_17_STABLE
```


#### Сборка и установка
```bash
cd ~/postgres/REL_17_STABLE
$ ./configure --enable-debug --prefix=$HOME/postgres/.install/REL_17_STABLE
$ make -j8
$ make install
```

#### Создание управляющих скриптов

Скрипты для запуска и подключения к базе данных размещаем в директории `~/postgres/.install/REL_17_STABLE-scripts`

`base._sh` - скрипт определяющий глобальные переменные:

```bash
export MY_PG_BIN=$HOME/postgres/.install/REL_17_STABLE/bin
export MY_PG_DATA=$HOME/postgres/.install/REL_17_STABLE-data
```

`initdb.sh` - скрипт для инициализации кластера БД:

```bash
#!/bin/sh

source ./base._sh

rm -r $MY_PG_DATA

$MY_PG_BIN/initdb -D $MY_PG_DATA

```

`restart.sh` - скрипт для запуска/перезапуска нашего экземпляра PostgreSQL

```bash
#!/bin/bash

pkill postgres
sleep 2

source ./base._sh

$MY_PG_BIN/pg_ctl start -D $MY_PG_DATA -l $MY_PG_DATA/log
```

`psql.sh` - скрипт для подключения к БД через коммандно-строчный интерфейс psql

```bash
#!/bin/bash

source ./base._sh

$MY_PG_BIN/psql postgres
```

`psql_con.sh` - скрипт перенаправляющий поток стандартного вывода на вход нашего psql

```
#!/bin/bash

source ./base._sh

cat - | $MY_PG_BIN/psql postgres
```

#### Инициализация кластера БД и создание тестовой таблицы

При помощи скрипта `initdb.sh` создаем кластер БД:

```bash
$ cd ~/postgres/.install/REL_17_STABLE-scripts
$ ./initdb.sh
```

Запускаем СУБД

```bash
$ ./restart.sh
```

далее подключаемся к базе данных с помощь скрипта `psql.sh`

```bash
$ ./psql.sh
```

создаем таблицу для вставки помеченных данных

```sql
create table test (t tsvector);
```

выходим из psql

```sql
exit
```

### Подготовка помеченных данных

В качестве основы для наших помеченных данных, возьмем основной [пример из документации](https://www.postgresql.org/docs/current/datatype-textsearch.html) расширив его дополнительными синтаксическими конструкциями описанными ниже по тексту документации.
В результате получим файл вида

```
a:1A fat:2B,4C cat:5D sat:4 on:5 a:6 mat:7 and:8 ate:9 a:10 fat:11 rat:12
```

#### Тестирование вставки тестовых данных

Перед записью трассы следует убедиться, что мы умеем правильно вставлять в таблицу данные из файла IN.
Вставку предполагается делать командой

```
$ cd ~/postgres/.install/REL_17_STABLE-scripts
$ echo INSERT INTO test VALUES \( \'`cat IN`\'::tsvector\)\; CHECKPOINT | ./psql_con.sh

```

Как вы можете видеть в этой команде на стандартный вывод печатается SQL-запрос вставки, в который добавляется содержимое файла с помеченными данными.
За запросом вставки следует команда `CHECKPOINT`, которая инициирует принудительный сброс на диск кэша страниц хранилища PostgreSQL.
Полученная строка направляется в `psql`.
Таким образом помеченными оказываются только данные из файла `IN`, но не сам текст запроса.

Убедитесь, что команда отрабатывает без ошибок и данные действительно попадают в таблицу `test`

#### Очистка окружения перед проведением эксперимента

Перед проведением эксперимента таблицу `test` рекомендуется очистить от старых данных, чтобы они не смущали нас своим видом.

```sql
DELETE FROM test;
```

### Проведение исследования

#### Создание проекта natch

При создании проекта natch, уже на host-машине следуем штатной инструкции.
В качестве источника помеченных данных указываем файл `IN` о котором мы говорили выше.
В моем случае `/home/nataraj/postgres/.install/REL_17_STABLE-scripts/IN`.
В качестве директории содержащий дополнительные модули с отладочной информацией указать место в которое были установлены бинарные файлы нашей сборки PostgreSQL: `/home/nataraj/postgres/.install/REL_17_STABLE/bin` и `/home/nataraj/postgres/.install/REL_17_STABLE/lib/`

#### Запись трассы

- Запускаем штатным образом запись трассы используя команду `natch record`;
  - В появившемся окне виртуальной машины логинимся в виртуалку;
  - Останавливаем системный PostgreSQL: `sudo service postgresql stop`;
  - Переходим в каталог с нашей скриптовой обвязкой: `cd ~/postgres/.install/REL_17_STABLE-scripts`;
  - Запускаем нашу сборку PostgreSQL: `./restart.sh`;
- В консоли Natch делаем первый снапшот (см. штатный tutorial);
  - Запускаем команду вставки помеченных данных в базу: `echo INSERT INTO test VALUES \( \'`cat IN`\'::tsvector\) | ./psql_con.sh`
  - Запускаем утилиту `psql` в командно-строчном режиме: `./psql.sh`;
    - Даем в ней команду `CHECKPOINT;` для гарантированного сброса страничного кеша на диск;
    - Получаем содержимое таблицы `test` выполнив запрос: `SELECT * FROM test;`;
- В консоли Natch делаем второй снапшот;
- Завершаем работу Natch.

#### Генерация отчета

Далее следуя штатной инструкции при помощи команды `natch replay` снимаем трассу между первым и вторым снепшотом и загружаем ее в snatch.

### Анализ результатов

#### Ввод/вывод помеченных данных

Помеченные данные должны через стандартный ввод попасть в `psql`, после чего попасть в бэкенд PostgreSQL через unix-сокет, через который `psql` по умолчанию подключается к базе.
После вставки мы не перезагружали сервер, данные все еще будут закешированы, и следовательно останутся помеченными.
Поэтому запросив данные из таблицы мы по факту должны получить значение из страничного кеша, которое все еще сохранит пометку.

Посмотрим как это выглядит на практике

##### Ввод `psql`

![...](3. PostgreSQL.imgs/in_psql_resources.png)

На картинке выше мы видим, что процесс `psql` получил помеченные данные из сокета `pipe` (это наше перенаправление вывода) и произвел какие-то операции с сокетом `unix` (видимо передал данные в backend).
Посмотрим на содержание этих обменов.

В `pipe` мы видим наш SQL запрос содержащий помеченные данные

![...](3. PostgreSQL.imgs/in_psql_pipe-read.png)

В `unix` сокете мы видим как тот же самый запрос с помеченными данными отправляется на запись в сокет, через который `psql` подключен к PostgreSQL 

![...](3. PostgreSQL.imgs/in_psql_unix-write.png)


#### Ввод `postgres`

В процессе получения запроса вставки принимает участие и процесс `postgresql`

![...](3. PostgreSQL.imgs/in_postgres_resoruces.png)

На картинке выше мы видим что процесс обменивается помеченными данными через unix сокет (спойлер: он их чиатет) и кроме этого производит запись этих данных на диск (об этом ниже).

Данные принимаемые процессом `postgres` полностью (что неудивительно) совпадают с данными которые отправлял процесс `psql`, с точностью до направления движения данных.
То что `psql` писал `postgres` читает.

![...](3. PostgreSQL.imgs/in_postgres_unix-read.png)

#### Вывод помеченных данных

Вывод в нашем случае работает похожим образом что и ввод.
`psql` получает запрос из эмуляротра терминала, пренаправляет запрос бэкенду `postgres` через unix-сокет, получает обратно ответ и выводит его в консоль.

##### Вывод `psql`

![...](3. PostgreSQL.imgs/out_psql_resources.png)

На этом скриншоте мы видим что помеченные данные проходят через unix-сокет и устройство виртуального терминала

Ниже мы видим как происходит обмен данных через unix socket.
Видим отправленный запрос `select` и до этого более ранний `checkpoint`.
Видим как `psql` получает через сокет помеченные данные в ответ на отправленный запрос запрос

![...](3. PostgreSQL.imgs/out_psql_unix-read.png)

Далее мы видим как помеченные данные полученные от backend'а в человекочитаемом виде отправляются на консоль:

![...](3. PostgreSQL.imgs/out_psql_tty1-write.png)

##### Вывод `postgres`

В процессе `postgres` обмен данными через unix-сокет ожидаемо происходит полностью аналогично с `pslq`, с точностью до направления:

![...](3. PostgreSQL.imgs/out_postgres_resources.png)

![...](3. PostgreSQL.imgs/out_postgres_unix-write.png)

#### Запись на диск

С точки зрения операций чтения/записи помеченные данные должны быть записаны на диск дважды.
Первый раз в момент фиксации изменений, вносимая правка должна быть записана в т.н. Write Ahead Log (WAL), файл содержащий все последние изменения данных в базе, по которому в случае аварии данные базы могут быть восстановлены до актуального состояние.
Второй раз, данные будут записаны в хранилище в котором они будут храниться на постоянной основе.
Гарантированной записи в хранилище мы и добивались передавая базе данных команду `CHECKPOINT`.

##### Запись в Write Ahead Log

Запись WAL  происходит в процессе выполнения транзакции.
Поэтому запись в WAL мы уже видели в том процессе `postgres` который принимал запрос на вставку помеченных данных:

![...](3. PostgreSQL.imgs/in_postgres_resoruces.png)

Можем теперь посмотреть на то, какие данные были в него записаны, и как в этом случае выглядят наши помеченные данные:

![...](3. PostgreSQL.imgs/disk_wal.png)

Мы явно видим помеченные данные, теперь уже во внутреннем представлении.
Строковые константы перемешаны и местами визуально склеены.
Так же мы видим, что в записанном образце WAL-лога внутреннее представление вставляемых данных повторено несколько раз, при этом помеченным оказывается один комплект.

Излишне экземпляры в логе происходят из-за того, что мы были не аккуратны при проведении эксперимента, и производили вставку в не "девственную" базу в которой мы до этого создавали и удаляли аналогичные записи.
Записи удаленные с точки зрения MVCC, с точки зрения хранилища данных продолжают существовать, требуют обслуживания и все эти действия отражены в логах операций чтения и записи.
При этом следует обратить внимание, что помеченным остается только один экземпляр, только что вставленный, а следы оставшиеся от предыдущих вставок остаются не помеченными.


##### Запись в основное хранилище.

Финальная запись в основное хранилище происходит в отдельном процессе.
Этот процесс так же как и другие сервисные процессы (воркеры) является форком основного процесса `postgres`, только он выполняет особую роль и называется в соответствии с этой ролью checkpointer.
Поэтому в результатах нашего анализа запись в основное хранилище происходит в отдельном процессе так же именуемом `postgres`, но мы знаем, что он судя по всему является воркером checkpointer.

![...](3. PostgreSQL.imgs/disk_checkpointer_resources.png)

Здесь мы видим, что запись помеченных данных происходит в файл `/base/5/16384`, это один из файлов основного хранилища.
Если мы загляним внутрь, то увидим следующую картину:

![...](3. PostgreSQL.imgs/disk_checkpointer_file.png)

Здесь мы во-первых вдимем внутреннее представление вставленного tsvector'а, данные которого отмечены как помеченные.
Во вторых мы наблюдаем еще один экземпляр наших данных уже не помеченный.
Этот экземпляр остался от предыдущих экспериментов и попал в записанные данные так как страница была сброшена из памяти на диск целиком.
Можно так же обратить внимание на то, что "старый" экземпляр находится после нового.
Это происходит от того, что в PostgreSQL записи добавляются на страницу с конца, это штатное, ожидаемое поведение.

#### Стек вызовов

Далее рассмотрим как помеченные данные передаются внутри процессов.
Процесс `psql` мы из рассмотрения исключим, с формулировкой "это тема для отдельного исследования".
Если посмотреть на историю стека вызовов, то становиться видно, что с помеченными данными происходит много манипуляций вроде копирования и какой-то валидации.
Однако как-то содержательно прокомментировать происходящее я не в состоянии, поэтому оставим эту часть реальности за скобками.
Поэтому сосредоточимся на том, что происходит с помеченными данными в процессе `postgresql` при добавлении новой записи, и при выводе содержимого таблицы с помеченными данными на экран.

##### Стек вызовов процесса `postgres`, ввод

История стека вызовов `postgres` при вставке помеченных данных в таблицу делится на три принципиальные части.

В первой части происходит общий "парсинг" запроса вставки:

![...](3. PostgreSQL.imgs/callstack_in_1.png)

На этом скриншоте мы видим как помеченные данные попадают в backed вместе с запросом, проходят предварительную проверку и после чего производится синтаксический разбор самих помеченных данных.
Сами помеченные данные при этом никак отдельно не обрабатываются, только туда-сюда копируются и принимают участие в других групповых операциях.

За синтаксическим разбором следует разбор константных аргументов входящих в состав запроса.
Это как раз то место в котором наши помеченные данные будут парситься.

![...](3. PostgreSQL.imgs/callstack_in_2.png)

И действительно, в глубине стека вызовов мы наблюдаем функцию `tsvectorin`, которая занимается переводом констант типа `tsvector` из внешнего, текстового, представления в представление в котором она будет обрабатываться внутри СУБД.
Внутри этой функции происходит какая-то достаточно развесистая обработка, тип данных-то сложный.

Далее идет блок вызовов посвященный выполнению запроса:

![...](3. PostgreSQL.imgs/callstack_in_3.png)

В первой подветке идет формирование записи (`heap_fill_tuple`).
Помеченные данные судя по стеку вызовов копируются куда-то в формируемую запись.

Во второй подветке производится вставка сформированной записи в таблицу (`heapam_tuple_insert`).
Тут тоже помеченные данные просто копируются из одного места в другое

И в третьей, последней подветке происходит запись произведенных изменений в WAL-лог (`XLogInsert`).
Помеченные данные принимают участие в вычислении контрольной суммы, и копируются вместе со всей остальной дельтой произошедшей во время транзакции.

### Итог

Не смотря на то, что эксперимент был проведен не очень чисто, и наши данные оказались замусорены артефактами от предыдущих запусков, нам удалось отследить маршрут движения помеченных данных данных, и наблюдаемая картина совпала с нашими теоретическими представлениями.

В качестве развития темы читателю предлагается во-первых повторить предложенный эксперимент полностью пересоздав кластер базы данных перед проведением эксперимента, и убедиться что мы в этом случае артефакты предыдущих вставок в отчете natch не наблюдаются.

Так же читателю предлагается повторить эксперимент с перезагрузкой базы данных между вставкой помеченных данных и их получением.
Предположительно, при прохождении через дисковое хранилище данные должны утратить пометку.
Однако в случае, если они останутся в дисковом кеше уровня ОС, пометка может и сохраниться.
Интересно будет выяснить каково будет фактическое поведение, и как поставить эксперимент, чтобы дисковый кеш тоже оказался бы гарантированно сброшен. 


**FIXME**
sudo su
echo "deb-src http://deb.debian.org/debian trixie main" >>/etc/apt/sources.list
apt-get update