Устройство и принцип работы Postgresql
Общие сведения
При старте сервера postgresql, первым стартует процесс postmaster, который пораждает все остальные процессы ( вызов fork в linux )
Если один из дочерних процессов аварийно завершается, postmaster может восстановить данный процесс или перезапустить ( на тот случай если аварийный процесс повредил общие данные )
Работу сервера обеспечивают фоновые служебные процессы. Postmaster выделяет общую память, чтобы процессы могли обмениваться информацией между собой
Кроме общей памяти каждый процесс имеет свою личную локальную память
Postmaster слушает входящие соединения, при появлении клиента создает обслуживающий процесс ( backend ), далее клиент общается со своим процессом
В локальной памяти обслуживающего процесс выделяется место из оперативной памяти под запросы и их планы, состояния курсоров, кеш системного каталога, место для сортировки данных
При одновременной работе с одним объектом необходимо, чтобы один процесс не поменял какие либо данные в то время как объект занят другим процессом. Для этого используются кратковременные блокировки
Postgresql использует механизм многоверсионности на основе снимков данных, когда каждый процесс видит собственную картину данных
Блокируются только те процессы которые пытаются изменить данные уже измененные, но не зафиксированные другими процессами
Если клиентов слишком много или соединения устанавливаются и разъединяются слишком часто, есть смысл использовать менеджер пула ( PgBouncer ). Такой менеджер удерживает несколько соединений с сервером баз данных и использует одно из свободных для обслуживания запросов клиента. Таким образом кол-во соединений остается постоянным независимо от того сколько клиентов обращаются к менеджеру пула.
Нужно понимать, что при таком режиме работы несколько клиентов разделяют один процесс ( backend ), который в своей локальной памяти хранит определенное состояние.
Данные базы хранятся на дисках в обычных файлах. Логический файлы разделены на страницы по 8 Кб. Размер по умолчанию можно изменять, но только при сборке, собранный кластер может работать только со страницами одного размера
Каждая страница имеет свою разметку, заголовок и другие полезные данные
При обращении к данным на дисках, операционной системой выделяется кэш из оперативной памяти для недавно используемых страниц
Измененные данные не сразу записываются на диск, а через определенное время
Кроме буфера операционной системы в postgresql выделена общая память для всех процессов. Таким образом, если в общей памяти postgresql не найдена определенная страница, есть вероятность, что страница будет найдена в буфере операционной системы, чтобы избежать обращения к диску
При сбое ( выключение питания ) содержимое оперативной памяти пропадает вместе с данными postgresql, поэтому в процессе работы postgresql постоянно записывает журнал, который позволит повторно выполнить не завершенные операции
Клиент и сервер
чтобы начать общение с сервером, клиент передат стартовое сообщение. в данном сообщении содержатся имя пользователя и базы данных, версия протокола и др.
через файл pg_hba.conf сервер проверяет возможность подключения клиента. затем сервер может отправить соответствующее сообщение с запросом аутентификации
примеры ответа сервера:
negotiateprotocolversion - сервер не поддерживает младшую версию протокола, запрошенную клиентом, но поддерживает более раннюю версию протокола, указывается поддерживаемая версия протокола
readyforquery - готов к выполнению запросов, передаётся всегда, и при успешном завершении обработки, и при ошибке
errorresponse - ошибочный ответ, запуск не удался, соединения закрывается
noticeresponse - предупреждающее сообщение
при выполнении запроса клиент отправляет сообщение query в котором содержится текст команды. в ответ сервер передает запрашиваемые данные и завершает выполнение сообщением readyforquery
cообщение query содержит несколько sql-операторов (разделённых точкой с запятой), эти операторы выполняются в одной транзакции. в результате ошибки, откатываются все команды в запросе, если только в запросе не используются begin; и commit;
подробнее об этом здесь: https://postgrespro.ru/docs/postgresql/13/protocol-flow#id-1.10.5.7.4
раздел протокола «вызов функций» позволяет клиенту запросить непосредственный вызов любой функции, существующей в системном каталоге pg_proc. при этом клиент должен иметь право на выполнение этой функции.
цикл вызова функции начинает клиент, передавая серверу сообщение functioncall
при штатном или нештатном завершении сеанса любая открытая транзакция откатывается, а не фиксируется. однако следует заметить, что при отключении клиента в процессе обработки запроса, отличного от select, обслуживающий процесс вероятнее всего завершит запрос, прежде чем заметит отключение. если запрос выполняется не в блоке транзакции (вне последовательности begin ... commit), его результаты могут быть зафиксированы до того, как будет обнаружено отключение.
подробнее здесь: https://postgrespro.ru/docs/postgresql/13/protocol-flow#protocol-flow-pipelining
Выполнение запроса
Выполнение запроса — довольно сложная задача. Запрос передается от клиента серверу в виду текста. Текст надо разобрать — выполнить синтаксический разбор (складываются ли буквы в слова, а словав команды) и семантический разбор (есть ли в базе данных таблицыи другие объекты, на которые запрос ссылается по имени). Для этого требуется информация о том, что вообще содержится в базе данных. Такая мета-информация называется системным каталогом и хранится в самой же базе данных в специальных таблицах.Запрос может переписываться (трансформироваться) — например, вместо имени представления подставляется текст запроса. Можно придумать и свои трансформации, для чего есть механизм правил.SQL — декларативный язык: запрос на нем говорит о том, какие данные надо получить, но не говорит, как это сделать. Поэтому запрос (уже разобранный и представленный в виде дерева), передается планировщику, который разрабатывает план выполнения. Например, планировщик решает, надо или не надо использовать индексы. Чтобы качественно спланировать работу, планировщику нужна информацияо размере таблиц, о распределении данных — статистика.Далее запрос выполняется в соответствии с планом и результат возвращается клиенту — целиком и полностью.Это удобный и простой способ для небольших выборок, однако при большом объеме данных он может оказаться проблематичным.
Каждый запрос проходит перечисленные ранее шаги: разбор, переписывание, планирование и выполнение. Но если один и тот же запрос (с точностью до параметров) выполняется много раз, нет смысла каждый раз разбирать его заново
Поэтому кроме обычного выполнения запросов протокол PostgreSQL предусматривает расширенный режим, который позволяет более детально управлять выполнением операторов
качестве одной из возможностей расширенный режим позволяет подготовить запрос — заранее выполнить разбор и переписываниеи запомнить дерево разбора
При выполнении запроса выполняется привязка конкретных значений параметров. Если необходимо, выполняется планирование(в некоторых случаях PostgreSQL запоминает план запроса и не выполняет повторно этот шаг). Затем запрос выполняется.Еще одно преимущество подготовленных операторов — невозможность внедрения SQL-кода
Источники
Здесь пока нет комментариев