r

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

 Хао Чен, Heechul Лим и Цзинь Сяо

Абстрактный

PostgreSQL является открытым исходным кодом, объектно-ориентированная система реляционной базы данных. До актуальный,

тысячи приложений баз данных был разработан с использованием PostgreSQL и это широкий

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

Этот документ пытается набросать концептуальную архитектуру PostgreSQL на основе

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

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

бетон архитектура в результате. Мы надеемся, что такая конкретная архитектура может служить

как эталонной архитектуры PostgreSQL для разработчиков PostgreSQL.

1. Введение

PostgreSQL является открытым исходным кодом, объектно-ориентированная система реляционной базы данных. Это был первый

разработана в 1977 году, под названием-Энгра ". В конце 1990-х, Postgres принят SQL

стандартные и взял себе имя,-PostgreSQL ". До актуальный, тысячи базе данных

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

проверка ее концептуальной архитектуры, через систематического анализа. Это попытки документов

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

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

Процесс проверки должны быть проведены на более позднем этапе, обеспечивая конкретную архитектуру

результат. Мы надеемся, что такая конкретная архитектура может служить PostgreSQL

Эталонная архитектура для разработчиков PostgreSQL.

В документе впервые вводит общую архитектуру PostgreSQL как классический клиента-

серверная архитектура. Каждый подсистема: сервер, клиент, и менеджер хранения рассматриваются в

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

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

выгодно и невыгодно из PostgreSQL и спекулировать на его evolvability.

PostgreSQL использует смесь архитектурных стилей. На верхнем уровне, клиент и сервер

взаимодействует в классической модели клиент-сервер, в то время как структура доступа к данным строго

слоистых. На сервере слоя, обработка запросов структурирована в виде трубопровода, в то время

доступ к базе данных по серверных подсистем структурирован как доски объявлений. Взаимодействие

между клиентом и сервером в основном запрос / ответ приводом и каждый клиент

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

поделился система управления данными.

2. Общая Архитектура

Рисунок 1 PostgreSQL Концепция системы Архитектура

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

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

Описания подсистемы

1) LIBPQ отвечает за обработку связь с клиентскими процессами:

установления соединения с почтового отделения; получения поток сервера Postgre для

операционная сессия. Это перенаправляет запросы операции пользователя на заднем конце.

Запрос операция направляется по мере является основе.

2) на стороне сервера состоит из двух подсистем: почтмейстер и Postgre

сервер. Начальник почтового отделения отвечает за принятие входящий запрос соединения

от клиента, выполняя аутентификацию и управление доступом по запросу клиента, и

установления клиенту Postgre обмене данными между серверами. Сервер ручки Postgre

все запросы и команды из клиента. PostgreSQL является-процесс "модель для каждого пользователя,

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

Процесс. Поскольку элементы управления Postmaster поступающие все запросы от клиентов и

вызывает новые Postgres без подключения к сети, одной из следствий этого

архитектура, что почтмейстер и Postgres всегда работать на то же самое

машина (то есть сервер базы данных), в то время как приложение (клиент) переднего плана может работать

в любом месте. Из-за этого, масштабируемость PostgreSQL ограничено и

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

3) Storage Manager отвечает за управление общем хранения и ресурса

управления в заднем конце, в том числе совместного управления буферной, управление файлами,

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

Управления параллелизмом

Несколько потоков из PostgreSQL может быть выполнена одновременно имеют доступ к общей информации

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

и поток сервиса, который выполняет запись данных в качестве писателя. В PostgreSQL читатели

не блокируют писателей и писателей не блокируют читателей. Писатель только блоки писателем, если

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

решения (на основе SQL стандарта ISO): читать совершено сериализуемым. В случае

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

В случае сериализуемым, писатель прерывается если значение данных был изменен с ней

начал свою сделку.

3. Подсистемы сервера

Хозяин сервер PostgreSQL в значительной степени состоит из двух частей: PostMaster и Postgres.

Когда клиент (передний конец) посылает запрос на доступ к базе на сервере, почтмейстер

сервера порождает новый процесс сервера под названием Postgres, который непосредственно общается

с клиентом. Таким образом, почтмейстер всегда работает, ожидая запросы

клиент, в то время как Postgres, что является процесс, запускает и останавливает по просьбе клиентов.

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

фоновых. Там нет разбора сделано в передний конец. Затем сервер анализирует запрос,

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

Клиент в течение установленного соединения.

Запрос / Команда Процессор

Рисунок 2 Запрос / Команда Архитектура процессора

2 показана концептуальная архитектура сервера PostgreSQL структурирована в виде

трубопроводов. Он показывает общий контроль и потока данных в пределах фоновых с момента

фоновых получает запрос от времени он посылает результаты. Существуют шесть основных подсистем

на сервере:

1) Парсер сначала проверяет запрос, переданный прикладной программы для действительны

Синтаксис. Если синтаксис является правильным, дерево разбора строится и сдают; в противном случае

возвращается ошибка. Затем дерево разбора преобразуется во внутреннюю формуле, используемой

по серверную базу данных.

2) гаишник идентифицирует запрос как подсобное запроса или более сложного запроса.

Сложные запросы в PostgreSQL являются выбирать, вставлять, обновлять и удалять. Эти

Запросы направляются к следующему этапу (т.е. Rewriter.) Утилита запросы направляются в

Команды Утилита.

3) Утилита Команды обрабатывает запросы, которые не требуют сложной обработки.

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

Команды утилиты.

4) Запрос Rewriter является подсистемой между Parser и Planner. Это

обрабатывает дерево разбора, принятый гаишник и, применяя любые применимые

править в настоящее время она переписывает дерево в альтернативную форму. Этот этап позволяет

PostgreSQL поддерживать мощную систему правил для спецификации мнениями и

неоднозначные просматривать обновления.

5) Планировщик обеспечивает оптимальный план выполнения для данного запроса. Основная идея

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

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

запрос. Все созданные пути ведут к одному результату и планировщик оценкам

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

переходит к Исполнителю.

6) Исполнитель принимает план передается обратно планировщиком и начинает обработку

верхний узел. Это выполняет дерево плана, который является конвейерный спроса тянуть сеть

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

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

которые они вычислить свои выходные кортежи. Узлы верхних уровней, как правило, присоединиться

узлов. Каждый присоединиться узел объединяет два входных потоков кортежей в один. В противоположность этому,

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

сканы. Исполнитель использует системы хранения при сканировании отношения,

выполняет виды и присоединяется, оценивает квалификацию и, наконец, руки назад кортежи

получены.

Запрос / командной строки для

Рисунок 3 Запрос / командной строки для Архитектура

На рисунке 3 показана концептуальная архитектура утилит PostgreSQL сервера структурированных

как объектно-ориентированного проектирования. Каждая утилита компонент отличается по своей функциональности, как

подробно описаны ниже:

1) Каталог: она обеспечивает системного каталога манипуляции, и содержит создание и

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

Процедура, оператор, тип, совокупный и т.д. Модуль Каталог используется всеми суб-

системы заднем конце.

2) Доступ: он определяет доступ к данным для кучи, индексы и сделок. Его функция заключается три

складки: обеспечить основные правила доступа к данным; обеспечить структуру доступа к данным в

форма хэш, кучи, индекса BTree и т.д.; выступать в качестве фазы менеджера во время операций.

Модуль доступа используется всеми подсистемами заднем конце.

3) Узлы: модуль узлов / списки определяет создании и управлении узлов и списков,

которые являются контейнерами запросу и данных при обработке запроса. Узлы / списков

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

4) Утилиты: Utils предоставляет различные утилиты для серверной части, такие как инициализация, отсортируйте

процедуры, журнал ошибок, картофельные процедуры и т.д. Он широко доступны для всех подсистем

фоновым.

5) начальной загрузки: загрузочный модуль используется, когда PostgreSQL в настоящее время пробег за первый

время в системе. Этот модуль необходим, поскольку PostgreSQL команды

обычно доступ таблицу данных. Такие таблицы данных не существует, когда Postgre является уже

работать в первый раз.

Системный каталог

PostgreSQL использует каталоги в гораздо большей степени и контекста, чем другие DBMSes.

PostgreSQL использует не только каталоги определять таблицы, но и использует его для описания типов данных,

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

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

специализированные базы данных; Пользовательские функции могут быть как стандартные функции или

агрегатные функции; Пользовательские операторы могут использоваться в выражениях в качестве стандарта

выражение. Все каталогу поддерживаются и доступны через каталоге суб-

Система, обеспечивая равномерное организацию.

4. Хранения

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

активен на сервере PostgreSQL. Функциональность модуле хранения включает в себя: обеспечивают

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

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

Модуль и командный модуль.

PostgreSQL использует управление хранением без перезаписи, что означает обновление кортежи

добавляется к столу и старые версии удаляются через некоторое время. PostgreSQL

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

сообщение, которое затем должен быть прочитан всеми бэк-концов.

Рисунок 4 хранения Архитектура менеджер

• Файловый менеджер: обеспечивает управление общими файлами и большими буферизованными файлов.

• Менеджер буфера: обеспечивает управление общими буферов.

• Менеджер Страница: использует алгоритм LRU управлять страниц.

• Блокировка менеджер: предоставляет чтения "и записи" замки для достижения согласованности.

• IPC: понимает синхронизации кэша.

• Disk Manager: предоставляет интерфейс для физического хранения / диск.

Эта цифра показывает концептуальную архитектуру менеджера хранения PostgreSQL. В этом

фигура, двуглавый стрелки указывают зависимость от или от всех менеджером хранения

Подсистема.

. 5 Используйте Корпус: Запрос Workflow

Рисунок 5 Работа Поток запросов

1) Строка запроса SQL преобразуется в дереве запроса.

2) дерево запроса модифицируется Rewriter следующим образом: переписчиком выглядит

до ключевые слова в дереве запроса и расширить его с помощью прилагаемого определению.

3) Планировщик принимает в модифицированном дерева разбора, генерирует все возможные пути запроса.

Затем планировщик оценивает пути для определения оптимального пути и

устанавливает план запроса для этого пути.

4) план запроса преобразуется в серии исполняемых запросов SQL и

обработаны для получения результатов.

6. Заключение

Серверная архитектура PostgreSQL имеет некоторые преимущества. Во-первых, это предварительные фильтры

входящий запрос в полезности и сложного запроса. Этот шаг уменьшает ненужную нагрузку для

Запросы, которые не требуют сложную обработку таких как переписывание и планирование. Кроме того,

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

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

функции и операторы.

С другой стороны, централизованный характер PostgreSQL делает его плохо подходит для

управление крупномасштабных баз данных. Кроме того, база данных должны быть доступны сусло

проживают в том же месте, что и процесс сервера.

Evolvability из PostgreSQL является двусторонний. С положительной стороны, PostgreSQL гибкая

Системный каталог и элегантный режиме клиент-сервер делает его хорошо подходит для домашнего офиса

и управление базами данных для приложений, требующих специализированного манипуляций и

определение. С негативной стороны, централизованное распределение PostgreSQL и отсутствие

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

управления базами данных.

#auto

Subpages (37): View All
Comments