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

Также реализовано отслеживание взаимных блокировок (deadlocks).

• 
  Клиент-серверная архитектура. В PostgreSQL используется архитектура «клиент-сервер» с распределением процессов между пользователями. В целом она напоминает методику работы с процессами в сервере Apache. Главный (master) процесс создает дополнительные подключения для каждого клиента, пытающегося установить соединение с PostgreSQL.
  
• 
  Полнотекстовый поиск. Начиная с версии 8.3 в ядро PostgreSQL включена функция полнотекстового поиска (раньше реализовалась в виде отдельного модуля-расширения). Полнотекстовый поиск позволяет создавать такие запросы к текстовым документам, которые могут гибко настраиваться в завимости от конкретных потребностей.
  
• 
  Ссохраняющая регистрация WAL. WAL  (Write-Ahead Logging) является стандартным методом для обеспечения целостности данных. Сохраняющая регистрация  метод регистрации (журналирования) транзакций, при котором запись в журнале делается до записи данных. Используется также в MS SQL Server. Суть WAL заключается в том, что изменения в файлах данных (таблицы и индексы) должны быть внесены только после записи в журнал (log), в котором фиксируются эти изменения. Эта процедура позволяет не переписывать страницы данных на диске при каждой транзакции, так как в случае аварии мы сможем восстановить базу данных с помощью журнала. Механизм WAL обеспечивает следующие преимущества:
  

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

• 
  Репликация и технология Hot Standby. Начиная с версии 9.0, на основе WAL введена репликация по технологии Hot Standby. Технология позволяет получить на сервере вторую базу данных, которая является актуальной копией оригинальной базы данных, доступной лишь для чтения. Технология может быть использована также и на отдаленном сервере, который подключается к primary- или master-серверу и загружает из него WAL-логи, предоставляя онлайновую репликацию базы данных и поддерживая копию базы данных на отдаленном сервере в актуальном состоянии, а также делая эту копию доступной для запросов на чтение.
  
• 
  Наследование. Таблицы могут наследовать характеристики и наборы полей от других таблиц (родительских). При этом данные, какие добавляются к порожденную таблицу, автоматически будут принимать участие (если это не отмечено отдельно) в запросах к родительской таблице. Данная функция в настоящее время не является полностью завершенной, однако ее состояние достаточно для практического использования.
  
• 
  Гибкая настройка сервера. Основной конфигурационный файл postgresql.conf включает более 150 настраиваемых параметров по разделам: файлы и пути к ним, авторизация и безопасность, выделение ресурсов и т.д. Дополнительный конфигурационный файл pg_hba.conf включает в себя настройку доступа к отдельным БД, такие как указание конкретных IP-адресов и (или) сетей, из которых разрешен доступ, а также метод авторизации для доступа в БД и возможность включения безопасных (зашифрованных) соединений.
  

---

1. 
   Физическая архитектура баз данных PostgreSQL
   

Схема размещения файлов базы данных.

Все данные, необходимые для кластера базы данных хранятся в каталоге, который, как правило, называют PGDATA (как и соответствующую переменную окружения). PGDATA обычно локализован в ../var/lib/pgsql/data. Несколько кластеров, управляемых разными экземплярами сервера, могут существовать на одной машине.

Каталог PGDATA содержит несколько подкаталогов и файлов управления, таких как: PG_VERSION  файл, содержащий номер версии PostgreSQL, base  подкаталог, содержащий подкаталоги баз данных, и др., а также необходимые файлы конфигурации кластера  postgresql.conf , pg_hba.conf и pg_ident.conf  (хотя в PostgreSQL 8.0 и выше, можно сохранить их в другом месте).

Для каждой базы данных в кластере есть подкаталог PGDATA / base , имя которого совпадает с OID (object identifier  идентификатор объекта) базы данных, хранящимся в системной таблице pg_database. Этот подкаталог используется для хранения файлов базы данных, в частности, его системных каталогов.

Каждая таблица и индекс сохраняется в отдельном файле с именем, совпадающим с дескриптором таблицы (filenode). Кроме того каждая таблица или индекс имеет карту свободного пространства (free space map), в которой хранится информация о доступном объеме памяти. Карта свободного пространства хранится в файле с именем, состоящим из десктриптора таблицы или индекса и суффикса_fsm.

Каждое отношение имеет также карту видимости (visibility map) , чтобы отслеживать, какие страницы содержат кортежи, видимые для всех активных транзакций Эта карта хранится в файле с именем, состоящим из дескриптора отношения и суффика _vm. Например, если дескриптор отношения есть 12345, карта видимости хранится в файле с именем 12345_vm в том же каталоге, что и основной файл отношения. Обратите внимание, что индексы не имеют карт видимости.

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

Когда таблица или индекс превышают 1 Гб, они делятся на гигабайтные сегменты (1 Гб  это размер по умолчанию, его можно настроить с помощью опции конфигурации -segsize при сборке PostgreSQL) . Имя файла первого сегмента совпадает с filenode, последующие сегменты называются filenode.1, filenode.2 и т.д. Такая схема позволяет избежать проблем для платформ, которые имеют ограничения на размер файла.

---

PostgreSQL поддерживает табличные пространства (tablespaces), которые позволяют задать место хранения объектов БД в файловой системе. Сначала создается табличное пространство с определенным именем. Далее, это имя может быть использовано при создании таблиц, чтобы разместить эти таблицы именно в данном табличном пространстве. Каждое определяемое пользователем табличное пространство имеет ссылку внутри каталога PGDATA/pg_tblspc, которая указывает на физический каталог этого табличного пространства. Эта ссылка имеет такое же имя, как и OID табличного пространства. Внутри физическиго каталога табличного пространства есть подкаталог с именем, которое зависит от версии PostgreSQL сервера, например, PG_9.0_201008051. В этом подкаталоге содержатся подкаталоги для каждой базы данных ((их имена совпадают с OID базы данных), которая имеет элементы в данном табличном пространстве. Для именования записи таблиц и индексов в этих подкаталогах используется схема, основанная на filenode..

Временные файлы (для таких операций, как сортировка больших объемов данных) создаются в PGDATA/base/pgsql_tmp, или в подкаталоге pgsql_tmp каталога табличного пространства, если для них указано табличное пространство, отличное от табличного пространства по умолчанию. Имя временного файла имеет вид pgsql_tmpPPP.NNN, где PPP  OID вычислительной машины базы данных (backend), NNN  метки различных временных файлов.

Хранение больших значений. Таблицы TOAST.

Для хранения больших по размеру данных в PostgreSQL используется техника TOAST (The Oversized-Attribute Storage Technique). PostgreSQL использует фиксированный размер страницы (обычно 8 Кб), и не позволяет кортежам занимать несколько страниц. Таким образом, невозможно хранить очень большие значения полей непосредственно в таблице. Чтобы преодолеть это ограничение, большие значения сжимаются и/или разбиваются на несколько физических строк. Этот процесс прозрачен для пользователя.

TOAST поддерживается только для определенных типов данных. Для поддержки TOAST тип данных должен иметь переменную длину (varlena), причем первое 32-разрядное слово содержит общую длину значения в байтах, включая само это слово.

TOAST резервирует два бита varlena-слова: старшие биты для машин с обратным порядок байтов (big-endian) и младшие биты для машин с прямым порядком байтов (little-endian). Тем самым размер любого значения ограничивается 1 Гб (2³⁰  1 байт). Нулевые значения битов соответствуют обычным (не TOAST) значениям. В противном случае возможны две комбинации:

1. 
   Самый старший/младший бит varlena-слова установлен, смежный бит сброшен.
   

---

Это указывает на то, что данное значение имеет 1-байтовое, а не 4-байтовое , varlena-слова, а оставшиеся биты этого слова дают общий размер значения (включая байт длины) в байтах. Если остальные биты varlena-слова равны нулю, то данное значение является указателем на данные, хранящиеся в отдельной TOAST-таблице. При этом размер TOAST -указателя дает второй байт значения. Данные с однобайтовыми заголовками не выравниваются по какой-либо конкретной границе.

2. 
   Самый старший/младший бит varlena-слова сброшен, смежный бит установлен.
   

Это говорит о том, что значение было сжато и должно быть распаковано перед использованием. В этом случае оставшиеся биты длины слова дают общий размер сжатых данных, а не исходных данных Сжатие также возможно и для значений, хранящихся в TOAST-таблицах (информацию об этом содержит TOAST-указатель).

Если какой-либо из столбцов таблицы поддерживается TOAST, таблица будет иметь соответствующую TOAST-таблицу, гле и будут храниться значения этого столбца. Такие TOAST-значения делятся (после сжатия, если оно используется) на блоки размером не более TOAST_MAX_CHUNK_SIZE байт (по умолчанию это значение выбирается так, чтобы четыре блока помещались на страницу, всего около 2000 байт). Каждй блок хранится в виде отдельной строки в TOAST-таблице. Каждая TOAST-таблица содержит столбцы:

chunk_id (OID TOAST-значений),

chunk_seq (порядковый номер блока в пределах своего TOAST-значения),

chunk_data (фактические данные блока).

Уникальный индекс по chunk_id и chunk_seq обеспечивает быстрый поиск значений. TOAST-указатель, следовательно, должен хранить OID TOAST-таблицы и OID от конкретного TOAST-значения (его chunk_id). Для удобства, TOAST-указатель также хранит размер несжатых данных и реальный размер хранимых данных (если данные были сжаты). Учитывая байт varlena-заголовка, общий размер TOAST-указателя составляет 18 байт независимо от фактического размера представляемого значения.

Механизм TOAST запускается только тогда, когда строка, которая будет храниться в таблице превышает TOAST_TUPLE_THRESHOLD байт (обычно 2 Кб). Значение столбца, для которого поддерживается TOAST, будет сжиматься и/или перемещаться в TOAST-таблицу пока длина строки не станет короче, чем TOAST_TUPLE_TARGET байт (также обычно 2 Кб).

Механизм TOAST использует четыре различные стратегии для хранения данных:

• 
  PLAIN предусматривает либо сжатие, либо хранение вне основной таблицы, кроме того он исключает использование однобайтовых varlena-заголовков (единственная возможная стратегия для столбцов, для которых не поддерживается TOAST).
  
• 
  EXTENDED позволяет как сжатие и хранение вне основной таблицы. Это  стратегия, используемая по умолчанию для большинства TOAST-типов данных. Сначала будет предпринята попытка сжатия, а затем  запись в TOAST-таблицу, если строка по-прежнему слишком велика.
  
• 
  EXTERNAL позволяет хранение вне основной таблицы, но не сжатие. Использование этой стратегии позволяет ускорить подстроковые операции в текстовых и байтовых полях быстрее (но за счет увеличения пространства для хранения), поскольку эти операции оптимизированы для извлечения необходимых частей данных, когда они не сжаты.
  
• 
  MAIN позволяет сжатие, но не хранение вне основной таблицы. На самом деле, хранение вне основной таблицы будет по-прежнему доступно, но только в качестве крайней меры, когда нет возможности уменьшить строку так, чтобы она поместилась на странице.
  

---

Для каждого типа данных, для которого поддерживается TOAST, определена используемая стратегия по умолчанию, но стратегия для данного столбца таблицы можно изменить с помощью команды ALTER TABLE SET STORAGE

Рассмотренная схема имеет ряд преимуществ по сравнению с более простыми подходами, допускающими, например, использование только строк определенного размера, соответствующего размеру страницы файла базы данных. Если предположить, что в запросах, как правило, фигурируют относительно небольшие значения ключа таблицы, большая часть работы будет производиться исполнителем над не TOAST-полями. Последние будут выбираться (если они вовсе указываются в запросе) только при отправке результатов клиенту. Таким образом, основная таблица намного меньше, чем было бы в случае без каких-либо TOAST-значений. Поэтому и сортировка будет чаще выполняться полностью в оперативной памяти. Тестирование показало, что при использовании TOAST таблица, содержащая типичные HTML-страницы и их URL-адреса, занимает примерно половину размера необработанных исходных данных, причем в основной таблице содержится только около 10% всей информации (URL-адреса и несколько небольших HTML страницы). Для такой таблицы времени выполнения оказывается таким же, как и для таблицы без TOAST , в которой все HTML-страниц были сокращены до 7 Кб.

Формат страницы базы данных.

Каждая таблица и индекс в PostgreSQL хранится как массив страниц фиксированного размера (обычно 8 Кб, хотя иной размер страницы можно выбрать при компиляции сервера). В таблице, все страницы логически эквивалентны, так что та или иная строки может быть сохранена на любой странице. В индексах, первая страница, как правило, защищены в качестве метастраницы, содержащей управляющую информацию, и в индексе могут быть различные типы страниц, в зависимости от метода доступа к индексу

Каждая страница сотоит из пяти частей:

• 
  PageHeaderData (24 байт)  Содержит общую информацию о странице, в том числе указатель свободного пространства;
  
• 
  ItemIdData  массив пар (смещение, длина) по 4 байта каждая, указывающих на фактические элементы данных, хранящихся на странице;
  
• 
  Free space  свободное место. Новые указатели на элементы данных локализуются в начале этой области, новые элементы  с конца;
  
• 
  Items  фактические данные;
  
• 
  Special space  специфические данные с индексным методом доступа, различным для различных данных (эта область  пустая в обычных таблицах).
  

Первые 24 байта на каждой странице отводятся под заголовок страницы (PageHeaderData), состоящий из нескольких полей, в которых содержится информация о частях страницы, описанных выше.

---

Смотрите также файлы

• Исследовательская работа Влияние средств массовой информации на формирование общественного мнения.docx

• Биология 8 сынып 4Тосан і нса Тірі табиатты тарихи дамуы дегеніміз .docx

• Работа выполнена авторами сайта дцо. Рф помощь с дистанционным обучением.docx

• Домашняя работа. 7 класс Геометрия 1112. 04. 23.doc

• Руководство для начинающих ЛитРес Самиздат 2019 бонсай И. Бонсай руководство для начинающих И. бонсай ЛитРес Самиздат.pdf