postgresql для чего используется

Возможности PostgreSQL для тех, кто перешел с MySQL

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

Мы рады сообщить, что подготовка к PG Day’17 Russia идет полным ходом! Мы опубликовали полное расписание предстоящего мероприятия. Приглашаем всех желающих прийти и похоливарить с Антоном лично

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

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

Но сплошь и рядом складывается такая ситуация, когда какой-нибудь условный программист Вася вчера писал на MySQL, а сегодня вдруг начал писать на Посгресе. Как он будет писать? Да в целом также, как и раньше, используя лишь самый минимальный набор возможностей новой базы. Практика показывает, что проходят годы, прежде чем СУБД начинает использоваться более менее полноценно.

Не холивар

Сразу disclaimer: это не статья «мускуль vs посгрес». Переходить на посгрес или нет — ваше дело. Uber, к примеру, перешел обратно на MySQL по своим каким-то причинам.

Надо отдать должное Oracle, они явно двигают MySQL в правильном направлении. В 5.7 сделали strict mode по умолчанию. В восьмой версии обещают CTE и оконные функции, а также избавление от движка MyISAM в системных таблицах. Т.е. видно, что в базу вкладываются ресурсы, и хотелки юзеров исследуются очень серьёзно.

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

Встроенные типы данных

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

Например, есть типы cidr, inet, macaddr для работы с ip адресами.

Или например, время с таймзоной (timestamptz), интервал времени и т.д.

Когда я готовил этот слайд, я решил из любопытства посмотреть, а какое смещение времени относительно UTC было 100 лет назад, в 1917 году:

Т.е. москвичи жили по времени UTC+02:31:19.

Кроме перечисленных, есть и другие встроенные типы данных: UUID, JSONB, XML, битовые строки и т.д.

Тип array

Отдельно надо рассмотреть тип «array». Массивы давно и хорошо интегрированы в PostgreSQL. Многомерные массивы, слайсы, операторы пересечения, объединения и т.д. Существует множество функций для работы с массивами.

Есть очень удобная функция, которая так и называется: array. В качестве аргумента подается некий SELECT-запрос, на выходе — результат запроса в виде массива.

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

Создаем собственные типы

Собственные типы можно создавать тремя способами. Во-первых, если вы знаете язык Си, то вы можете создать базовый тип, наравне с каким-нибудь int или varchar. Пример из мануала:

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

Второй способ — это композитный тип. Например, для хранения комплексных чисел:

И потом использовать это:

Третий вид типа, который вы можете создать — это доменный тип. Доменный тип — это просто алиас к существующему типу с другим именем, т.е. именем, соответствующим вашей бизнес-логике.

us_postal_code — это более семантично, чем некий абстрактный text или varchar.

Создаем собственные операторы

Можно делать свои операторы. Например, сложение комплексных чисел (сам тип complex мы определили выше):

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

Давайте сделаем какой-нибудь сферический в вакууме пример. Создадим типы RUR и USD, и правило для преобразования одного типа в другой. Так как я плохо знаю си, то для примера сделаем простой композитный тип:

Собственно, это всё, теперь можно использовать. Сколько там будет 100 баксов в рублях?

Результат будет таким:

Типы в расширениях PostgreSQL

Описаны правила индексирования. Например, тип ip4r (диапазон IP-адресов) можно проиндексировать индексом GIST по оператору && (и другим). Таким образом, можно сделать таблицу для поиска городов по IP.

Индексы

Partial indexes

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

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

Этот индекс будет хорошо работать на запросах select * from my_money where status = 2 и при этом занимать мало места.

Индексы по выражению

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

И потом такой запрос будет быстро работать:

Constraints

Помимо стандартных UNIQUE и NOT NULL, в базе можно делать еще и другие проверки целостности. В доменном типе можно прописать check:

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

Также check можно прописать в таблице:

Т.е. в имени должен быть хотя бы один символ, и не больше 300.

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

Таким образом, иногда композитный тип может быть предпочтительнее, чем jsonb, потому что в json вы можете напихать что угодно вообще.

Частичная уникальность и уникальность по выражению

В отличие от простой уникальности UNIQUE или PRIMARY KEY, в посгресе можно сделать уникальность среди определенного набора строк, заданного условием. Например, email должен быть уникальным среди неудаленных юзеров:

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

Constraint Exclude

Ключевое слово EXCLUDE позволяет делать так, что при вставке/обновлении строки, эта строка будет сравниваться с другими по заданному оператору. Например, таблица, содержащая непересекающиеся диапазоны IP (проверяется оператором пересечения && ):

Хранимые процедуры

Хранимые процедуры можно писать на SQL, pl/pgsql, javascript, (pl/v8), python и т.д. Например, можно на языке R обсчитать какую-то статистику и вернуть из нее график с результатом.
Это отдельная большая тема, советую поискать доклад Ивана Панченко на этот счет.

CTE (Common Table Expressions)

Это будет и в MySQL 8, но всё равно давайте кратко остановимся на этом.

CTE — это просто. Вы берете какой-то кусок запроса и выносите его отдельно под каким-то именем.

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

Например, если у вас 20 джойнов с подзапросами и группировками, планировщик запросов может не понять ваших намерений и план запроса будет неоптимальным. Тогда можно вынести часть запроса в cte-подзапрос, а остальное уже дофильтровать в основном запросе.

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

В CTE можно использовать не только SELECT-запросы, но и UPDATE.

Пример: обновить юзеров с возрастом > 20 лет, и в том же запросе выдать имена обновленных вместе с какой-нибудь там страной.

Но тут надо понимать, что иногда с помощью CTE можно хорошо выстрелить себе в ногу.
Такой запрос синтаксически верен, но по смыслу полный бред:

Кажется, что мы прибавили рубль, потом отняли рубль, и должно остаться всё как есть.

Но дело в том, что update1 и update2 при своем выполнении будут брать начальную версию таблицы, т.е. по сути получится так, что один update затрет изменения другого. Поэтому с update внутри CTE надо точно знать, что ты делаешь и зачем.

Оконные функции

Про оконные функции я уже когда-то подробно писал здесь: https://habrahabr.ru/post/268983/. Оконные функции тоже обещают в MySQL 8.

Разное

FILTER

К агрегатным функциям (например, COUNT или SUM), можно дописывать условие FILTER, т.е. агрегировать не все строки, а только ограниченные неким выражением:

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

\watch

Materialized View

Это как View, только закешированное (материализованное). Кеш можно обновлять с помощью команды REFRESH MATERIALIZED VIEW. Есть также ключевое слово CONCURRENTLY, чтобы Postgres не лочил при обновлении SELECT-запросы.

Listen / Notify

Я пока что не пробовал это в продакшене, поэтому не знаю, применимо ли это на практике (если кто использовал, поделитесь плиз опытом в комментариях). Суть в том, что можно подписаться на какое то событие, а также можно уведомить подписчиков, что событие произошло, передав при этом строку с доп. сведениями.

Механизм Foreign Data Wrappers позволяет использовать некоторые внешние данные, как простые таблицы. Т.е. к примеру, можно заджойнить постгресовую таблицу, мускульную таблицу, и csv файл.

Sequences

SEQUENCE — это посгресовый аналог MySQL-ного AUTO_INCREMENT. В отличие от MySQL, sequence может существовать отдельно от таблиц или наоборот, «тикать» сразу для нескольких таблиц. Можно задавать различные параметры, например, размер инкремента, зацикливание и проч.

Вместо выводов

Это верхушка айсберга, на самом деле. Есть еще куча нюансов, вообще никак не затронутых в статье, потому что на всё никакой статьи не хватит. По одним только хранимым процедурам можно написать книгу. Или посмотрите, к примеру, полный список sql-команд текущей версии: https://www.postgresql.org/docs/9.6/static/sql-commands.html

Главное, что я хотел показать в статье: несмотря на хайповость, PostgreSQL — очень старая СУБД, в которой очень много чего есть, и которая очень хорошо расширяется. Поэтому при переходе на нее с MySQL рекомендуется полистать мануал, почитать статьи и т.д.

Источник

Postgres расправляет плечи

С 6 по 7 февраля в бизнес-центре Digital October в Москве пройдёт конференция PGCONF.RUSSIA 2015, одним из организаторов которой я являюсь. PostgreSQL — одна из наиболее перспективных современных свободно распространяемых СУБД, активно развивающаяся и во многих случаях уже не уступающая флагману коммерческих СУБД Oracle, а в чем-то и превосходящая его. При этом что Postgres распространяется по очень свободной лицензии, близкой к BSD и MIT-лицензиям, позволяющей делать с ним что угодно — даже продавать от своего имени. Поэтому нет препятствий в создании на базе постгреса коммерческих СУБД и прикладных систем, и этим многие пользуются. Это, в свою очередь, дает возможность участвовать в разработке большему количеству людей, и активнее подпитываться новыми идеями. На страницах данного поста мы расскажем о том, как возникла и развивалась эта СУБД, каковы её сильные и слабые стороны, в том числе с точки зрения широкого распространения.

Что такое Postgres

В мире существует очень много систем управления базами данных. Самая известная, конечно, Oracle, сегодня это общепризнанная СУБД №1 в мире. Из свободно распространяемых СУБД наиболее известна и популярна MySQL. Однако в последние годы все больший интерес в мире вызывает PostgreSQL, свободно распространяемая объектно-реляционная система управления базами данных (ORDBMS), наиболее развитая из открытых СУБД. Рост запросов на миграцию с проприетарных систем на PostgreSQL доказывает, что он является реальной альтернативой коммерческим СУБД.

В чем причина роста популярности Postgres? Прежде всего, он очень тщательно продуман, гибок и за счет этого имеет ряд преимуществ.

Postgres был создан в 1986 профессором университета Калифорнии в Беркли Майклом Стоунбрейкером, как следующая ступень после СУБД Ingres. Основы его устройства и механизмы для обеспечения расширяемости были заложены уже тогда. Интересно, что в то время использование языка SQL еще не считалось обязательным для реляционных баз данных. И когда в 1996 году Postgres, уже научившийся языку SQL, стал свободно распространяемым продуктом, он стал назывался замысловатым словом PostgreSQL («постгр ́есквел»), но для удобства произношения старое название «постгрес» тоже сохранилось и используется.

В последние годы в PostgreSQL испытывает бурный расцвет, связанный с его проникновением на рынки промышленных решений. Поэтому в него целенаправленно добавляются возможности, необходимые для использования его в серьёзных проектах – репликация, средства для хранения неструктурированных данных, row level security. Производительность с каждой новой версией возрастает.

За рубежом к PostgreSQL проявляют большой интерес. Многие компании оказывают коммерческие услуги по поддержке и кастомизации — в частности, этим занимаются американская компания EnterpriseDB, британская The Second Quandrant и французская Dalibo. К слову, директор последней Жан-Поль Аргудо в своем докладе на PGCONF.RUSSIA 2015 поделится опытом оказания коммерческих услуг в отношении свободного распространяемого продукта и поддержки правительственных учреждений Франции в миграции с Oracle на Рostgres. Также на PGCONF.RUSSIA 2015 будут выступать довольно известные разработчики PostgreSQL из Японии и Китая, которые расскажут о причинах высокой его популярности в этих странах.

Важнейшие ТТХ PostgreSQL

Postgres в России

На волне сегодняшней тенденции к импортозамещению на Postgres стали обращать внимание многие государственные и окологосударственные структуры, которые сегодня пользуются СУБД Oracle и другими проприетарными системами. Конкретные шаги по миграции предпринимаются рядом министерств и госкорпораций. Кстати, в Европе такая же картина, как у нас: там тоже хотят, как ни странно, «слезать» с проприетарных решений. Причем хотят очень давно. Но многие свободно распространяемые решения еще только подходят к такому уровню качества, чтобы на них можно было переходить. РostgreSQL — одна из наиболее серьезных систем.

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

Благодаря индексной поддержке работы с пространственными данными PostgreSQL очень широко используется в геоинформационных системах. В частности, на нем сделаны такие известные проекты, как OpenStreetMap и российский 2ГИС. Кстати, Postgres лежит и в основе площадки объявлений Avito.

К сожалению, во многих случаях открытость системы и отсутствие явной компании-разработчика мешает активному распространению. Ведь, несмотря на свою бесплатность, как и любая другая сложная система, Postgres имеет ненулевую стоимость владения, требуя определенных затрат на разработку и обслуживание. Нужны квалифицированные и компетентные специалисты. И, если в случае с той же Oracle или Microsoft есть формальная система сертификации, то у Рostgres такой системы нет. Поэтому организации и государственные структуры, которые привыкли или вынуждены работать строго формально, не понимают, кого им брать на работу. Ну хорошо, поставят они Рostgres. А где они возьмут сертифицированных инженеров? В России их формально нет. Поэтому сейчас в воздухе витает идея, что российскому сообществу разработчиков необходимо приобрести или создать некую формальную структуру, которая будет заниматься сертификацией, обучением и продвижением Рostgres в России. Конечно, есть частные фирмы, занимающиеся обучением работе с Postgres. Но для того, чтобы государство признавало выдаваемые ими сертификаты, требуется поддержка на достаточно высоком уровне. Нужна мощная поддержка со стороны потенциальных клиентов, нужна политическая воля, пиар. Возможно, в будущем это будет реализовано.

Кому можно порекомендовать Postgres

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

Postgres можно порекомендовать для тех проектов, где важна высокая надежность работы, возможность без остановки системы обновлять конфигурацию самой базы, хранимых процедур. В новых версиях Рostgres можно будет (пока с помощью хитроумного DBA) даже обновлять версию самого постгреса без остановки сервиса.

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

Зачем мы организуем PGCONF.RUSSIA 2015

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

Мы хотим способствовать формированию сообщества и рынка, собрать вместе разные заинтересованные стороны. Тех, кто разрабатывает сам Рostgres, кто разрабатывает на нем, кто использует его. Ведь если будет развиваться рынок услуг, связанных с Рostgres, то будет развиваться и сам Рostgres.

Вообще, такие конференции — одна из форм самоорганизации мирового сообщества разработчиков и пользователей. Есть серия международных конференций, которые проходят в Канаде; в США проводятся американские конференции; в различных городах Европы — ежегодные общеевропейские. В Китае и Японии тоже проводят свои национальные конференции по Postgres. Европейские конференции собирают обычно по 200-300 человек. Первая крупная российская конференция была организована энтузиастами прошлым летом в Санкт-Петербурге, ее посетили около 250 человек. Примерно столько же мы ожидаем и на PGCONF.RUSSIA 2015.

В России, в отличие от многих других стран, есть свои члены международной команды разработки ядра PostgreSQL, то есть ключевые, фундаментальные разработчики Рostgres. Один из них, Федор Сигаев, работает у нас в Mail.Ru Group. В свое время он создал важные инструменты для Рostgres, которые позволили работать с массивами и неструктурированными данными. Вместе с Олегом Бартуновым — другим российским разработчиком ядра — он создавал модуль полнотекстового поиска.

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

Расширяемость PostgreSQL — проблемы и перспективы

Исторически Postgres создавался как база данных, которая не имеет жестко зашитого набора правил, жестко зашитых типов. Она позволяет добавлять свои типы, создавать свои функции и т.д. Конечно, не все удавалось сделать сразу, многие заложенные идеи все еще развиваются. Скажем, только в середине 2000-х Postgres наконец избавился от «знания» семантического значения знаков операций. Затем это знание было обобщено, и теперь есть возможность объяснять ядру Postgres, как именно с помощью индекса ускорять поиск по выражениям с любыми знаками операций. Это дало возможность с помощью индексов специального типа ускорить поиск по вхождению элемента в множество (массив), по пересечению множеств, и затем — полнотекстовый поиск.

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

Итак, Postgres позволяет создавать свои типы и функции. В докладе Федор расскажет о том, как это лучше всего делать. Проще всего создать новый тип: для этого достаточно написать две функции, которые превращают простую текстовую строку во внутреннее представление и обратно, и запустить эти функции в жизнь специальной SQL-командой. С этим Postgres уже может жить и реплицироваться. Но, чтобы получить какой-то толк от созданного типа данных, вам потребуется определить над ними какие-то функции и операции. Если нужна индексная поддержка поиска по какой-то операции — тоже потребуется написать несколько функций.

Существуют операции над типами данных, которые являются не слишком тривиальными, такие как близость (похожесть) двух строк. Например, задача поиска — чтобы по фразе «черная дыра» в базе нашлась и «дыра черная». На самом деле, не так просто устранить чередование терминов без потери смысла, и при этом находить нужные строчки (а ведь еще бывают опечатки!). Здесь не вводятся новые типы; вместо этого сравниваются две строки, учитывая меру похожести Левенштейна. Те, кто пробовал с ней работать, знают, что поиск по ней работает только полным перебором. Поэтому в свое время был создан модуль pg_trgm, который представляет строку в виде множества триграмм, индексировать эти множества и искать достаточно эффективно.

Также в докладе будет рассказано о возможности использования этого модуля для индексного поиска по некоторым подмножествам регулярных выражений — о том, как можно сделать что-то совершенно необычное со строками, используя уже существующие возможности Postgres. Отдельно будет упомянуто о foreign data wrappers (fdw), обертках над источниками данных, которые не являются самим Postgres. Сейчас этот функционал развился настолько, что поддерживаются даже транзакции.

Ахиллесова пята Postgres — это, как ни странно, подключение новых типов индексов. Операция эта довольно редкая, но заложенная в ней гибкость реализована еще не полностью. В целом, Postgres и без того богат индексами: в нем есть BTree, Rtree, обратный индекс (GIN), обобщенный индекс (GIST), пространственный обобщенный индекс (SP-GIST). Однако иногда возникают задачи, которые не ложатся в традиционную базу данных, например, Блумовские фильтры. На первый взгляд, достаточно создать новый тип индекса и вставить в системный каталог в несколько табличек.

Проблема в том, что такие подключаемые индексы не имеют доступа к WAL (write ahead log), который лежит в основе восстановления после сбоев и репликации. В результате этот индекс не реплицируется вообще, потому что репликация идет через WAL. Для того чтобы новый индекс писался в WAL, необходимо патчить ядро системы, одними расширениями тут не обойтись. Но мы ожидаем, что в версии 9.6 будет реализована возможность подключения индексов с использованием WAL.

Также в своем докладе Федор коснется темы exclusive constraints. Все знают о unique constraints, использующихся, если какое-то поле должно быть уникальным в таблице. Но, например, представьте себе расписание, в котором для каждой лекции указана аудитория, время и длительность. Арендовать аудиторию можно на три часа, а можно на 15 минут. Требуется, чтобы лекции не пересекались в пространстве-времени. Для этого unique constraints, естественно, не подходят. Тут помогут exclusive constraints, чтобы можно было гарантировать, что эти два временных интервала в одной аудитории не пересекаются.

Источник

Обзор СУБД PostgreSQL: в чем преимущества и секрет успеха?

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

История PostgreSQL

СУБД PostgreSQL начиналась как исследовательский проект в Калифорний­ском университете в Беркли. С 1996 года она разрабатывалась сообществом, и до сих пор в разработке PostgreSQL принимают активное участие сообщества и университеты. Перечислим основные исторические вехи:

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

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

PostgreSQL обладает многими возможностями, которые привлекают разработ­чиков, администраторов, архитекторов и компании.

Преимущества PostgreSQL с точки зрения бизнеса

Преимущества PostgreSQL с точки зрения пользователя

PostgreSQL весьма привлекательна для разработчиков, администраторов и ар­хитекторов. Развитая функциональность позволяет гибко решать различные задачи. Перечислим некоторые ее преимущества с точки зрения разработчика: О новые версии выходят ежегодно; к настоящему моменту, начиная с вер­сии 6.0, было выпущено 24 основные версии;

Применения PostgreSQL

PostgreSQL применяется в различных ситуациях. Основные области примене­ния PostgreSQL можно отнести к двум категориям:

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

Истории успеха

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

Ответвления

Ответвлением называется независимый программный проект, основанный на каком-то другом проекте. От PostgreSQL существует более 20 ответвлений; расширяемый API этому весьма способствует. На протяжении многих лет раз­личные группы создавали ответвления и затем включали результаты своей работы в PostgreSQL.

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

В PostgreSQL используется клиент-серверная архитектура, когда клиент и сер­вер могут находиться в различных узлах. Обмен данными между клиентом и сервером обычно ведется по протоколу TCP/IP или через Linux-сокеты. Сер­вер PostgreSQL может одновременно обрабатывать несколько подключений клиентов. Типичная программа, работающая с PostgreSQL, состоит из следую­щих процессов операционной системы:

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

Почти все компоненты PostgreSQL, включая регистратор, планировщик, анализатор статистики и диспетчер памяти, допускают конфигурирование. Конфигурация PostgreSQL выбирается в соответствии с характером приложе­ния: OLAP или OLTP.

Сообщество PostgreSQL

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

Сообщество PostgreSQL поддерживает службу агрегирования блогов Planet PostgreSQL. Некоторые разработчики и компании с ее помощью делятся своими знаниями и опытом.

Источник