--- /dev/null
+## 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`
+
+
+
+На картинке выше мы видим, что процесс `psql` получил помеченные данные из сокета `pipe` (это наше перенаправление вывода) и произвел какие-то операции с сокетом `unix` (видимо передал данные в backend).
+Посмотрим на содержание этих обменов.
+
+В `pipe` мы видим наш SQL запрос содержащий помеченные данные
+
+
+
+В `unix` сокете мы видим как тот же самый запрос с помеченными данными отправляется на запись в сокет, через который `psql` подключен к PostgreSQL
+
+
+
+
+#### Ввод `postgres`
+
+В процессе получения запроса вставки принимает участие и процесс `postgresql`
+
+
+
+На картинке выше мы видим что процесс обменивается помеченными данными через unix сокет (спойлер: он их чиатет) и кроме этого производит запись этих данных на диск (об этом ниже).
+
+Данные принимаемые процессом `postgres` полностью (что неудивительно) совпадают с данными которые отправлял процесс `psql`, с точностью до направления движения данных.
+То что `psql` писал `postgres` читает.
+
+
+
+#### Вывод помеченных данных
+
+Вывод в нашем случае работает похожим образом что и ввод.
+`psql` получает запрос из эмуляротра терминала, пренаправляет запрос бэкенду `postgres` через unix-сокет, получает обратно ответ и выводит его в консоль.
+
+##### Вывод `psql`
+
+
+
+На этом скриншоте мы видим что помеченные данные проходят через unix-сокет и устройство виртуального терминала
+
+Ниже мы видим как происходит обмен данных через unix socket.
+Видим отправленный запрос `select` и до этого более ранний `checkpoint`.
+Видим как `psql` получает через сокет помеченные данные в ответ на отправленный запрос запрос
+
+
+
+Далее мы видим как помеченные данные полученные от backend'а в человекочитаемом виде отправляются на консоль:
+
+
+
+##### Вывод `postgres`
+
+В процессе `postgres` обмен данными через unix-сокет ожидаемо происходит полностью аналогично с `pslq`, с точностью до направления:
+
+
+
+
+
+#### Запись на диск
+
+С точки зрения операций чтения/записи помеченные данные должны быть записаны на диск дважды.
+Первый раз в момент фиксации изменений, вносимая правка должна быть записана в т.н. Write Ahead Log (WAL), файл содержащий все последние изменения данных в базе, по которому в случае аварии данные базы могут быть восстановлены до актуального состояние.
+Второй раз, данные будут записаны в хранилище в котором они будут храниться на постоянной основе.
+Гарантированной записи в хранилище мы и добивались передавая базе данных команду `CHECKPOINT`.
+
+##### Запись в Write Ahead Log
+
+Запись WAL происходит в процессе выполнения транзакции.
+Поэтому запись в WAL мы уже видели в том процессе `postgres` который принимал запрос на вставку помеченных данных:
+
+
+
+Можем теперь посмотреть на то, какие данные были в него записаны, и как в этом случае выглядят наши помеченные данные:
+
+
+
+Мы явно видим помеченные данные, теперь уже во внутреннем представлении.
+Строковые константы перемешаны и местами визуально склеены.
+Так же мы видим, что в записанном образце WAL-лога внутреннее представление вставляемых данных повторено несколько раз, при этом помеченным оказывается один комплект.
+
+Излишне экземпляры в логе происходят из-за того, что мы были не аккуратны при проведении эксперимента, и производили вставку в не "девственную" базу в которой мы до этого создавали и удаляли аналогичные записи.
+Записи удаленные с точки зрения MVCC, с точки зрения хранилища данных продолжают существовать, требуют обслуживания и все эти действия отражены в логах операций чтения и записи.
+При этом следует обратить внимание, что помеченным остается только один экземпляр, только что вставленный, а следы оставшиеся от предыдущих вставок остаются не помеченными.
+
+
+##### Запись в основное хранилище.
+
+Финальная запись в основное хранилище происходит в отдельном процессе.
+Этот процесс так же как и другие сервисные процессы (воркеры) является форком основного процесса `postgres`, только он выполняет особую роль и называется в соответствии с этой ролью checkpointer.
+Поэтому в результатах нашего анализа запись в основное хранилище происходит в отдельном процессе так же именуемом `postgres`, но мы знаем, что он судя по всему является воркером checkpointer.
+
+
+
+Здесь мы видим, что запись помеченных данных происходит в файл `/base/5/16384`, это один из файлов основного хранилища.
+Если мы загляним внутрь, то увидим следующую картину:
+
+
+
+Здесь мы во-первых вдимем внутреннее представление вставленного tsvector'а, данные которого отмечены как помеченные.
+Во вторых мы наблюдаем еще один экземпляр наших данных уже не помеченный.
+Этот экземпляр остался от предыдущих экспериментов и попал в записанные данные так как страница была сброшена из памяти на диск целиком.
+Можно так же обратить внимание на то, что "старый" экземпляр находится после нового.
+Это происходит от того, что в PostgreSQL записи добавляются на страницу с конца, это штатное, ожидаемое поведение.
+
+#### Стек вызовов
+
+Далее рассмотрим как помеченные данные передаются внутри процессов.
+Процесс `psql` мы из рассмотрения исключим, с формулировкой "это тема для отдельного исследования".
+Если посмотреть на историю стека вызовов, то становиться видно, что с помеченными данными происходит много манипуляций вроде копирования и какой-то валидации.
+Однако как-то содержательно прокомментировать происходящее я не в состоянии, поэтому оставим эту часть реальности за скобками.
+Поэтому сосредоточимся на том, что происходит с помеченными данными в процессе `postgresql` при добавлении новой записи, и при выводе содержимого таблицы с помеченными данными на экран.
+
+##### Стек вызовов процесса `postgres`, ввод
+
+История стека вызовов `postgres` при вставке помеченных данных в таблицу делится на три принципиальные части.
+
+В первой части происходит общий "парсинг" запроса вставки:
+
+
+
+На этом скриншоте мы видим как помеченные данные попадают в backed вместе с запросом, проходят предварительную проверку и после чего производится синтаксический разбор самих помеченных данных.
+Сами помеченные данные при этом никак отдельно не обрабатываются, только туда-сюда копируются и принимают участие в других групповых операциях.
+
+За синтаксическим разбором следует разбор константных аргументов входящих в состав запроса.
+Это как раз то место в котором наши помеченные данные будут парситься.
+
+
+
+И действительно, в глубине стека вызовов мы наблюдаем функцию `tsvectorin`, которая занимается переводом констант типа `tsvector` из внешнего, текстового, представления в представление в котором она будет обрабатываться внутри СУБД.
+Внутри этой функции происходит какая-то достаточно развесистая обработка, тип данных-то сложный.
+
+Далее идет блок вызовов посвященный выполнению запроса:
+
+
+
+В первой подветке идет формирование записи (`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
+
projects / articles.git / commitdiff
