Концепция архитектуры PostgreSQL

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

В данной статье описываются основные концепции, лежащие в основе исходного кода СУБД, и описанные в руководстве разработчика.

Немного истории

 

PostgreSQL «вырос» из некоммерческой СУБД Postgres, разработанной, как и многие открытые проекты, в Калифорнийском университете в Беркли. К разработке Postgres имел непосредственное отношение Майкл Стоунбрейкер, руководитель более раннего проекта Ingres, на тот момент уже приобретённого компанией Computer Associates.

Ingres, разрабатываемый с 1977 по 1985 год, был «тренировочным» проектом создания классической реляционной системы управления базами данных. Само название «Postgres» расшифровывалось как «Post Ingres», соответственно, при создании Postgres использовались многие уже ранее сделанные наработки.

Стоунбрейкер и его студенты разрабатывали новую СУБД Postgres в течение восьми лет, с 1986 по 1994 год. За этот период в синтаксис были введены процедуры, правила, пользовательские типы и многие другие компоненты. Работа не прошла даром — в 1995 году разработка снова разделилась: Стоунбрейкер использовал полученный опыт в создании коммерческой СУБД Illustra, продвигаемой его собственной одноимённой компанией (приобретённой впоследствии компанией Informix), а его студенты разработали новую версию Postgres — Postgres95, в которой язык запросов POSTQUEL — наследие Ingres — был заменен на SQL.

В этот момент разработка Postgres95 была выведена за пределы университета и передана команде энтузиастов. С этого момента СУБД получила имя, под которым она известна и развивается в текущий момент — PostgreSQL.

Преимущества PostgreSQL:

• Наиболее развитая СУБД с открыты кодом;
• Надежность и устойчивость на очень больших нагрузках;
• Кросс-платформенность: работает в широком диапазоне диалектов UNIX (Linux, FreeBSD, Solaris и т.д.), а также на платформе Microsoft Windows;
• Высокий уровень соответствия стандартам;
• Существует множество интерфейсов и библиотек взаимодействия для других языков программирования: Java (JDBC), ODBC, Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и Qt;
• Расширяемость;
• Быстродействие;
• Наследование;
• поддержка баз данных практически неограниченного размера

Архитектура системы

Архитектура Postgres разбита на 3 основные подсистемы:

• Front End или клиентская часть системы, включающая в себя собственно клиентское приложение и библиотеку LIBPQ, реализующую интерфейс связи с сервером. Библиотека LIBPQ отвечает за установление соединения с сервером и передачу SQL-запросов.
• Серверная часть, включающая в себя серверные процессы и контролирующий процесс-демон Postmaster, отвечающий за взаимодействие с клиентами. Демон postmaster постоянно запущен в фоновом режиме на сервере. Он авторизует и принимает запросы от клиентов и осуществляет обмен данными между клиентом и сервером. При получении запроса соединения от клиента Postmaster создаёт соответственный фоновый серверный процесс postgres, при этом используется связь один-к-одному. После того, как серверный процесс создан, клиент и сервер взаимодействуют напрямую.
• Back End, включающий хранилище данных и средства управления хранилищем. Несколько серверных процессов могут одновременно иметь доступ к информации из хранилища.

Серверная часть

После установления соединения, серверный процесс получает SQL-запросы в текстовом виде и трансформирует эти запросы в поток выходных данных.

Обработка запроса происходит в следующем порядке:

• Парсер принимает запрос в виде текста в формате ASCII и проверяет его синтаксис, распознавая идентификаторы и ключевые слова. В результате работы парсера формируется дерево разбора, либо в случае неверного синтаксиса генерируется ошибка.
• Далее за дело принимается служба контроля трафика. На этом этапе запрос идентифицируется как простой или сложный. Простые запросы перенаправляются непосредственно в модуль исполнения, сложные передаются через компоновщик планировщику/оптимизатору.
• Компановщик принимает дерево разбора запроса от парсера и преобразует его в альтернативную вспомогательную форму.
• Сложный SQL-запрос может быть выполнен несколькими разными способами. Планировщик определяет наиболее оптимальный путь и передаёт управление модулю исполнения.
• Модуль исполнения выполняет запрос оптимальным образом согласно дереву разбора, предоставленному планировщиком, и возвращает вывод в текстовом виде клиенту.

Принципы организации хранения данных

Архитектура Postgres разбита на 3 основные подсистемы:

Взаимодействие с хранилищем данных осуществляется через службы доступа и загрузочный модуль.

• Хранилище предоставляет унифицированный доступ доступ к серверным данным. С помощью сложной системы буферизации в хранилище возможен множественный доступ к одним и тем же таблицам параллельными запросами и процессами. Таким образом, хранилище является посредником между службами Postgres и физическим диском, а также обеспечивает семафоры и блокировки файлов. На сервере Postreg может существовать только одно хранилище.
• Образец базы данных создаётся с помощью загрузочного модуля при первом запуске Postgres. На этом этапе невозможно обращение к базе данных через обычные SQL-запросы.
• Затем вся работа происходит через службу доступа к базе данных. Служба доступа отвечает за индексирование, сканирование, поиск, компиляцию и возвращение запрошенных данных.

Управление хранилищем включает в себя несколько независимых, иногда необязательных, подсистем:

• Модуль сбора статистики накапливает информацию о доступе к таблицам и индексам, вызовах серверных функций и командах, выполненных модулем исполнения. По запросу накопленная статистика передаётся другим процессам системы. В свою очередь, процессы системы периодически передают актуальные данные коллектору.
• Сборщик мусора Auto-Vacuum — набор процессов для автоматического освобождения неиспользуемой памяти в таблицах. Для принятия решения об очистке неиспользуемых данных сборщик мусора опирается на данные, полученные от модуля сбора статистики.
• Фоновый процесс записи логов сохраняет логи произведённых операций и информацию для резервного восстановления системы в случае поломки. Все изменения, сделанные после последнего сохранения состояния системы записываются в специальных лог-файлах.

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

Заключение

PostgreSQL имеет множество возможностей, не затронутых в данной обзорной статье. В публичном доступе доступно большое количество документации и статей для дальнейшего изучения.