Postgresql описание. Поддерживаемые встроенные типы данных. Создание нового типа

В этой книге описаны принципы действия и область применения многих серверов, выполняющихся в системе Linux. Здесь рассматриваются DHCP-сервер, серверы Samba и NFS, серверы печати, NTP-сервер, средства удаленной регистрации и система X Window. He забыты и средства, традиционно используемые для обеспечения работы Internet-служб: серверы DNS, SMTP, HTTP и FTP. Большое внимание уделено вопросам безопасности сети. В данной книге нашли отражения также средства удаленного администрирования - инструменты Linuxconf, Webmin и SWAT.

Данная книга несомненно окажется полезной как начинающим, так и опытным системным администраторам.

Отзывы о книге

Сетевые средства Linux

Появилась прекрасная книга по Linux, осталось воспользоваться ею. Не упустите свой шанс.

Александр Стенцин, Help Net Security,

www.net-security.org

Если вы стремитесь в полной мере использовать сетевые возможности Linux - эта книга для вас. Я настоятельно рекомендую прочитать ее.

Майкл Дж. Джордан, Linux Online

Выхода подобной книги давно ожидали читатели. Менее чем на 700 страницах автор смог изложить суть самых различных вопросов, связанных с работой Linux. Автор является высококвалифицированным специалистом в своей области и щедро делится своими знаниями с читателями.

Роджер Бертон, West, DiverseBooks.com

Книга:

Разделы на этой странице:

Таблица маршрутизации выполняет две задачи. Во-первых, она сообщает системе, на какой из интерфейсов следует передавать информационные пакеты. На первый взгляд может показаться, что если на компьютере установлен лишь один сетевой интерфейс, то ответ на этот вопрос очевиден. На самом деле это не так. Дело в том, что на каждом из компьютеров, работающих под управлением системы Linux, поддерживается интерфейс обратной петли. Этот интерфейс соответствует сети 127.0.0.0/8, но реально при работе с ним используется лишь один IP-адрес 127.0.0.1. Поскольку этот интерфейс присутствует на всех компьютерах, многие программы используют его для взаимодействия с другими локальными программами. При этом обеспечивается более высокая скорость обмена, чем при использовании традиционных сетевых интерфейсов. Для того чтобы распределять трафик между интерфейсом локальной петли и обычными сетевыми интерфейсами, существуют специальные правила. Вторая задача, которую выполняет таблица маршрутизации, состоит в управлении трафиком, предназначенным для компьютеров в локальной сети. Для маршрутизации в локальной сети используется протокол ARP (Address Resolution Protocol - протокол преобразования адресов). Пакеты, предназначенные узлам локальной сети, непосредственно передаются соответствующим компьютерам, а пакеты, адресованные удаленным узлам, передаются посредством маршрутизатора, или шлюза. В большинстве случаев в таблице маршрутизации Linux указывается лишь один шлюз, но встречаются также более сложные конфигурации с несколькими шлюзами. Для заполнения таблицы маршрутизации используется команда route.

На заметку

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

Структура таблицы маршрутизации

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

Для чтобы лучше понять, как используется таблица маршрутизации, рассмотрим пример такой таблицы. На рис. 2.2 показана таблица маршрутизации, которая отображается в результате выполнения команды route -n (более подробно команда route будет рассмотрена в следующем разделе). Записи таблицы, изображенной на рисунке, упорядочены так, что в начале расположены записи, определяющие наиболее конкретные правила обработки, а в конце таблицы находятся наиболее универсальные правила. В первой записи указан адрес назначения 255.255.255.255, т. е. широковещательный адрес. Широковещательные пакеты передаются через интерфейс eth0 , при этом шлюз не используется. В последующих двух записях содержатся адреса назначения 10.92.68.0 и 192.168.1.0, которые представляют собой адреса локальных сетей; им соответствует маска подсети 255.255.255.0, которая указана в столбце Genmask . Эти две записи направляют трафик соответственно через интерфейсы eth1 и eth0 . Если компьютер содержит только один сетевой интерфейс, в таблице маршрутизации будет указана лишь одна подобная запись. Четвертая запись соответствует интерфейсу обратной петли (в некоторых разновидностях Linux, например в системе Debian, при выводе таблицы маршрутизации этот маршрут не отображается, но он учитывается при обработке пакетов). Обратите внимание, что этот интерфейс имеет имя lo (оно содержится в столбце Ifасе таблицы). Последняя запись, в которой указан адрес назначения 0.0.0.0, определяет маршрут по умолчанию. Этот адрес вместе с маской подсети 0.0.0.0 соответствует любому адресу, при сравнении которого с адресами, указанными в предыдущих правилах, был получен отрицательный результат. В этом случае трафик направляется через интерфейс eth1 . Маршрут по умолчанию - единственный маршрут в таблице, для которого был указан шлюз (в данном случае 10.92.68.1).

Рис. 2.2 . Для того чтобы определить маршрут пакета, надо сравнить его адрес назначения с адресом, указанным в столбце Destination , и учесть при этом маску подсети, значение которой отображается в столбце Genmask

При активизации интерфейса с помощью ifconfig эта утилита автоматически включает в таблицу маршрутизации запись, соответствующую активизированному интерфейсу. Эта запись определяет маршрут к сети, которая подключена через данный интерфейс. Сценарий, выполняющихся при загрузке Linux, добавляет в таблицу запись для интерфейса обратной петли. Запись, соответствующая широковещательному маршруту, не обязательна, но используется некоторыми утилитами. Во многих случаях единственной записью, которую приходится создавать вручную, остается маршрут по умолчанию.

Использование route

Если утилита route вызывается без параметров, она отображает текущее содержимое таблицы маршрутизации. Такой же результат будет получен при указании некоторых опций (например, опции -n , которая указывает на то, что при выводе содержимого таблицы вместо доменных имен должны отображаться числовые IP-адреса). Однако в основном route предназначена для добавления, удаления и изменения записей о маршрутах. Синтаксис route имеет следующий вид:

route add|del [-net|-host] target [ interface ]

Ниже перечислены опции данной утилиты и описано их назначение.

Add|del . Опция add задается тогда, когда необходимо добавить в таблицу запись о новом маршруте, а опция del позволяет удалить существующую запись. При добавлении нового маршрута необходимо задать дополнительную информацию. При удалении можно ограничиться указанием адреса назначения.

[-net|-host] . В качестве адреса назначения вы можете задать либо адрес сети (-net), либо адрес конкретного компьютера (-host). В большинстве случаев route способна самостоятельно отличить адрес сети от адреса узла, но иногда необходимо явно указать тип адреса. Чаще всего данную опцию приходится задавать, определяя маршрут к небольшой сети, подключенной с помощью отдельного шлюза.

адрес_назначения . Адрес назначения принадлежит сети или отдельному компьютеру, которому маршрутизатор должен передать пакет. Для маршрута по умолчанию используется адрес 0.0.0.0 либо эквивалентное ему ключевое слово default . Этот параметр необходимо указывать при добавлении или удалении маршрута.

Если адреса сети, которой должны быть переданы пакеты, соответствуют традиционной схеме распределения адресов, утилита route , пользуясь сетевыми средствами Linux, сама определит значение маски подсети. В противном случае вам необходимо явно задать маску подсети, указав при вызове route параметр netmask nm . (Вместо использования данного параметра вы можете указать число бит, выделяемых для представления адреса сети, в составе адреса назначения.)

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

На рис. 2.2 среди прочих изображен столбец Metric . В нем отображается метрика маршрута, т.е. "стоимость" передачи пакета. Чаще всего за "стоимость" принимается время передачи пакета. Таким образом, маршрутам, на которых встречаются линии с низким быстродействием, соответствуют высокие значения метрики, а "быстрым" маршрутам - низкие значения метрики. Параметр metric m используется только в том случае, если компьютер выполняет роль маршрутизатора. Подробно вопросы настройки маршрутизаторов будут рассмотрены в главе 24.

Параметр mss m задает максимальный размер сегмента (MSS - Maximum Segment Size). Подобно metric m , данный параметр используется в основном в маршрутизаторах.

Размер окна (TCP Window Size) - это объем данных, которые могут быть переданы передающим узлом, не дожидаясь получения подтверждения с принимающего узла. Если задано небольшое значение данного параметра, скорость обмена данными уменьшится, так как передающий компьютер будет простаивать, ожидая подтверждения приема пакета. Если указать слишком большой размер окна, повышается вероятность того, что вследствие возникновения ошибки передающему узлу придется повторять передачу большого объема информации. Поэтому наилучшее решение - использовать размер окна по умолчанию (в системе Linux он составляет 64 Кбайт). Если данные по линии передаются быстро, но с большой задержкой (например, если используется спутниковая связь), то целесообразно увеличить размер окна до 128 Кбайт.

[ имя_интерфейса ] . Как правило, система Linux по IP-адресу самостоятельно определяет используемый интерфейс. Однако в некоторых случаях необходимо указать интерфейс явно, задавая при вызове route параметр имя_интерфейса . (Ключевое слово dev указывать не обязательно, достаточно задать имя интерфейса, например eth0 или tr1 .)

Наиболее часто с помощью утилиты route задается маршрут по умолчанию. Делается это после того, как посредством утилиты ifconfig был активизирован сетевой интерфейс. Пример определения маршрута по умолчанию с помощью route приведен ниже.

# route add 0.0.0.0 gw 10.92.68.1

Адрес 0.0.0.0 можно заменить ключевым словом default ; результат выполнения команды от этого не изменится. Несколько реже при вызове route приходится указывать имя устройства, опцию -net и некоторые другие опции.

Использование нескольких интерфейсов и одного шлюза

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

Вызов ifconfig для каждого из интерфейсов компьютера.

Одиночный вызов route для добавления в таблицу маршрутизации маршрута по умолчанию.

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

# echo "1" > /proc/sys/net/ipv4/ip_forward

На заметку

Если компьютер содержит два сетевых интерфейса (т.е. одновременно принадлежит двум сетям), но не должен выполнять функции маршрутизатора, не следует разрешать перенаправление IP-пакетов.

На заметку

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

Если провайдер выделил для вашего компьютера лишь один IP-адрес, но вы хотите организовать доступ к Internet с нескольких компьютеров, подключенных к локальной сети, вам необходимо использовать специальный тип маршрутизатора, в котором используется технология NAT (Network Address Translation - преобразование сетевых адресов). Эта технология подробно описана в главе 25. Настройка системы NAT выполняется подобно настройке обычного маршрутизатора, кроме того, в этом случае приходится выполнять дополнительные команды, разрешающие преобразование адресов. В результате такого преобразования вся локальная сеть выглядит извне как один компьютер.

Использование нескольких интерфейсов и шлюзов

Если компьютер с несколькими интерфейсами должен передавать пакеты на различные шлюзы, его настройка несколько усложняется. Большинство систем работает с одним шлюзом, через который проходит маршрут по умолчанию. Такой шлюз соединяет локальную сеть с другой сетью, и в большинстве случаев посредством этого же шлюза осуществляется взаимодействие с Internet. Однако возможны и другие варианты конфигурации сети. Рассмотрим локальные сети, представленные на рис. 2.3. Как видно на рисунке, две локальные сети, принадлежащие различным подразделениям одной организации, соединены с помощью маршрутизаторов. Конфигурация обычных компьютеров, принадлежащих этим сетям, очень проста; в маршруте по умолчанию в качестве адреса шлюза указан адрес маршрутизатора, через который локальная сеть подключена к другой сети. Несмотря на то что маршрутизатор сети Office 2 имеет два интерфейса, в маршруте по умолчанию, заданном в его таблице маршрутизации, роль шлюза играет маршрутизатор сети Office Маршрутизатор сети Office 1 имеет более сложную конфигурацию. Его маршрут по умолчанию обеспечивает обмен пакетами с Internet, кроме того, трафик, предназначенный для сети 172.20.0.0/16, должен передаваться на маршрутизатор Office 2. Чтобы такая передача пакетов могла выполняться, необходимо вызвать следующую команду:

# route add -net 172.20.0.0 netmask 255.255.0.0 gw 172.21.1.1

Рис. 2.3 . Чтобы маршрутизатор, содержащий больше двух интерфейсов, работал корректно, для него должны быть определены как минимум два шлюза

На заметку

Структура, показанная на рис. 2.3, имеет смысл только в том случае, если сети Office 1 и Office 2 расположены далеко друг от друга и для их взаимодействия используется один из протоколов поддержки удаленного соединения. Если же подразделения находятся рядом, например в одном здании, целесообразно подключить обе сети к одному концентратору или коммутатору. При этом обе сети могут обслуживаться одним маршрутизатором.

В данном случае предполагается, что маршрутизатор Office 2 использует для соединения с маршрутизатором Office 1 сетевой интерфейс с адресом 172.21.1.1. Заметьте, что этот адрес не принадлежит сети Office 2 (все компьютеры сети Office 2 соединены с маршрутизатором Office 2 через один интерфейс, а маршрутизатор Office 1 подключен к нему через другой интерфейс). Если кроме приведенной выше команды для маршрутизатора Office 1 также задать с помощью утилиты route маршрут по умолчанию, то в результате в таблице маршрутизации будут определены два шлюза: один в качестве маршрута по умолчанию, а другой - для управления трафиком, предназначенным для сети Office 2. Заметьте, что остальные компьютеры в сети Office 1 не обязаны знать об особенностях настройки маршрутизатора, в них должна содержаться лишь информация о маршруте по умолчанию, в котором роль шлюза выполняет маршрутизатор этой сети.

Подобная конфигурация маршрутизатора может потребоваться и в других случаях. Предположим, что в сети Office 1 присутствует второй маршрутизатор, посредством которого локальная сеть подключается к Internet. При этом для каждого компьютера сети Office 1 должны быть определены два шлюза: шлюз по умолчанию, т.е. компьютер, посредством которого осуществляется соединение сети с Internet, и второй шлюз, через который походит маршрут к компьютерам сети Office 2. (Компьютеры сети Office 1 могут быть сконфигурированы и по-другому, для них может быть определен только шлюз по умолчанию, который, в свою очередь, будет передавать пакеты на второй шлюз. Как нетрудно заметить, использование такой конфигурации увеличивает трафик локальной сети.) Поскольку использование двух маршрутизаторов затрудняет настройку компьютеров, желательно использовать в сети один маршрутизатор.

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

20.07.2015 Иван Панченко

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

Корни PostgreSQL уходят в проект POSTGRES Майкла Стоунбрейкера, профессора Калифорнийского университета в Беркли, получивший развитие как одна из трех ветвей реляционных баз данных. Первая выросла из System R, продвигаемой IBM в начале 70-х, вторая - это проект Ingres Стоунбрейкера и третья - Oracle. СУБД Ingres развивалась в духе Беркли как открытая база, коды которой распространялись на лентах по цене почтовых отправлений. Система разрабатывалась для операционной системы UNIX PDP 11, что и предопределило ее популярность, а либеральная лицензия BSD и харизма Стоунбрейкера способствовали как развитию Ingres, так и появлению большого количества реляционных СУБД.

Проект Postgres стал результатом осмысления опыта Ingres и желания преодолеть ограниченность типов данных за счет возможности определения новых типов. Работа над проектом началась в 1985 году; в период с 1985 по 1988 год появились описание модели данных, язык запросов POSTQUEL и хранилище, однако уже тогда отмечалась ограниченность реляционной модели, вытекающая из ее простоты. Первая версия постреляционной СУБД Postgres вышла в 1989 году, причем коды Ingres и Postgres не имели ничего общего. После выпуска в 1993 году версии 4.2 проект был закрыт, однако открытый код и лицензия BSD подвигли выпускников Беркли Эндрю Ю и Джолли Чена в 1994 году взяться за его дальнейшее развитие. После замены языка запросов POSTQUEL на стандартный SQL проект, получивший название Postgres95, сразу привлек к себе множество последователей.

В 1996 году проект получил название PostgreSQL, чтобы подчеркнуть связь с оригинальным проектом POSTGRES и SQL, а управление им взяла на себя инициативная группа пользователей и разработчиков PGDG (PostgreSQL Global Development Group). Все решения о планах развития и выпусках новых версий принимаются управляющим комитетом (Core team), состоящим из шести человек. Помимо этого, выделяется группа основных (major) разработчиков (около 20 человек, из которых трое из России), внесших существенный вклад в развитие PostgreSQL, а также просто разработчиков.

Разработка и поддержка

Цикл работы над очередной «мажорной» версией PostgreSQL обычно составляет около года, в течение которого любой желающий может отправить на рассмотрение свои рекомендации (патчи). Для их обсуждения используется список рассылки pgsql-hackers, и если патч прошел обязательную процедуру проверки другими разработчиками, то он включается в новый релиз (на сайте commitfest.postgresql.org организована процедура отслеживания статуса предложенных рекомендаций). В ходе подготовки релиза появляются бета-версии, выпуск которых обычно совмещается с проведением конференций PGDG.

В некоторый момент объявляется этап замораживания кода (code freeze), в течение которого рекомендации с новой функциональностью не принимаются, а допускается только исправление или улучшение кода. Иногда в процессе работы над новой версией вскрываются или исправляются ошибки предыдущих версий (backporting), и по мере накопления таких исправлений принимается решение о выпуске новой стабильной версии, совместимой со старой. Например, 9.4.4 - это исправленная версия (bugfix) стабильной версии 9.4. Ближе к концу цикла выпускается Release Candidate, а затем выходит и новая мажорная версия PostgreSQL.

Через списки рассылки PGDG выполняет поддержку мажорных версий на протяжении пяти лет с момента ее выпуска, причем корректно оформленное сообщение об ошибке имеет все шансы на скорейшее рассмотрение и нередки случаи, когда исправления выпускаются в течение суток. Помимо поддержки сообществом разработчиков, ведется и коммерческая поддержка PostgreSQL, которую осуществляют ряд компаний: EnterpriseDB в Северной Америке, 2ndQuadrant, Dalibo и другие в Европе и «Постгрес Профессиональный» в России.

Российский след PostgreSQL

Одним из первых разработчиков PostgreSQL (1996 год) был Вадим Михеев из Красноярска. Он автор таких частей СУБД, как: многоверсионное управление одновременным доступом (multiversion concurrency control, MVCC), на которой в современном PostgreSQL базируются управление транзакциями и поддержка целостности данных; система очистки (Vacuum); журнал транзакций (WAL); вложенные запросы и триггеры. Сегодня среди основных разработчиков проекта PostgreSQL три представителя из России: научный сотрудник ГАИШ МГУ Олег Бартунов, выпускник физфака МГУ Федор Сигаев и Александр Коротков (МИФИ). Ими выполнена локализация PostgreSQL (поддержка национальных кодировок, включая Unicode), создана система полнотекстового поиска и работы со слабоструктурированными данными (hstore, json, jsonb), а также предложены новые методы индексации (GiST, GIN, SP-GiST).

Бартунов и Сигаев входили в команду разработчиков портала «Рамблер» (лидера Рунета начала 2000-х), для которого потребовалось создать систему управления контентом и платформу для разработки контентных проектов, сочетающую высокую производительность и гибкость. Именно тогда возникла идея организовать средствами СУБД быстрый поиск по массивам, однако на тот момент в PostgreSQL поддерживалась работа с индексами типов B-tree и R-tree, что плохо подходило для данной задачи, поэтому разработчики обратили внимание на инфраструктуру обобщенных индексных деревьев Generalized Search Tree (GiST).

Первоначально система GiST была исследовательским проектом - обобщением над R-tree и его вариациями (RD-tree, signature-tree и т. д.), а реализация GiST для PostgreSQL, предложенная авторами GiST, имела много ограничений (ключи только фиксированного размера, отсутствие поддержки восстановления и т. д.), не позволяющих говорить о промышленном использовании. Бартунов и Сигаев модернизировали GiST, которая стала полноценным компонентом PostgreSQL, - на ее базе были разработаны индексы для быстрого поиска по массивам, система полнотекстового поиска OpenFTS и индексы для поиска по деревьям и графам ltree. Реализация R-tree с помощью GiST заменила отдельную реализацию R-tree в PostgreSQL.

В 2011 году Александр Коротков, будучи аспирантом МИФИ, в рамках программы Google Summer of Code разработал реализацию алгоритма построения GiST на дисковом пространстве и представил ее на конференции PGConf.EU 2011 (https://wiki.postgresql.org/images/0/07/Fast_GiST_index_build.pdf). Затем он предложил новый алгоритм разделения узла для R-tree, который был использован в различных применениях GiST: для встроенных геометрических типов данных, диапазонов, pgSphere, типа geometry в PostGIS.

Система полнотекстового поиска PostgreSQL является одним из главных достоинств этой СУБД: возможность включать полнотекстовые критерии поиска в произвольные SQL-запросы выгодно отличает поиск в PostgreSQL от специализированных поисковых движков типа Solr или Sphynx. Сигаев и Коротков разработали систему нечеткого поиска по текстам, действующую на основе разложения на триграммы, - модуль pg_trgm, добавивший возможность индексного поиска по условиям LIKE/ILIKE, а также по регулярным выражениям. Индексный поиск по регулярным выражениям pg_trgm был представлен на международной конференции PGCon 2012 (http://www.pgcon.org/2012/schedule/attachments/248_Alexander%20Korotkov%20-%20Index%20support%20for%20regular%20expression%20search.pdf). Однако для эффективного полнотекстового поиска и поиска по масcивам производительности GiST-индексов не хватало - требовался обратный индекс. По аналогии с GiST такой индекс был реализован: Generalized Inverted iNdex (GIN) позволяет осуществлять индексирование сложных объектов с произвольным разбиением на ключи. GIN был представлен на PostgreSQL Anniversary Summit в Торонто в 2006 году (http://www.sai.msu.su/~megera/postgres/talks/Gin-toronto-2006.pdf). В результате СУБД PostgreSQL может сегодня конкурировать со специализированными системами полнотекстового поиска. Дальнейшим развитием GiST стала технология поиска ближайших соседей (KNN), позволяющая организовывать эффективный поиск как ближайших геометрических объектов, так и похожих изображений и других сложных массивов данных.

Одно из самых популярных расширений PostgreSQL - модуль PostGIS, поддерживающий стандарт OpenGIS и все ГИС-проекции для работы с геометрическими данными в пространствах от двух до пяти измерений. В PostGIS включен разработанный Коротковым алгоритм разделения узла для типа geometry, что увеличило скорость поиска от трех до десяти раз.

Начиная с версии 8.2 (2006 год) в PostgreSQL появилось расширение Hstore, реализующее тип данных для хранения набора пар «ключ - значение», и с ростом востребованности документоориентированных СУБД возникла идея добавить в Hstore поддержку вложенности, типов и массивов. Прототип был представлен Бартуновым и Сигаевым на конференции PGCon 2013. Впоследствии на основе этой работы был создан тип данных jsonb, реализующий эффективное бинарное хранение json-объектов, что стало одной из ключевых особенностей версии PostgreSQL 9.4.

Современная СУБД PostgreSQL

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

Надежность и безопасность

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

Особое внимание в PostgreSQL уделено обеспечению безопасности - СУБД предоставляет различные методы аутентификации: по паролю в открытом или зашифрованном (md5) виде, с помощью серверов LDAP, RADIUS или подключаемых модулей (PAM); по внешней аутентификации (ident, peer, cert - сертификатSSL, gss - Kerberos по протоколу GSSAPI, sspi - Kerberos/NTLM для Windows). При управлении пользователями и доступом к объектам базы данных имеется возможность выделять отдельных пользователей и роли, которые могут быть вложенными; доступ к объектам базы (grant/revoke) может осуществляться как напрямую пользователями, так и косвенно через роли; в версии 9.5 появится разделение доступа на уровне столбцов и строк (Row Level Security); реализована поддержка SELinux через встроенную функциональность SE-PostgreSQL (мандатный доступ).

По мере развития стандарта ANSI SQL его поддержка осуществлялась и в PostgreSQL: SQL-92, SQL:1999, SQL:2003, SQL:2008 и SQL:2011. Версия PostgreSQL 9.4 поддерживает 160 из 179 обязательных возможностей SQL:2011.

СУБД PostgreSQL обеспечивает полную поддержку свойств ACID и гарантирует изоляцию транзакций благодаря механизму многоверсионного управления одновременным доступом - транзакции на чтение никогда не блокируют транзакции на запись, и наоборот. Это справедливо и для самого строгого уровня изоляции SERIALIZABLE, который использует инновационную систему SSI (SERIALIZABLE SNAPSHOT ISOLATION) и обеспечивает полную изоляцию транзакций, гарантирующую, что результат работы одновременных транзакций будет такой же, как и при их последовательном исполнении.

Возможности для разработчиков

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

интерфейсы для Tcl, Perl, C, C++, PHP, Json, ODBC, JDBC, Embedded SQL in C, Python, Ruby, Java;
представления, последовательности, наследование, ограничения целостности, внешнее соединение, вложенные запросы, window-функции, CTE (запросы WITH), хранимые процедуры, функции, триггеры;
встроенная гибкая система полнотекстового поиска с поддержкой русского и всех европейских языков;
поддержка NoSQL: слабоструктурированные данные (xml, json, jsonb);
подключение внешних источников в качестве таблиц всех основных баз данных с возможностью записи через Foreign Data Wrappers.

Расширяемость и применение

Расширяемость - одно из фундаментальных свойств системы, лежащее в основе ее архитектуры. Пользователи могут самостоятельно добавлять функции, типы данных, операторы для работы с новыми типами, использовать индексные методы доступа (Btree, Hash, GiST, GIN, SP-GiST) и языки программирования (pl/pgsql, pl/perl, pl/python, pl/tcl, pl/R, pl/java, pl/v8,.. .). Подключение к внешним источникам (Foreign Data Wrappers) осуществляется через интерфейсы практически ко всем СУБД, а загружаемые расширения позволяют, например, поддерживать геоинформационные данные PostGIS, осуществлять нечеткий поиск с помощью триграмм, работу с массивами и др.

Среди крупнейших пользователей PostgreSQL такие компании, как Microsoft, Yahoo, Instagram, BASF и Afilias. Эта СУБД применяется и в государственном секторе: например, во Франции на базе PostgreSQL работают национальная метеослужба и информационная система национального фонда семейных пособий (CNAF), хранящая данные о 30 млн человек. В России PostgreSQL используется, в частности, компаниями «Яндекс», Avito, а также в ряде государственных структур и на промышленных предприятиях.

PostgreSQL поддерживает все клоны Unix, включая Linux, FreeBSD, Solaris, HPUX, Mac OS X, а также Windows.

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

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

При индексировании, помимо традиционного B-дерева, также доступны: Hash, GIN (Generalized INverted index - обобщенный обратный индекс), GiST (Generalized Search Tree - обобщенное поисковое дерево), SP-GiST (Space-Partitioned GiST - пространственный индекс) - причем индексы могут строиться по выражениям (функциональные), а при необходимости создаются индексы только для определенных строк в таблице (частичные индексы).

Отечественная экосистема PostgreSQL

Преодоление технологической зависимости невозможно в закрытой среде , поэтому целесообразно внедрять открытое ПО, интегрируя российское сообщество программистов, в частности, в экосистему разработки СУБД PostgreSQL, а также создавать в стране центры компетенции и развивать систему подготовки специалистов. Наличие полного комплекта исходного кода, процедур сборки, а главное, техническая поддержка силами отечественных разработчиков внутри страны являются основой успеха такой интеграции. Действительно, работоспособность СУБД в значительной степени зависит от мощной системы технической поддержки в режиме 24x7x365 - это задача промышленного уровня , которую для PostgreSQL решает в России компания «Постгрес Профессиональный».

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

Масштабируемый кластер shared-nothing высокой доступности. Кластер позволит масштабировать запись и обработку данных в системах OLAP и OLTP при обеспечении высокого уровня доступности, что востребовано в высоконагруженных промышленных системах. Дистрибутив отказоустойчивой конфигурации PostgreSQL позволяет относительно просто развернуть кластер с полным дублированием для работы в динамически изменяющихся вычислительных средах (например, облачных). Кроме того, можно создавать кластер MultiMaster высокой доступности с масштабированием по чтению и записи при увеличении числа узлов, причем за счет шардинга данных общая емкость хранения может превышать доступную на каждом из узлов в отдельности.

Подключаемые хранилища. Механизм foreign data wrapper (fdw) для работы со специализированными хранилищами данных (хранение по строкам или колонкам, работа с диском или хранение в оперативной памяти) позволит ускорить выполнение как OLTP-, так и OLAP-запросов.

Система автоматической адаптивной оптимизации исполнения запросов. Современные методы машинного обучения открывают новые перспективы для развития СУБД - такие задачи, как балансировка нагрузки, расчет плана выполнения запросов, построение эффективных индексов и пр., могут иметь оптимальное решение для конкретных наборов данных, запросов и режимов нагрузки. Кроме того, машинное обучение позволяет адаптивно перестраивать алгоритмы обработки в реальном времени. Разработанные совместно со специалистами из МГУ и НИУ ВШЭ инструменты машинного обучения, встроенные в стандартный функционал СУБД, способны расширить привычную область применения СУБД - в частности, позволят эффективно и с минимальной потерей точности в условиях реального времени выполнять запросы на больших объемах данных. Также появится возможность гибко реагировать на изменения распределения данных и запросов, что особенно важно для СУБД эпохи Интернета вещей.

Расширенная функциональность слабоструктурированных данных. Благодаря технологии, позволяющей работать с данными в формате JSON и JSONB, PostgreSQL сочетает в себе такие преимущества традиционных СУБД, как транзакционность, атомарность изменений и целостность данных, с гибкостью NoSQL без потери производительности. Язык запросов к слабоструктурированным данным дает возможность формулировать на SQL сложные запросы, повышая производительность за счет упрощения структур данных, переноса сложной фильтрации данных из приложений на сторону СУБД и эффективного использования индексов.

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

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

Будущее PostgreSQL

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

Функция Row level security позволяет организовать доступ не к таблице целиком, а к ее отдельным строкам. Эта возможность также известна как Virtual Private Database или Fine-grained access control и дополняет набор существующих в PostgreSQL механизмов для управления доступом к данным. Благодаря функции pgaudit можно выполнять детальный аудит операций в базе данных, что особенно полезно для автоматизации контроля функционирования прикладных систем, например для регистрации аудиторского следа. Кроме этого, в новой версии получили развитие средства работы с Большими Данными - в частности, появились индексы Block Range (BRIN) с методом доступа по диапазонам страниц (они занимают меньше пространства и требуют меньше ресурсов при обновлении, хотя и менее эффективны при выборке данных, чем B-tree). Для повышения надежности было включено расширение pg_rewind, которое при использовании репликации «ведущий-ведомый» позволяет быстро синхронизировать сбойный ведущий сервер с ведомым.

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

Литература

Сергей Муравьев, Сергей Дворянкин, Игорь Насенков. СУБД: проблема выбора // Открытые системы.СУБД. - 2015. - № 1. - С. 22–24. URL: (дата обращения: 1.09.2015).
Константин Селезнев, Виталий Максимов. Импортозамещение: цель или средство? // Открытые системы.СУБД. - 2015. - № 1. - С. 30–33. URL: (дата обращения: 2.09.2015).
Александр Лашманов. Импортозамещение: риски и иллюзии // Открытые системы.СУБД. - 2015. - № 1. - С. 34–35. URL: (дата обращения: 3.09.2015).

Иван Панченко ([email protected]) - заместитель генерального директора, компания «Постгрес Профессиональный» (Москва).

Скриптовые языки - PL/Lua, PL/LOLCODE, PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl и PL/Scheme;

Классические языки - C, C++, Java (через модуль PL/Java);

Статистический язык R (через модуль PL/R).

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

Функции могут выполняться как с правами их создателя, так и с правами текущего пользователя. Иногда функции отождествляются с хранимыми процедурами, однако между этими понятиями есть различие.

Триггеры

Триггеры определяются как функции, инициируемые DML-операциями. Например, операция INSERT может запускать триггер, проверяющий добавленную запись на соответствия определённым условиям. При написании функций для триггеров могут использоваться различные языки программирования.

Триггеры ассоциируются с таблицами. Множественные триггеры выполняются в алфавитном порядке.

Правила и представления

Механизм правил (англ. rules) представляет собой механизм создания пользовательских обработчиков не только DML-операций, но и операции выборки. Основное отличие от механизма триггеров заключается в том, что правила срабатывают на этапе разбора запроса, до выбора оптимального плана выполнения и самого процесса выполнения. Правила позволяют переопределять поведение системы при выполнении SQL-операции к таблице. Хорошим примером является реализация механизма представлений (англ. views): при создании представления создается правило, которое определяет, что вместо выполнения операции выборки к представлению система должна выполнять операцию выборки к базовой таблице/таблицам с учетом условий выборки, лежащих в основе определения представления. Для создания представлений, поддерживающих операции обновления, правила для операций вставки, изменения и удаления строк должны быть определены пользователем.

Индексы

В PostgreSQL имеется поддержка индексов следующих типов: B-дерево , хэш, R-дерево, GiST, GIN. При необходимости можно создавать новые типы индексов, хотя это далеко не тривиальный процесс. Индексы в PostgreSQL обладают следующими свойствами:

возможен просмотр индекса не только в прямом, но и в обратном порядке - создание отдельного индекса для работы конструкции ORDER BY ... DESC не нужно;
возможно создание индекса над несколькими столбцами таблицы, в том числе над столбцами различных типов данных;
индексы могут быть функциональными, то есть строиться не на базе набора значений некоего столбца/столбцов, а на базе набора значений функции от набора значений;
индексы могут быть частичными, то есть строиться только по части таблицы (по некоторой её проекции); в некоторых случаях это помогает создавать намного более компактные индексы или достигать улучшения производительности за счёт использования разных типов индексов для разных (например, с точки зрения частоты обновления) частей таблицы;
планировщик запросов может использовать несколько индексов одновременно для выполнения сложных запросов.

Многоверсионность (MVCC)

PostgreSQL поддерживает одновременную модификацию БД несколькими пользователями с помощью механизма Multiversion Concurrency Control (MVCC). Благодаря этому соблюдаются требования ACID и практически отпадает нужда в блокировках чтения.

Полнотекстовый поиск

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

Геоинформационные системы

PostGIS - расширение СУБД PostgreSQL предназначенное для хранения в базе географических данных. PostGIS включает поддержку пространственных индексов R-Tree/GiST и функции обработки геоданных.

2019: Совместимость с TerraLink xDE

2018

Включение в список коммитеров СУБД PostgreSQL сооснователя Postgres Professional Александра Короткова

В июне 2018 года список коммитеров (разработчиков, вносящих вклад в развитие кода) СУБД PostgreSQL пополнился третьим россиянином. В список основных коммитеров ядра PostgreSQL , сооснователь и руководитель разработки российской компании Postgres Professional .

2017

Документация версии 10 локализована для России

Основные нововведения:

Логическая репликация : отдельные части этого механизма были добавлены в PostgreSQL уже довольно давно, а в этой версии логическая репликация стала полностью доступна для пользователей. С ее помощью можно выборочно реплицировать отдельные таблицы на другой сервер , который при этом может выполнять как читающие, так и пишущие запросы. Серверы, участвующие в репликации, могут работать под управлением разных версий PostgreSQL, что позволяет проводить обновление кластера с минимальным временем простоя.
Декларативное секционирование избавляет администратора от необходимости вручную определять иерархию таблиц, создавать триггеры и ограничения целостности.
Параллельное выполнение запросов стало возможным для сканирования битовых карт и индексов, для соединения слиянием и подзапросов в дополнение к тем возможностям, которые появились в предыдущей версии.
Синхронная репликация с учетом кворума позволяет фиксировать изменения, если их подтвердило необходимое число произвольных реплик.
SCRAM-аутентификация является более криптостойким вариантом используемой ранее MD5-аутентификации .

Всего, по словам разработчиков, в версию 10 вошло более 100 изменений и улучшений, часть из которых выполнена в компании Postgres Professional .

Интеграция с Ethereum

14 сентября 2017 года российская компания Postgres Professional объявила о создании прототипа расширения Posthereum для интеграции полнофункциональной СУБД PostgreSQL с блокчейн -платформой , предназначенной для регистрации сделок с любыми видами активов на основе системы «умных контрактов». По замыслу компании, крупные российские банки, корпорации и госструктуры, работающие с СУБД PostgreSQL, с помощью данной разработки смогут объединить базы данных с блокчейн-приложениями на основе Ethereum. Подробнее .

2016

PostgreSQL 9.6

29 сентября 2016 года сообщество разработчиков представило стабильную ветку СУБД PostgreSQL 9.6. Обновления для нее 9.6 будут выходить в течение пяти лет, до сентября 2021 года.

Основные дополнения

Сравнение Tibero и PostgreSQL

Корректирующий выпуск всех веток

11 февраля 2016 года сообщество разработчиков PostgreSQL сообщило о выпуске корректирующих обновлений для всех поддерживаемых веток PostgreSQL: 9.5.1, 9.4.6, 9.3.11, 9.2.15 и 9.1.20, в которых устранены две уязвимости, представлена порция исправлений ошибок, добавлена поддержка Python 3.5 в PL/Python и обеспечена возможность совместного использования Python2 и Python3 в одной БД .

Поддержка ветки 9.0.x прекращена. Выпуск обновлений для ветки:

9.1 продлен до сентября 2016 года.
9.2 продлен до сентября 2017 года,
9.3 продлен до сентября 2018 года,
9.4 продлен до декабря 2019 года,
9.5 продлен до января 2021 года.

Первая из уязвимостей (CVE-2016-0773) проявляется в движке обработки регулярных выражений и может привести к краху бэкенда при разборе регулярных выражений с символами вне диапазона Unicode (проблеме подвержены системы, в которых пользовательский ввод применяется для генерации регулярного выражения).

Вторая уязвимость (CVE-2016-0766) присутствует в движке PL/Java и позволяет повысить свои привилегии при работе с БД.

PostgreSQL 9.5

7 января 2016 года стало известно о выходе стабильной ветки СУБД PostgreSQL 9.5. Выпуск обновлений для ветки 9.5 будет поддерживаться до января 2021 года .

Изменения

Функциональность "UPSERT" (добавить-или-модифицировать), реализованная через новое выражение "INSERT ... ON CONFLICT DO NOTHING/UPDATE", позволяющая обработать ситуацию невозможности добавления данных через "INSERT", например, из-за нарушения условий уникальности или недопустимости значения одного из полей. Вместо вывода ошибки теперь можно игнорировать выполнение оператора или изменить связанные с ключевым полем данные (т.е. если запись уже существует, вместо INSERT выполнить UPDATE);
Ограничение доступа на уровне строк (Row-Level Security, RLS). Доступ пользователей к данным в таблице теперь можно разграничивать на уровне отдельных строк, например, можно запретить определённой категории пользователей просмотр строк, в которых хранятся данные, добавленные другим пользователем. Для активации RLS следует использовать директиву "ALTER TABLE tablename ENABLE ROW LEVEL SECURITY", после чего следует задать правила доступа при помощи выражения "CREATE POLICY";
BRIN-индексы ("индексы блоковых зон", Block Range Index), позволяющие сверхкомпактно индексировать очень большие таблицы, без применения традиционных B-деревьев. Суть BRIN-индексов сводится к разбиению общего индекса на блоки, каждый из которых содержит данные индекса только для определённого диапазона значений. В тесте подобный метод оказался примерно в два раза медленнее b-деревьев при осуществлении операций выборки данных, но в 3-4 раза быстрее при создании и обновлении индекса, а также занял значительно меньше места на диске (64 Кб против 28 Мб);
Новые функции и операторы для типа данных JSONB. Для изменения значений в документе JSONB теперь можно обойтись без извлечения и переопределения всего документа, благодаря появлению функции jsonb_set(). Также добавлены функции json_strip_nulls (удаление атрибутов, содержащих значения NULL) и jsonb_pretty (вывод в отформатированном JSON). Добавлен оператор "||" для соединения двух значений JSONB;
Инструмент pg_rewind, позволяющий существенно упростить процесс восстановления отказоустойчивых конфигураций после переключения на резервный сервер. После возвращения в строй основного сервера возникает задача синхронизации его состояния с продолжившим работу запасным сервером, который успел накопить свою порцию изменений. Утилита pg_rewind пытается восстановить состояние первичного сервера по WAL-логу транзакций, перебирая их начиная с момента незадолго до сбоя, определяя изменённые данные и перенося только изменившиеся блоки, что позволяет обойтись без восстановления полной копии с работающего резервного сервера.
Значительно оптимизированы скорости сортировки и хэширования в памяти. Благодаря применению нового метода сортировки строковых значений и чисел, удалось до 20 раз увеличить скорость создания индексов, а время выполнения запросов требующих сортировки больших объёмов данных, сократить в 2-12 раз;
Добавлена поддержка выражения TABLESAMPLE, позволяющего сформировать выборку над неполным объёмом данных из больших таблиц, без выполнения ресурсоёмких операций сортировки над всей таблицей. Например, запрос "SELECT * FROM test TABLESAMPLE SYSTEM(10)" сформирует вывод, охватив только 10% от таблицы test. Доступно несколько алгоритмов отсеивания значений в процессе неполной выборки;
Улучшено масштабирование на системах с большим количеством процессорных ядер и оперативной памяти. Например, на системе с 24 ядрами CPU и 496 Гб ОЗУ в тесте EnterpriseDB при нагрузке в 64 одновременных соединения PostgreSQL 9.5 показал прирост производительности в 96% по сравнению с PostgreSQL 9.4;
Автоматизировано управление размером лога транзакций. Возможность исключения отражения таблиц в логе транзакций (ALTER TABLE ... SET LOGGED / UNLOGGED);
Аналитические возможности "GROUPING SETS", "CUBE" и "ROLLUP", позволяющие формировать вывод с группировкой по набору полей и рассчитывать число комбинаций различных категорий;
Улучшена репликация и средства повышения отказоустойчивости. Добавлен механизм отслеживания состояния выполнения репликации, в том числе реализованы методы для определения причины возникновения отдельных изменений в процессе выполнения логической репликации;
Произведены множественные улучшения в механизме Foreign Data Wrappers, включая выражение "IMPORT FOREIGN SCHEMA", которое позволяет автоматизировать импорт всех связанных внешних таблиц для существующих таблиц с выбранной меткой сервера. Кроме того, обеспечена возможность наследования внешних таблиц в локальных таблицах и наоборот, например, "CREATE local_customers () inherits (remote.customers);"
В утилиту vacuumdb добавлена опция "-j", позволяющая запускать VACUUM в несколько одновременно выполняемых потоков.

2015

Инфраструктура параллельных вычислений в PostgreSQL

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

Она предоставляет:

Удобные процедуры для координирования запуска и завершения работы параллельно выполняемых рабочих процессов;
Синхронизация различных внутренних состояний (GUCs, комбинированный маппинг CID, снапшоты транзакций) между лидером группы параллельных работ и непосредственно распараллеленными рабочими процессами;
Ограничение вызова различных операций, которые могут привести к внесению некорректных изменений в условиях активного распараллеливания;
Доставка уведомлений клиенту через сообщения ErrorResponse, NoticeResponse и NotifyResponse от работающих в параллельном режиме обработчиков.

Postgres-XL на EcoServer - альтернатива для ЦОД

13 августа 2015 года стало известно о завершении испытаний системы управления базами данных Postgres-XL на серверах линейки EcoServer .

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

Андрей Черногоров , генеральный директор «Индиго ИТ », отметил: «Сегодня на рынке ИТ наиболее востребованными являются СУБД MS SQL и Oracle DataBase . Вместе с тем, по ряду ключевых возможностей им ни чем не уступает, а кое-где и превосходит, СУБД с открытыми кодами PostgreSQL , что открывает перед ней широкие перспективы для использования в рамках программы импортозамещения».

Для тестирования специалисты компании подготовили идентичные для всех СУБД тестовые наборы данных. Объектом испытаний стала база данных объемом 1 ТБ, состоящая из 1 млн. бизнес-объектов. Продолжительность тестирования для каждой СУБД - 10 часов.

В нем участвовали последние версии наиболее востребованных заказчиками «Индиго ИТ » СУБД :

открытая СУБД PostgreSQL 9.4 .

Всего проведено 5 наборов тестов:

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

Результаты тестирования, 2015

Под временем, затраченным в каждом из наборов тестов указанных в таблице, имеется ввиду усредненное по всем наборам значение (мс). Тестирование проводилось на серверах с процессорами Intel Xeon Е5 v3 с 128 Гб ОЗУ.

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

Поддержка данной версией СУБД с открытым кодом PostgreSQL широко распространенного формата обмена данными JSON нацелена на растущий рынок нереляционных хранилищ данных NoSQL и особенно на популярную СУБД MongoDB .

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

Версия PostgreSQL 9.4 поддерживает формат JSON (JavaScript Simple Object Notation), который быстро завоевал популярность при организации обмена данными между различными системами, в том числе и с применением протокола REST (Representational State Transfer). Успех документальной СУБД MongoDB во многом обусловлен как раз растущей популярностью JSON .

Структурированный формат PostgreSQL для сохранения данных в соответствии со спецификациями JSON (JSONB) исключает необходимость реструктуризации документа перед его занесением в базу данных. В результате PostgreSQL проглатывает документы так же быстро, как и MongoDB , продолжая при этом удовлетворять требованиям ACID (atomicity, consistency, isolation, durability - атомарность, согласованность, изолированность и надежность), которые предъявляются к хранению информации в базах данных. Кроме того, PostgreSQL поддерживает полный набор индексных сервисов, функций и операторов для эффективного манипулирования данными JSON.

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

PostgreSQL получила ряд новых функций:

Новый интерфейс API для декодирования данных из потока репликации открывает независимым разработчикам программного обеспечения путь к созданию более быстрых реплицирующих систем.
Новая функция Materialized Views, называемая «одновременным обновлением», позволяет на лету обновлять итоговые отчеты.
Функция Alter System Set поможет администраторам изменять файл конфигурации PostgreSQL непосредственно из командной строки SQL.

Добавлен ряд функций и возможностей, среди которых динамические фоновые исполнители (Dynamic Background Workers), манипуляции с массивами и табличные функции, увеличена общая производительность.

PostgreSQL 9.3

В PostgreSQL 9.3 реализован ряд механизмов, позволяющих обмениваться информацией с другими базами и хранилищами данных. Модули Foreign Data Wrapper, которые появились еще в версии 9.1 и раньше позволяли только считывать данные из других систем, теперь предоставляют и возможность записи. Поддерживается работа как с реляционными таблицами, так и с полуструктурированной информацией из систем NoSQL. Для СУБД также создан драйвер, который позволяет связать с друг другом две разных копии самой PostgreSQL и обеспечивает ускоренное выполнение транзакций между ними.

Среди других особенностей - расширенная поддержка JSON и возможность создания произвольных фоновых серверных модулей с неограниченным доступом к данным PostgreSQL. Пример - модуль Mongres, автоматически переводящий запросы MongoDB в формат PostgreSQL.

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

PostgreSQL 9.2

PostgreSQL 9.0

Разработчики открытой системы управления базами данных PostgreSQL выпустили в сентябре 2010 года первый релиз-кандидат системы Postrgesql 9.0, в котором реализованы все функции, заготовленные к выходу в девятой версии этой популярной СУБД. В свободном доступе на данный момент доступна бинарная версия предварительной сборки Postgresql 9.0 и все желающие могут протестировать новые возможности этой разработки перед тем, как переводить на нее производственные серверы, работающие с реальной информацией.

Также в девятой версии появилась возможность репликации информации из бинарных логов, соответствующая механизму Hot Stanby Databases в Oracle Database. Не обошли вниманием разработчики и набирающие популярность облачные или SaaS -системы. Теперь СУБД оптимизирована для работы в среде виртуальных машин, поддерживает механизм быстрого клонирования данных, а также возможность репликации информации с единого мастер-сервера на большое количество (более сотни) подчиненных серверов. Также новый релиз полностью поддерживает возможности адресации памяти в 64-битных вариантах Windows .

SQL ,

Разработка веб-сайтов

Перевод

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day"16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Модель данных

PostgreSQL не просто реляционная, а объектно-реляционная СУБД. Это даёт ему некоторые преимущества над другими SQL базами данных с открытым исходным кодом, такими как MySQL, MariaDB и Firebird.

Фундаментальная характеристика объектно-реляционной базы данных - это поддержка пользовательских объектов и их поведения, включая типы данных, функции, операции, домены и индексы. Это делает Постгрес невероятно гибким и надежным. Среди прочего, он умеет создавать, хранить и извлекать сложные структуры данных. В некоторых примерах ниже вы увидите вложенные и составные конструкции, которые не поддерживаются стандартными РСУБД.

Структуры и типы данных

Существует обширный список типов данных, которые поддерживает Постгрес. Кроме числовых, с плавающей точкой, текстовых, булевых и других ожидаемых типов данных (а также множества их вариаций), PostgreSQL может похвастаться поддержкой uuid, денежного, перечисляемого, геометрического, бинарного типов, сетевых адресов, битовых строк, текстового поиска, xml, json, массивов, композитных типов и диапазонов, а также некоторых внутренних типов для идентификации объектов и местоположения логов. Справедливости ради стоит сказать, что MySQL, MariaDB и Firebird тоже имеют некоторые из этих типов данных, но только Постгрес поддерживает их все.

Давайте рассмотрим подробнее некоторые из них:

Сетевые адреса

PostgreSQL обеспечивает хранение разных типов сетевых адресов. Тип данных CIDR (бесклассовая маршрутизация интернет домена, Classless Internet Domain Routing) следует соглашению для сетевых адресов IPv4 и IPv6. Вот несколько примеров:

192.168.100.128/25
10.1.2.3/32
2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128
::ffff:1.2.3.0/128

Также для хранения сетевых адресов доступен тип данных INET, используемый для IPv4 и IPv6 хостов, где подсети являются необязательными. Тип данных MACADDR может использоваться для хранения MAC-адресов для идентификации оборудования, таких как 08-00-2b-01-02-03.

У MySQL и MariaDB тоже есть INET функции для конвертации сетевых адресов, но они не предоставляют типы данных для внутреннего хранения сетевых адресов. У Firebird тоже нет типов для хранения сетевых адресов.

Многомерные массивы

Поскольку Постгрес - это объектно-реляционная база данных, массивы значений могут храниться для большинства существующих типов данных. Сделать это можно путём добавления квадратных скобок к спецификации типа данных для столбца или с помощью выражения ARRAY. Размер массива может быть задан, но это необязательно. Давайте рассмотрим меню праздничного пикника для демонстрации использования массивов:

Создаем таблицу, у которой значения являются массивами CREATE TABLE holiday_picnic (holiday varchar(50) -- строковое значение sandwich text, -- массив side text , -- многомерный массив dessert text ARRAY, -- массив beverage text ARRAY -- массив из 4-х элементов); -- вставляем значения массивов в таблицу INSERT INTO holiday_picnic VALUES ("Labor Day", "{"roast beef","veggie","turkey"}", "{ {"potato salad","green salad","macaroni salad"}, {"chips","crackers"} }", "{"fruit cocktail","berry pie","ice cream"}", "{"soda","juice","beer","water"}");
MySQL, MariaDB, и Firebird так не умеют. Чтобы хранить такие массивы значений в традиционных реляционных базах данных, придется использовать обходной путь и создавать отдельную таблицу со строками для каждого из значений массива.

Геометрические данные

Геоданные быстро становятся основным требованием для многих приложений. PostgreSQL уже давно поддерживает множество геометрических типов данных, таких как точки, линии, круги и многоугольники. Один из этих типов – PATH, он состоит из множества последовательно расположенных точек и может быть открытым (начальная и конечная точки не связаны) или закрытым (начальная и конечная точки связаны). Давайте рассмотрим в качестве примера туристическую тропу. В данном случае туристическая тропа - это петля, поэтому начальная и конечная точки связаны, и, значит, мой путь является закрытым. Круглые скобки вокруг набора координат указывают на закрытый путь, а квадратные - на открытый.

Создаем таблицу для хранения троп CREATE TABLE trails (trail_name varchar(250), trail_path path); -- вставляем тропу в таблицу, -- для которой маршрут определяется координатами в формате широта-долгота INSERT INTO trails VALUES ("Dool Trail - Creeping Forest Trail Loop", ((37.172,-122.22261666667), (37.171616666667,-122.22385), (37.1735,-122.2236), (37.175416666667,-122.223), (37.1758,-122.22378333333), (37.179466666667,-122.22866666667), (37.18395,-122.22675), (37.180783333333,-122.22466666667), (37.176116666667,-122.2222), (37.1753,-122.22293333333), (37.173116666667,-122.22281666667)));
Расширение PostGIS для PostgreSQL дополняет существующие свойства геометрических данных вспомогательными пространственными типами, функциями, операторами и индексами. Оно обеспечивает поддержку местоположения и поддерживает как растровые, так и векторные данные. Оно также обеспечивает совместимость с множеством сторонних геопространственных инструментов (защищённых авторским правом и с открытым исходным кодом) для отображения, отрисовки и работы с данными.

Заметьте, что в MySQL 5.7.8 и в MariaDB, начиная с версии 5.3.3, были добавлены расширения типов данных для поддержки стандарта географической информации OpenGIS. Эта версия MySQL и последующие версии MariaDB предлагают хранение типов данных, аналогичное штатным геоданным Постгреса. Тем не менее, в MySQL и MariaDB значения данных сначала должны быть сконвертированы в геометрический формат простыми командами перед тем, как будут вставлены в таблицу. Firebird на данный момент не поддерживает геометрические типы данных.

Поддержка JSON

Поддержка JSON в PostgreSQL позволяет вам перейти к хранению schema-less данных в SQL базе данных. Это может быть полезно, когда структура данных требует определённой гибкости: например, если в процессе разработки структура всё ещё меняется или неизвестно, какие поля будет содержать объект данных.

Тип данных JSON обеспечивает проверку корректности JSON, который позволяет использовать специализированные JSON операторы и функции, встроенные в Постгрес для выполнения запросов и манипулирования данными. Также доступен тип JSONB - двоичная разновидность формата JSON, у которой пробелы удаляются, сортировка объектов не сохраняется, вместо этого они хранятся наиболее оптимальным образом, и сохраняется только последнее значение для ключей-дубликатов. JSONB обычно является предпочтительным форматом, поскольку требует меньше места для объектов, может быть проиндексирован и обрабатывается быстрее, так как не требует повторного синтаксического анализа.

В MySQL 5.7.8 и MariaDB 10.0.1 была добавлена поддержка встроенных объектов JSON. Но, хотя существует множество функций и операторов для JSON, которые теперь доступны в этих базах данных, они не индексируются так, как JSONB в PostgreSQL. Firebird пока что не присоединился к тренду и поддерживает объекты JSON только в виде текста.

Создание нового типа

Если вдруг так случится, что обширного списка типов данных Постгреса вам окажется недостаточно, вы можете использовать команду CREATE TYPE, чтобы создать новые типы данных, такие как составной, перечисляемый, диапазон и базовый. Рассмотрим пример создания и отправки запросов нового составного типа:

Создаем новый составной тип "wine" CREATE TYPE wine AS (wine_vineyard varchar(50), wine_type varchar(50), wine_year int); -- создаем таблицу, которая использует составной тип "wine" CREATE TABLE pairings (menu_entree varchar(50), wine_pairing wine); -- вставляем данные в таблицу при помощи выражения ROW INSERT INTO pairings VALUES ("Lobster Tail",ROW("Stag""s Leap","Chardonnay", 2012)), ("Elk Medallions",ROW("Rombauer","Cabernet Sauvignon",2012)); /* выборка из таблицы с использованием имени колонки (используйте скобки, отделяемые точкой от имени поля в составном типе) */ SELECT (wine_pairing).wine_vineyard, (wine_pairing).wine_type FROM pairings WHERE menu_entree = "Elk Medallions";
Поскольку они не являются объектно-реляционными, MySQL, MariaDB и Firebird не предоставляют такую мощную функциональность.

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

PostgreSQL может обрабатывать много данных. Текущие опубликованные ограничения перечислены ниже:

В Compose [прим. пер.: организация, в которой трудится автор оригинальной статьи] мы автоматически масштабируем вашу инсталляцию, чтобы вам не приходилось волноваться о росте количества данных. Но, как известно любому администратору баз данных, стоит с опаской относиться к слишком большим и неограниченным возможностям. Мы советуем руководствоваться здравым смыслом при создании таблиц и добавлении индексов.

Для сравнения, MySQL и MariaDB печально известны ограничением размера строк в 65 535 байт. Firebird также предлагает всего лишь 64Кб в качестве максимального размера строки. Обычно объём данных ограничивается максимальным размером файлов операционной системы. Поскольку PostgreSQL умеет хранить табличные данные в множестве файлов меньшего размера, он может обойти это ограничение. Но стоит отметить, что слишком большое количество файлов может негативно сказаться на производительности. MySQL и MariaDB поддерживают большее количество столбцов в таблице (до 4,096 в зависимости от типа данных) и большие индивидуальные размеры таблицы, чем PostgreSQL, но необходимость превысить существующие ограничения Постгреса возникает лишь в крайне редких случаях.

Целостность данных

Постгрес стремится соответствовать стандарту ANSI-SQL:2008, отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность) и известен своей ссылочной и транзакционной целостностью. Первичные ключи, ограничивающие и каскадные внешние ключи, уникальные ограничения, ограничения NOT NULL, проверочные ограничения и другие функции обеспечения целостности данных дают уверенность, что только корректные данные будут сохранены.

MySQL и MariaDB больше работают на то, чтобы соответствовать стандарту SQL с движками таблиц InnoDB/XtraDB. Теперь они предлагают опцию STRICT с использованием режимов SQL, которая устанавливает проверки корректности используемых данных. Несмотря на это, в зависимости от того, какой режим вы используете, недостоверные и даже урезанные без вашего ведома данные могут быть вставлены или созданы при обновлении. Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения. Кроме того, у них существует множество особенностей в отношении ограничений ссылочной целостности по внешним ключам. В дополнение к вышесказанному, целостность данных может существенно пострадать в зависимости от выбранного движка хранения. MySQL (и fork MariaDB) не делают секрета из того, что променяли целостность и соответствие стандартам на скорость и эффективность.

Подводя итоги

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

Если вам кажется, что PostgreSQL не соответствует вашим потребностям, или вы предпочитаете “стрелять от бедра”, тогда вам стоит обратить внимание на NoSQL базы данных, которые мы предлагаем в Compose, или подумать о других SQL базах данных, которые мы упоминали. У каждой из них есть свои преимущества. Compose твёрдо уверен, что очень важно выбрать правильную базу данных для конкретной задачи… иногда это означает, что нужно выбрать несколько баз данных!

Хотите больше Постгреса?