что такое postgresql и для чего он нужен

Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расширение 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, чтобы создать новые типы данных, такие как составной, перечисляемый, диапазон и базовый. Рассмотрим пример создания и отправки запросов нового составного типа:

Поскольку они не являются объектно-реляционными, 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 твёрдо уверен, что очень важно выбрать правильную базу данных для конкретной задачи… иногда это означает, что нужно выбрать несколько баз данных!

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

Источник

Что такое postgresql и для чего он нужен

История развития PostgreSQL

Краткую историю PostgreSQL можно прочитать в документации, распространяемой с дистрибутивом или на сайте. Также, есть перевод на русский язык. Из нее следует, что современный проект PostgreSQL ведет происхождение из проекта POSTGRES, который разрабатывался под руководством Майкла Стоунбрейкера (Michael Stonebraker), профессора Калифорнийского университета в Беркли (UCB). Мне захотелось несколько подробнее показать взаимосвязи родословных баз данных, чтобы лучше понять место PostgreSQL среди основных игроков современного рынка баз данных.

Я попытался графически ( большая версия картинки откроется в новом окне) отобразить все наиболее заметные RDBMS и связи между ними и приблизительно привел даты их создания и конца. Пересечение объектов означает поглощение, при этом поглощаемый объект более бледен и не окантован. Знак доллара означает, что база данных является коммерческой. При этом, я основывался на информации, доступной в интернете, в частности в Wikipedia, в научных статьях, которые я читал и комментариях непосредственных пользователей БД, которые я получил после публикации этой картинки в интернете.

«System R» сыграла большую роль в развитии реляционных баз данных, создании языка SQL (изначально SEQUEL, но из-за проблем с уже существующей торговой маркой пришлось выкинуть все гласные буквы). Из «System R» развилась SQL/DS и DB2. На самом деле, в IBM было еще несколько проектов, но они были чисто внутренними. Подробнее об этой ветви можно прочитать в весьма поучительном документе «The 1995 SQL Reunion: People, Projects, and Politics», русский перевод которого доступен по адресу www.citforum.ru/database/digest/sql1.shtml.

INGRES (или Ingres89), в отличие от «System R», вполне в духе Беркли развивалась как открытая база данных, коды которой распространялись на лентах практически бесплатно (оплачивались почтовые расходы и стоимость ленты). К 1980 году было распространено порядка 1000 копий. Название расшифровывается как «INteractive Graphics Retrieval System» и совершенно случайно связано с французским художником Jean Auguste Dominique Ingres. Отличительной особенностью этой системы являлось то, что она разрабатывалась для операционной системы UNIX, которая работала на распространенных тогда PDP 11, что и предопределило ее популярность, в то время как «System R» работала только на больших и дорогих mainframe. Был разработан язык запросов QUEL, который, как писал Стоунбрейкер, похож на SEQUEL в том отношении, что программист свободен от знания о структуре данных и алгоритмах, что способствует значительной степени независимости от данных. Доступность INGRES и очень либеральная лицензия BSD, а также творческая деятельность, способствовали появлению большого количества реляционных баз данных, как показано на рисунке.

Стоунбрейкер лично способствовал их появлению, так он конце 70-х он организовал компанию Ingres Corporation (как он сам объясняет, ему пришлось на это пойти, так как Аризонский университет, потребовал поддержки), которая выпустила коммерческую версию Ingres, в 1994 году она была куплена CA (Computer Associates) и которая в 2004 году стала открытой как Ingres r3.

«NonStop SQL» компании Tandem Computers являлась модифицированной версией Ingres, которая эффективно работала на параллельных компьютерах и с распределенными данными. Она умела выполнять запросы параллельно и масштабировалась почти линейно с количеством процессоров. Ее авторами были выпускники из Беркли. Впоследствии, Tandem Computers была куплена компанией Compaq (2000 г.), а затем компанией HP.

Informix тоже возник из Ingres, но на это раз людьми не из Беркли, хотя Стоунбрейкер все-таки поработал в ней CEO после того, как Informix купила в 1995 году компанию Ilustra, чтобы прибавить себе объектно-реляционности и расширяемости (DataBlade), которую организовал все тот же Майкл Стоунбрейкер как результат коммерциализации Postgres в 1992 году. В 2001 году она была куплена IBM, которая приобретала немалое количество пользователей Informix и технологию. Таким образом, DB2 также приобрела немного объектно-реляционности.

Проект Postgres возник как результат осмысления ошибок Ingres и желания преодолеть ограниченность типов данных, за счет возможности определения новых типов данных. Работа над проектом началась в 1985 и в период 1985-1988 было опубликовано несколько статей, описывающих модель данных, язык запросов POSTQUEL, и хранилище Postgres.

Еще при проектировании оригинальной версии POSTGRES основное внимание было уделено расширяемости и объектно-ориентированным возможностям. Уже тогда было ясна необходимость расширения функциональности DMBS от управления данными (data management) в сторону управления объектами (object management) и знаниями (knowledge management). При этом объектная функциональность позволит эффективно хранить и манипулировать нетрадиционными типами данных, а управление знаниями позволяет хранить и обеспечивать выполнения коллекции правил (rules), которые несут семантику приложения. Стоунбрейкер так и определил основную задачу POSTGRES как «обеспечить поддержку приложений, которые требуют службы управления данными, объектами и знаниями«.

На сегодняшний день выпущена версия PostgreSQL v8 (19 января 2005 года), которая является значительным событием в мире баз данных, так как количество новых возможностей добавленных в этой версии, позволяет говорить о возникновении интереса крупного бизнеса как в использовании, так и его продвижении. Так, крупнейшая компания в мире, Fujitsu поддержала работы над версией 8, выпустила коммерческий модуль Extended Storage Management. Либеральная BSD-лицензия позволяет коммерческим компаниям выпускать свои версии PostgreSQL под своим именем и осуществлять коммерческую поддержку. Например, компания Pervasive объявила о выпуске Pervasive Postgres.

PostgreSQL поддерживается на всех современных Unix системах (34 платформы), включая наиболее распространенные, такие как Linux, FreeBSD, NetBSD, OpenBSD, SunOS, Solaris, DUX, а также под Mac OS X. Начиная с версии 8.X PostgreSQL работает в «native» режиме под MS Windows NT, Win2000, WinXP, Win2003. Известно, что есть успешные попытки работать с PostgreSQL под Novell Netware 6 и OS2.

Основные возможности и функциональность

Дистрибутив PostgreSQL в поддиректории contrib/ содержит большое количество (около 80) так называемых контриб-модулей, реализующих разнообразную дополнительную функциональность, такую как, полнотекстовый поиск, работа с xml, функции математической статистики, поиск с ошибками, криптографические модули и т.д. Также, есть утилиты, облегчающие миграцию с mysql, oracle, для административных работ.

Некоторые ограничения PostgreSQL

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

За основу взяты данные из Wikipedia

Что ожидается в будущих версиях

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

Цикл разработки

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

Структура

Где используется

Сообщество

Поддержка

Небольшая статистика списков рассылок PostgreSQL по данным www.pgsql.ru на 1 апреля 2005 года.

Разработка

Заключение

Благодарности

Текст написан Олегом Бартуновым в 2005 году, поправки и комментарии приветствуются.

Источник

Профессиональный Postgres

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. Доклад Олега Бартунова на тему «Профессиональный Postgres» открывал пленарную часть конференции. В нем раскрыта история СУБД Postgres, российский вклад в разработку, особенности архитектуры.

Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части 1 и 2.

Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.

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

Так получилось, что я использую и занимаюсь Postgres не урывками, а непрерывно с 1995-го года по сегодняшний день. Вся его история прошла на моих глазах, я участник основных событий.

История

На этом слайде я кратко обозначил те проекты, в которых принимал участие. Многие из них вам знакомы. А историю Postgres начну сразу с картинки, которую я нарисовал много-много лет назад и потом ее только дорисовывал — число версий всё увеличивается и увеличивается. Она отражает эволюцию реляционных баз данных. Слева, если кто не знает, это Майкл Стоунбрейкер, которого называют отцом Postgres. Внизу наши первые «ядерные» разработчики. Человек сидящий справа — это Вадим Михеев из Красноярска, он был одним из первых core-разработчиков.

Начну рассказ о реляционной модели с IBM, которая внесла гигантский вклад в индустрию. Именно в IBM работал Эдгар Кодд, из ее недр появилась первая white paper по IBM System R — это была первая реляционная база. Майк Стоунбрейкер работал в то время в Бёркли. Он прочитал эту статью и вместе со своими ребятами загорелся: надо сделать базу данных.

В те годы — в начале 70-х годов — как вы подозреваете, компьютеров было не много. На всё отделение Computer science университета Бёркли была одна PDP-11, и все студенты и преподаватели дрались за машинное время. В основном эта машина использовалась для расчетов. Я сам так работал, когда был молодым: отдаешь оператору задачу, он ее запускает. Но студенты и разработчики хотели интерактивной работы. Это была наша мечта — сидеть за пультом, вводить программы, отлаживать их. И когда Майк Стоунбрейкер со своими приятелями сделали первую базу, они назвали ее Ingres — INteractive Grafic REtrieval System. Люди не понимали: почему interactive? А это просто реализовалась мечта ее разработчиков. У них был консольный клиент, с помощью которого можно было работать с Ingres-ом. Он дал очень много нашей индустрии. Вы видите, сколько там стрелочек от Ingres? Это те базы данных, на которые он повлиял, которые шарили его код. У Майкла Стоунбрейкера было очень много учеников-разработчиков, которые ушли и разработали потом Sybase и MS SQL, NonStop SQL, Illustra, Informix.

Когда Ingres развился настолько, что стал интересным с коммерческой точки зрения, образовалась компания Illustra (это был 1992-й год), и код СУБД Illustra был куплен компанией Informix, которая была позже съедена IBM, и таким образом этот код ушел в DB2. Но что заинтересовало IBM в Ingres? В первую очередь расширяемость — те революционные идеи, которые Майкл Стоунбрейкер заложил с самого начала, думая о том, что база данных должна быть готова к решению любых бизнес-задач. А для этого нужно, чтобы в базу можно было добавить свои типы данных, access-методы и функции. Сейчас нам, постгресистам, это кажется естественным. В те годы это была революция. Именно со времен Ingres и Postgres эти фичи, эта функциональность стали де-факто стандартом для всех реляционных баз данных. Сейчас все базы данных имеют пользовательские функции, а когда Стоунбрейкер писал, что пользовательские функции нужны, компания Oracle, например, кричала о том, что это опасно, и что так делать нельзя потому, что пользователи могут навредить данным. Сейчас мы видим, что пользовательские функции существуют во всех базах данных, что можно делать свои агрегаты и типы данных.

Postgres развивался как академическая разработка, а это значит: есть профессор, у него есть грант на разработку, студенты и аспиранты, которые с ним работают. Серьезную базу, готовую для продакшн, так сделать нельзя. Тем не менее в последнюю версию из Бёркли — Postgres95 — уже был добавлен язык SQL. Студенты-разработчики в это время уже стали работать в компании Illustra, делали Informix и потеряли интерес к проекту. Они сказали: у нас есть Postgres95, забирайте его, кому нужно! Я это всё прекрасно помню потому, что сам был одним из тех, кто получил это письмо: был mailing list, а в нем меньше 400 человек подписчиков. Сообщество Postgres95 начиналось с этих 400 человек. Мы все дружно проголосовали за то, что берем этот проект. У нас нашелся энтузиаст, который поднял CVS-сервер, и мы перетащили всё в Панаму, так как серверы были там.

История PostgreSQL [дальше просто Postgres] начинается с версии 6.0, так как версии 1, 4, 5 были еще Postgres95. В 1997-м году 3 апреля появился наш логотип — слон. До этого у нас были разные животные. У меня на страничке, например, долгое время был гепард, намекавший, что Postgres очень быстрый. Потом в mailing list-е подняли вопрос: нашей большой базе данных нужно серьезное животное. И кто-то написал: давайте это будет слон. Все дружно проголосовали, потом наши ребята из Санкт-Петербурга нарисовали этот логотип. Изначально это был слон в алмазе — если поковыряетесь в машине времени, то увидите его. Слона выбрали потому, что у слонов очень хорошая память. Даже у Агаты Кристи есть такая повесть «Слоны могут помнить»: там слон очень мстительный, лет пятьдесят он помнил обиду, а потом задавил обидчика. Бриллиант потом откололи, рисунок векторизовали, и в результате получился вот этот слон. Так что это один из первых российских вкладов в Postgres.

Гепарда сменил Слоник в бриллианте:

Этапы развития Postgres

Первой задачей была стабилизация его работы. Сообщество переняло исходные коды академических разработчиков. Чего там только не было! Начали всё это перелопачивать, чтобы компилировалось прилично. Я выделил на этом слайде 1997-й год, версию 6.1 — в ней появилась интернационализация. Выделил не потому, что я сам это делал (это действительно был мой первый патч), а потому, что важный этап. Вы уже привыкли, что Postgres работает с любым языком, в любых локалях — во всем мире. А тогда он понимал только ASCII, то есть никаких 8-х битов, никаких европейских языков, никакого русского. Обнаружив это, я, следуя принципам open-source, просто взял и сделал поддержку локалей. И благодаря этой работе Postgres пошел в мир. После меня японец Тацуо Ишии [Tatsuo Ishii] сделал поддержку мультибайтных кодировок, и Postgres стал по-настоящему всемирным.

В 2005-м году была введена поддержка Windows. Я помню эти горячие споры, когда в mailing list-е это обсуждали. Все разработчики были нормальные люди, они работали под Unix. Вы вот сейчас хлопаете, и точно так же народ реагировал и тогда. И голосовал против. Это длилась годами. Более того, SRA Computers выпустили на несколько лет раньше свой Powergres — нативный порт на Windows. Но это было чисто японское изделие. Когда в 2005-м году в 8-й версии у нас появилась поддержка Windows, оказалось, что это сильный шаг: сообщество распухло. Появилось очень много людей и очень много глупых вопросов, но сообщество стало большое, мы схватили виндузовых пользователей.

В 2010-м году у нас появилась встроенная репликация. Это — боль. Я помню, сколько лет люди боролись за то, чтобы репликация была в Postgres. Сначала все говорили: нам не нужна репликация, это не дело базы данных, это дело внешних утилит. Если кто помнит, Slony сделал Ян Вик [Jan Wieck]. Кстати, «слони» тоже из русского языка пришли: Ян спросил меня, как будет по-русски «много слонов», и я ответил: «слоны». Вот он и сделал Slony. Эти слоны работали как логическая репликация на триггерах, настройка их была кошмаром — ветераны помнят. Более того, все долго слушали Тома Лейна [Tom Lane], который, помню, отчаянно кричал: зачем нам усложнять код репликацией, если это можно сделать снаружи базы? Но в результате встроенная репликация все-таки появилась. Это дало сразу колоссальное количество enterprise-пользователей потому, что до этого такие пользователи говорили: как нам вообще жить без репликации? Это невозможно!

В 2014-м году появился jsonb. Это работа моя, Федора Сигаева и Александра Короткова. И тоже народ кричал: зачем нам это нужно? Вообще, у нас уже был hstore, который мы сделали 2003-м году, а 2006-м он вошел в Postgres. Люди им прекрасно пользовались по всему миру, любили его, и, если в google набрать hstore, появлялось гигантское количество документов. Очень популярное расширение. И мы всячески пропагандировали идею неструктурированных данных в Postgres. С самого начала моей работы я как раз этим интересовался и, когда мы сделали jsonb, я получил массу писем с благодарностями и вопросами. А сообщество получило NoSQL-пользователей! До jsonb люди, зомбированые хайпом, шли в key-value базы данных. При этом они вынуждены были жертвовать целостностью, ACID-ностью. А мы им дали возможность, ничем не жертвуя, работать с их прекрасным json-ом. Комьюнити опять резко выросло.

В 2016-м году у нас появилось параллельное выполнение запросов. Если кто не знает, это, конечно, не для OLTP. Если у вас загруженная машина, то все ядра и так заняты. Параллельное выполнение запросов ценно для OLAP-пользователей. И они это оценили, то есть в сообщество начало прибывать и какое-то количество OLAP-юзеров.

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

В 2018-м году в 11-й версии мы получили JIT. Кто не знает, это Just In Time compiler: вы компилируете запросы, и это действительно может очень сильно ускорить выполнение. Это важно для ускорения медленных запросов потому, что быстрые запросы и так быстрые, а overhead на компиляцию все-таки существенный.

В 2019-м году самое основное, что мы ожидаем, это pluggable storage, API для того, чтобы разработчики могли создавать свои хранилища, один из примеров которых это zheap — хранилище, которое разрабатывает компания EnterpriseDB.

А вот и наша разработка: SQL/JSON. Я очень надеялся, что Саша Коротков закоммитит его до конференции, но там обнаружились какие-то проблемы, и мы теперь надеемся, что все-таки в этом году мы получим SQL/JSON. Люди ждут его уже два года [сейчас закоммичена значительная часть патча SQL/JSON: jsonpath, об этом написано подробно здесь].

Дальше я перехожу к слайду, который показывает: Postgres — это универсальная база данных. Эту картинку можно изучать часами, рассказать кучу историй о возникновении компаний, о поглощении, о смерти компаний. Я начну с 2000-го года. Один из первых форков Postgres — IBM-овская Netezza. Вы только представьте себе: «Голубой гигант» взял код Postgres и соорудил для поддержки своих BI базу для OLAP!

Вот форк TelegraphCQ: уже в 2000-м году на основе Postgres в Бёркли люди делали стриминговую базу данных. Если кто не знает, это база данных, которая не интересуется самими данными, а интересуются их агрегатами. Сейчас очень много задач, где не нужно знать каждое значение, допустим, температуру в какой-то точке, а нужно среднее значение в данном регионе. И в TelegraphCQ взяли эту идею (возникшую тоже в Бёркли), одну из самых передовых идей того времени, и разработали базу на основе Postgres. Дальше она эволюционировала, и в 2008-м году на ее основе выпущен был уже коммерческий продукт — база TruCQ, сейчас ее владелец Cisco.

Я забыл сказать, что на этой страничке не все форки, их в раза в два больше. Я выбрал наиболее важные и интересные, чтобы не загромождать картинку. На страничке в postgresql-вики перечислены все форки. Кто знает опенсорсную базу данных, у которой было бы столько форков? Таких баз нет.

Postgres отличается от других баз не только своей функциональностью, но и тем, что у нее
очень интересное сообщество, оно нормально принимает форки. В мире опенсорс принято считать: я сделал форк потому, что обиделся — вы меня не поддержали, вот я и решил вести собственную разработку. В постгресовом мире появление форка означает: какие то люди или какая-то компания решили сделать некоторый прототип и проверить придуманную ими функциональность, поэкспериментировать. А если повезет, то и сделать коммерческую базу, которую можно будет продавать клиентам, предоставлять им сервис и так далее. При этом, как правило, разработчики всех этих форков возвращают свои наработки и патчи в сообщество. Продукт нашей компании тоже форк, и понятно, что мы кучу патчей вернули обратно в сообщество. В последней, 11-й версии мы вернули сообществу более 100 патчей. Если посмотрите в ее release notes, то там будет 25 фамилий наших сотрудников. Это нормальное поведение в сообществе. Мы используем комьюнити-версию и делаем свой форк для того, чтобы проверять свои идеи или давать клиентам функциональность раньше, чем сообщество созреет для ее принятия. Форки в Postgres-сообществе очень даже приветствуются.

Известная Vertica возникла из C-Store — тоже выросла из Postgres. Некоторые люди утверждают, что в Vertica вообще не было исходников из Postgres, а была только поддержка постгресового протокола. Но тем не менее принято причислять ее к постгресовым форкам.

Greenplum. Сейчас вы можете скачать его и использовать как кластер. Он возник из Bizgres — массивно-параллельной базы данных. Потом она была куплена компанией Greenplum, стала и долго оставалась коммерческой. Но вы видите, что где-то в 2015-м году они поняли, что мир изменился: мир идет к открытым протоколам, к открытым сообществам, открытым базам данных. И открыли коды Greenplum. Сейчас они активно догоняют Postgres потому, что за это время отстали, конечно, очень сильно. Они отпочковались на 8.2, а сейчас говорят, что догнали 9.6.

Всеми нами любимый и нелюбимый Amazon. Вы знаете, как он возник. Это происходило на моих глазах. Была компания, был ParAccel с векторной обработкой, тоже на Postgres — продукт сообщества, открытый. В 2012-м году хитрый Amazon купил исходники и буквально через полгода объявил, что вот у нас в Amazon-е теперь есть RDS. Мы их тогда расспрашивали, они долго мялись, но потом все же выяснилось, что это Postgres. RDS до сих пор живет, и это один из самых популярных популярных сервисов Amazon-а, у них там порядка 7000 баз крутятся. Но они на этом не успокоились, и в 2010 появилась Amazon Aurora — Postgres 10 с переписанным сториджем, который вшит прямо в инфраструктуру Amazon, в их распределенное хранилище.

Посмотрите теперь на Teradata. Большая, старая добрая компания, которая занималась аналитикой, OLAP-ом. После «восьмерки» [PostgreSQL 8.0] возникла Aster Data.

Hadoop: у нас Postgres на Hadoop — HadoopDB. Через некоторое время она стала закрытой базой Hadapt, принадлежащей Teradata. Если вы увидите Hadapt, знайте, что внутри там Postgres.

Очень интересная судьба у Citus. Все знают, что это распределенный Postgres для онлайн-аналитики. Он не поддерживает транзакции. Citus Data был стартапом, а Citus была с закрытыми исходниками — отдельная база данных. Через некоторое время люди поняли, что лучше жить с сообществом, открыться. И они очень много сделали, чтобы стать просто расширением (extension) Postgres. Плюс они начали делать бизнес уже на предоставлении своих облачных услуг. Вы все уже знаете: здесь написано MS Citus потому, что Microsoft их купил, буквально недели две назад. Наверное, для того, чтобы поддержать Postgres на своей Azure, то есть Microsoft тоже играет в эти игры. У них на Azure крутится Postgres, и команда разработчиков Citus присоединилась к разработчикам MS.

Вообще в последнее время процессы покупки постгресовых компаний пошли интенсивно. Буквально после того, как Microsoft купил Citus, другая постгресовая компания — credativ — купила компанию OmniTI, чтобы усилить свое присутствие на рынке. Это две достаточно известные, добротные компании. А компания Amazon купила компанию OpenSCG. Постгресовый мир сейчас меняется, и я дальше покажу, почему такой большой интерес к Postgres.

Нашумевшая TimescaleDB тоже была отдельной базой данных, но и она теперь расширение: вы берете Postgres и устанавливаете timescaledb как расширение и получаете базу данных, которая рвет всяческие специализированные базы данных.

Еще имеется Postgres XL, имеются кластеры, которые развиваются.

Сюда вот, в 2015-й год, я поставил наш форк: Postgres Pro. У нас есть Postgres Pro Enterprise, имеется сертифицированная версия, мы поддерживаем «1С» из коробки и мы признанны компанией «1С». Если кто хочет попробовать Postgres Pro Enterprise, то можно бесплатно взять дистрибутив для тестирования, а если понадобится для работы, то вы можете его купить.

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

Видите, какая большая и интересная картина. Я даже не говорю про Yahoo! Everest с колоночным хранением, с петабайтами данных в Yahoo! — это был 2008-й год. Они даже спонсировали нашу конференцию в Канаде, приезжали туда, у меня где-то даже майка оттуда имеется 🙂

Есть еще PipelineDB. Она тоже начиналась как база с закрытыми исходниками, а сейчас это тоже просто расширение. Мы видим, что Citus, TimescaleDB и PipelineDB это как бы отдельные базы данных, но при этом они существуют как расширения, то есть вы берете стандартный Postgres и компилите расширение. PipelineDB это продолжение идеи стримовых баз данных. Хотите работать со стримами? Берёте Postgres, берёте PipelineDB и можно работать.

Кроме того, есть расширения, которые позволяют работать с GPU. Видите заголовок? Я показал, что есть экосистема, которая охватывает большое количество разных типов данных и нагрузок. Поэтому мы говорим, что Postgres это универсальная база данных.

Любимая народом база

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

Сейчас уже много расширений и много приложений, поэтому Postgres хорош как база данных, с которой начинается проект. Я всегда говорю стартаперам: ребята, не надо брать NoSQL базу данных. Я понимаю, что вам очень хочется, но начните с Postgres. Если вам не будет хватать чего-то, вы всегда сможете отцепить какой-нибудь сервис и отдать его специализированной базе данных. Кроме универсальности у Postgres есть еще одно достоинство: очень либеральная лицензия BSD, которая позволит делать что угодно со своей базой данных.

Всё, что вы видите на этом слайде, доступно благодаря тому, что Postgres — расширяемая база данных, причем эта расширяемость заложена сразу, прямо в архитектуре базы данных. Когда Майкл Стоунбрейкер писал про Postgres в своей первой статье о нём (она написана им в 1984-м году, здесь я цитирую статью 1987-го года), он уже говорил о расширяемости как важнейшей составляющей функциональности базы данных. И это, как говорится, уже проверено временем. Можно добавлять свои функции, свои типы данных, операторы, индексные доступы (то есть оптимизированные access-методы), вы можете писать ваши процедуры на очень большом количестве языков. У нас имеется Foreign Data Wrapper (FDW), то есть интерфейсы для работы с разными хранилищами, файлами, можно коннектиться к Oracle, MySQL и другим базам.

Хочу привести пример из собственного личного опыта. Я работал с Postgres и, когда мне чего-то не хватало в Postgres, мы с коллегами просто добавляли эту функциональность. Нам нужно было работать, например, с русским языком, и мы сделали 8-битную локаль. Это был проект Rambler. Кстати, он был тогда в топ-5. Rambler был первым крупным мировым проектом, который встал на Postgres. Массивы в Postgres были с самого начала, но они были такие, что с ними ничего нельзя было делать, это была просто текстовая строчка, в которой хранились массивы. Мы добавили операторы, сделали индексы, и сейчас массивы это неотъемлемая часть функциональности Postgres, и многие из вас используют их, совершенно не задумываясь о том, насколько они быстро работают — и это нормально. Раньше говорили, что массивы это уже не традиционная реляционная модель, не удовлетворяет классическим нормальным формам. Сейчас люди уже привыкли пользоваться массивами.

Когда нам понадобился полнотекстовый поиск, мы его сделали. Когда нам потребовалось хранить данные разной природы, мы сделали расширение hstore, и многие люди стали его использовать: он давал возможность строить гибкие схемы БД, чтобы можно было диплоиться раньше и быстрее. Мы сделали GIN-индекс, чтобы полнотекстовый поиск работал быстро. Сделали триграммы (pg_trgm). Сделали NoSQL. И всё это на моей памяти, всё из собственных нужд.

Расширяемость как раз и делает Postgres уникальной базой, универсальной базой данных, с которой можно начинать работать и не бояться, что вы останетесь без поддержки. Посмотрите, сколько у нас здесь людей — это уже рынок! Несмотря на то, что сейчас хайп — графовые базы данных, документные базы, time series и так далее, — посмотрите: большинство по-прежнему использует реляционные базы данных. Они доминируют, это 75% рынка баз данных, а остальные — это экзотические базы данных, мелочь по сравнению с реляционными.

Если вы посмотрите соотношение баз данных open source с коммерческими, то, по
данным DB-Engines, мы увидим, что количество баз open source почти равно числу коммерческих баз. И мы видим, что open source базы данных (синяя линия) растут, а коммерческие (красная) падают. Это направление развития всего ИТ-сообщества, направление к открытости. Сейчас, конечно, неприлично ссылаться на Gartner, но я всё равно скажу: они предсказывают, что к 2022-му году 70% будут использовать открытые базы данных и до 50% существующих систем будут мигрировать на open source.

Посмотрите на вот эту пузомерку: мы видим, что Postgres названа базой данных 2018-го года. В прошлом году она тоже была 1-ая по независимым оценкам экспертов DB-Engines. Рэнкинг показывает, что Postgres действительно впереди планеты всей. Он находится в абсолютном исчислении на 4-м месте, но посмотрите, как он растет. Уверенно, хорошо. На слайде это синяя линия. Остальные — MySQL, Oracle, MS SQL — либо балансирует на своем уровне, либо начинает загибаться.

Hacker news — все вы, наверное, читаете его или Y Combinator — там периодически проводят опросы, там компании публикуют свои вакансии, и с некоторых пор ведут статистику. Вы видите, что начиная где-то с 2014-го года, Postgres опережает всех. Был 1-м MySQL, но Postgres потихоньку вырос, и теперь среди всего хакерского сообщества (в хорошем смысле слова) он тоже превалирует и растет дальше.

В Stack Overflow тоже каждый год проводят опросы. По most used наш Postgres находится на хорошем, третьем месте. По most loved — на втором. Это любимая база данных. Redis это не реляционная база данных, а из реляционных Postgres самая любимая. Я не привел здесь картинку most dreaded — самая ужасная база данных, но вы, наверно догадываетесь, кто на первом месте. «База икс», как ее любят называть в России.

Есть обзор и по России, опрос на всеми нами уважаемой конференции HighLoad++. Проводился не нами, его делал Олег Бунин. Получилось: в России Postgres база данных №1.

Мы второй раз просим HH.ru, чтобы они с нами делились статистикой по вакансиям Postgres. 9 лет назад Postgres отставал от Oracle в 10 раз, все кричали: давайте нам ораклистов. И мы видим, что в прошлом году мы сравнялись, а дальше в 2018-м году был рост. И если вы волнуетесь о том, где найти работу, то смотрите: 2 тысячи вакансий на HH.ru это Postgres. Не волнуйтесь, работы хватит.

Для того чтобы было лучше видно, я сделал картинку, где показал вакансии Postgres относительно вакансий Oracle. Было меньше единички, начиная с 2018-го они уже вровень, и сейчас Postgres-а уже стало чуть-чуть больше. Пока немного удручает, что абсолютное число вакансий Oracle тоже растет, чего в принципе не должно быть. Но, как говорится, сидим у берега реки и смотрим: когда же мимо проплывет труп врага. Мы просто делаем свое дело.

Российское сообщество Postgres

Это самое организованное сообщество в России, я больше таких не встречал. Очень много ресурсов, чатов, где мы все общаемся по делу. Мы проводим конференции — две большие конференции: в Санкт-Петербурге и в Москве, квартирники, мы участвуем во всех крупных международных конференциях, проводим курсы.

Фактически это курсы сообщества. Их подготовила наша компания, но они свободно доступны любому из вас, смотрите на youtube наш канал или зайдите на наш сайт в раздел «Образование», там для свободного скачивания лежат курсы DBA1, DBA2, DBA3, девелоперские курсы.

А сейчас мы запускаем сертификацию — это то, что просят компании, они хотят иметь сертифицированных специалистов. И работодатель будет знать: вы сертифицированный специалист.

Очень часто спрашивают: а насколько Postgres российский? Вопрос немного неправильно поставлен: Postgres — международный. Но о российском флаге я немного скажу. Вы видите на слайде, что сделал Вадим Михеев. Тем, кто знает Postgres, понятно, что для этой базы значат MVCC, WAL, VACUUM и так далее. Это всё российский вклад. Сейчас ведущих разработчиков Postgres трое, из них двое — коммиттеры. На слайде вы видите, что сделано довольно много. Если смотреть мажорные фичи из release notes, то вы увидите наш вклад. Российский вклад есть и достаточно существенный. Мы работали с самого начала и продолжаем работать с сообществом — уже на уровне кампании.

А еще вклад компании — это книжки. У нас имеются 2 университетских курса по Postgres. Вы можете пойти в магазин и эти книжки купить, вы можете преподавать по этим курсам, сдавать экзамены и так далее. У нас имеются книжки для начинающих, которые раздаются, в том числе здесь. Очень полезная хорошая книжка. Мы ее даже перевели на английский язык.

Профессиональный Postgres

Перейдем к основному. Академический Postgres, когда он начинался, был рассчитан на несколько десятков пользователей. Комьюнити Postgres95 было меньше 400 человек. Cообщество состояло в основном из разработчиков и было еще немного пользователей. При этом — интересная деталь — разработчики были, в основном, и заказчиками, и исполнителями. Например, когда мне это было нужно, я разрабатывал для себя и, одновременно, делился со всеми. То есть комьюнити разрабатывало для комьюнити.

Начиная с 2000-го года, чуть раньше, начали появляться первые постгресовые компании: GreatBridge, 2ndQuadrant, EDB. Они уже нанимали full-time разработчиков, которые работали на сообщество. Появились первые энтерпрайзные форки и первые энтерпрайзные кастомеры. Привело это к тому, что к 2015-му году основное количество — да практически все ведущие разработчики — уже были организованы в какие-то компании. В 2015-м году образовалась наша компания: мы были последними свободными фрилансерами-разработчиками. Сейчас таких практически не осталось. Постгресовое сообщество изменилась, стало энтерпрайзным, и теперь уже эти компании драйвят разработку. Это хорошо потому, что эти компании проводят то, что необходимо энтерпрайзу. Сообщество является тормозом в хорошем смысле: оно тестирует фичи, осуждает или принимает новые фичи, оно объединяет всех нас. А Postgres стал enterprise ready, его с удовольствием используют большие компании, он стал профессиональным.

Этот слайд про будущее, как я его вижу. С появлением pluggable storage будут появляться новые хранилища: append-only, read-only, column storage — что хотите (я вот, например, мечтаю о паркетном). Будет поддержка векторных операций. Сегодня, кстати, будет доклад про них. Будет поддерживаться блокчейн. Никуда от этого не деться, раз мы переходим на цифровую экономику, на безбумажные технологии. Нужно будет использовать электронные подписи и нужно будет уметь удостоверять вашу базу данных, убеждаться, что никто ничего не подменил, и блокчейн для этого очень хорошо подходит.

Дальше: адаптивный Postgres. Это немного грустная для вас тема, но она еще довольно далека от вас. Дело в том, что DBA, вообще говоря, достаточно дорогой ресурс, и скоро базы данных не будут нуждаться в них. Базы будут достаточно умными и сами себя будут конфигурировать и подстраивать. Но это будет еще лет через десять, наверное. У нас еще много времени.

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

Источник