СУБД PostgreSQL

История ПОСТГРЕС началась в 1977 г. с базы данных Ingress.

В 1986 г. в университете Беркли, Калифорния, она была переименована в PostgreSQL (произносится «Пост-Грес-Кью-Эль»).

В 1995 г. постгрес стала открытой базой данных. Появился интерактивный psql.

В 1996 г. Postgres95 была переименована в PostgreSQL версии 6.0.

У постгреса несколько сотен разработчиков по всему миру.

Архитектура PostgreSQL

PostgreSQL – унифицированный сервер баз данных, имеющий единый движок – storage engine. Постгрес использует клиент-серверную модель.

Для каждого клиента на сервере создается новый процесс (не поток!). Для работы с такими клиентскими процессами сервер использует семафоры.

Клиентский запрос проходит следующие стадии.

1. Коннект.

2. Парсинг: проверяется корректность запроса и создается дерево запроса (query tree). В основу парсера положены базовые юниксовые утилиты yacc и lex.

3. Rewrite: берется дерево запросов и проверяется наличие в нем правил (rules), которые лежат в системных каталогах. Всякий раз пользовательский запрос переписывается на запрос, получающий доступ к таблицам базы данных.

4. Оптимизатор: на каждый запрос создается план запроса – query plan, который передается исполнителю – executor. Смысл плана в том, что в нем перебираются все возможные варианты получения результата (использовать ли индексы, джойны и т.д.), и выбирается самый быстрый вариант.

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

Постгрес – обьектно-реляционная база данных, каждая таблица в ней представляет класс, между таблицами реализовано наследование. Реализованы стандарты SQL92 и SQL99.

Транзакционная модель построена на основе так называемого multi-version concurrency control (MVCC), что дает максимальную производительность. Ссылочная целостность обеспечена наличием первичных и вторичных ключей.

Организация СУБД PostgreSQL

Как и любая СУБД PostgreSQL должна обслуживать запросы sql и возвращать результаты клиентским приложениям. Для этого механизм СУБД оптимизатор запросов принимает решение об оптимальном использовании ресурсов и строит план запроса. При этом он может опереться на используемых механизмы ускорения работы (индексов, кэшей в памяти, ресурсам процессора, данные статистики и т.д.).
Результаты запросов возвращаются клиентским подключениям

В Windows управляет всем файл службы pg_ctl.exe (останавливает, запускает, перезапускает).

Сам движок базы – это postgres.exe.

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

Зато управление дисковым пространством имеет весомое значение. Как и в любой СУБД, для баз данных PostgreSQL лучше использовать RAID 10 для баз данных и отдельный дисковый массив под логии. Применение STORAGE систем может также положительно сказаться на всем быстродействии. Еще одна фича, ускоряющая работу за счет расположения данных на разных дисках, это табличные пространства (tablespaces).

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

У PostgreSQL есть особенность в реализации хранения – это так называемый “кластер”. В данном случаи речь идет месте расположения каталога для баз данных. Плюс PostgreSQL организует единую файловую структуру, в которой отдельные файлы не соответствуют непосредственно таблицам или другим объектам базы данных.

При установке вы указываете “кластер” (читай каталог).

Рисунок 6.7.1

При установке PostgreSQL создает системную базу postgres и базу template1 как шаблон настроек для всех новых баз. Обычно в Linux-среде в каталоге /var/postgres/data находится некоторое количество служебных файлов для PostgreSQL, а в каталоге /var/postgres/data/base размещаются базы данных, каждая в своем отдельном каталоге.

К сожалению, реализованный в PostgreSQL способ хранения данных требует дополнительного обслуживания - периодической дефрагментации базы данных командой VACUUM. Примечание. Материализованные запросы (представления пользователя) view платформой не используются.

Размеры базы данных

На данный момент (версия 9.1.2), в PostgreSQL имеются следующие ограничения:

Максимальный размер базы данных	Нет ограничений
Максимальный размер таблицы	32 ТБайт
Максимальный размер записи	1,6 ТБайт
Максимальный размер поля	1 ГБайт
Максимум записей в таблице	Ограничено размером таблицы
Максимум полей в таблице	250—1600, в зависимости от типов полей
Максимум индексов в таблице	Нет ограничений

Сильными сторонами PostgreSQL считаются:

1. поддержка БД практически неограниченного размера;

2. мощные и надёжные механизмы транзакций и репликации;

3. расширяемая система встроенных языков программирования: в стандартной поставке оддерживаются PL/pgSQL, PL/Perl, PL/Python и PL/Tcl;

4. можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Schemeи PL/sh, а также имеется поддержка загрузки C-совместимых модулей;

5. наследование;

6. легкая расширяемость.

Утилита администрирования баз данных PostgreSQL pgAdmin - графическая оболочка проектирования и административная СУБД PostgreSQL для Unix и системы Windows.

Рисунок 6.7.2

Pgadmin пишется на языке программирования C и использует превосходный пакет разработчика платформы wxWidgets (когда-то wxWindows). pgAdmin распространяется по лицензии PostgreSQL, т.е. также является свободным ПО.

Дата добавления: 2014-12-10