Начало работы с PostgreSQL. Когда не стоит использовать SQLite. Типы данных, создаваемые пользователем

Postgres Pro - Российская СУБД, разработанная компанией Postgres Professional на основе свободно-распространяемой СУБД PostgreSQL. Postgres Pro входит в реестр российского ПО (см https://reestr.minsvyaz.ru/reestr/65273/)

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

Сравнение версий Postgres Pro

СУБД Postgres Pro
Enterprise
Postgres Pro
Standard
PostgreSQL
Коммерческая СУБД, разработанная Postgres Professional для ответственных приложений и высоких нагрузок. Российская СУБД с открытым кодом, разработанная компанией Postgres Professional на основе свободно-распространяемой СУБД PostgreSQL Свободно-распространяемая СУБД, разработанная международным сообществом.
Единый Реестр российского ПО
64-разрядный счетчик транзакций
Инкрементальный бэкап на уровне блоков
Сертификат ФСТЭК СВТ 5, НДВ 4
Автономные транзакции
Секционирование таблиц
Компрессия данных
Мультимастер
Поддержка 1С
Переносимые таблицы
Хинты планировщика


Версии Postgres Pro

Номер версии Postgres Pro строится из номера версии PostgreSQL с дополнением одного разряда, обозначающего номер текущего выпуска. При выходе новой минорной версии PostgreSQL (обычно это происходит при появлении патчей, связанных с безопасностью и исправлением серьезных ошибок), нумерация Postgres Pro сбрасывается на единицу. Например, при выходе PostgreSQL 9.5.1 выходит PostgresPro 9.5.1.1, затем до появления PostgreSQL 9.5.2 может выйти Postgres Pro 9.5.1.2, 9.5.1.3 и т.д. При выходе PostgreSQL 9.5.2 Postgres Pro обновится до версии 9.5.2.1 и т.д.

Одновременно с выпуском исходного кода Postgres Pro мы публикуем наши сборки в виде пакетов под различные платформы. Это следующие операционные системы и их версии:

  1. Linux
    • CentOS 6/7,
    • Debian 7/8,
    • Ubuntu 12.04/14.04/16.04/16.10,
    • Oracle Linux,
    • Rosa Enterprise Linux server,
    • ROSA SX Cobalt Server,
    • ROSA DX Cobalt Server,
    • ROSA Marathon LTS 2012,
    • Alt Linux Centaur 8,
    • Alt Linux СПТ 6,
    • Alt Linux СПТ 7,
    • SUSE Linux Enterprise Server,
  2. Microsoft ® Windows ® 2012 или 2016 .

Базы данных Postgres Pro 9.5.*.* совместимы с PostgreSQL 9.5.* При переходе с 9.5 dump/restore не требуется. При переходе с более ранних версий PostgreSQL необходимо использование dump/restore или pg_upgrade.

Текущая версия Postgres Pro Standard - 11.2.1 . Дата выпуска - 28 марта 2019. .

Отличия Postgres Pro Standard от PostgreSQL

В Postgres Pro Standard по сравнению с актуальной версией PostgreSQL на текущий момент вошли следующие изменения:

  1. Улучшения производительности на многоядерных системах:
    • оптимизации выделения хэш-таблиц в shared memory, исключающая lock contention при большом количестве процессов.
    • оптимизации Resource Owner. Улучшает производительность сложных запросов и запросом к таблицам с большим количеством партиций.
    • Оптимизации buffer manager
    • Оптимизация LWLock для архитектуры Power8
    • Оптимизации двухфазного коммита
  2. Усовершенствования полнотекстового поиска:
    • поддержка поиска фраз
    • поддержка словарей hunspell для работы со словоформами
    • некоторые словари, в том числе русский и английский, включены в состав дистрибутива и их подключение требует одной команды SQL
    • модуль shared_ispell , оптимизирующий производительность полнотекстового поиска, путем загрузки словарей в память при старте сервера, а не при начале сессии.
  3. Покрывающие индексы. Поддержка конструкции INCLUDING в CREATE INDEX.
  4. Переносимость: поддержка библиотеки libicu на всех платформах, что обеспечивает однозначную обработку порядка сортировки и прочих операций с юникодными символами. На ряде платформ эта библиотека улучшает производительность сортировки, и, что немаловажно, позволяет в Postgres Pro пользоваться abbreviated keys, которые были отключены в основной версии PostgreSQL.
  5. Модуль pg_trgm поддерживает не только нечеткое сравнение строк, но и нечеткий поиск подстроки.
  6. Модуль pageinspect поддерживает доступ не только к метаинформации, но и к внутреннему представлению данных таблиц.
  7. Добавлен новый модуль sr_plan , позволяющий сохранять планы выполнения запросов и использовать сохраненные планы вместо того, чтобы формировать план запроса заново, при каждом выполнении.
  8. Добавлен модуль dump_stat , позволяющий при дампе базы данных сохранять информацию о статистике и восстанавливать её. Это позволяет ускорить процедуру восстановления, избавляя от необходимости вычисления статистики командой VACUUM ANALYZE после восстановления.
  9. Добавлен модуль JSQuery , позволяющий на специальном языке формулировать запросы к полям типа JSONB с поддержкой GIN-индексов.
  10. Модуль предоставляет дополнительный тип данных для совместимости с Microsoft SQL Server.
  11. Модуль предоставляет дополнительный оператор равенства для совместимости с Microsoft SQL Server.
  12. Модуль предоставляет транзакционно-небезопасную функцию для усечения временных таблиц, предотвращающую разрастание каталога pg_class.
  13. Модуль предоставляет набор функций, которые немедленно обновляют статистику в целевых таблицах после операций INSERT, UPDATE, DELETE и SELECT INTO в них.
  14. Модуль добавляет поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса.

Более подробно с различиями PostgreSQL и Postgres Pro можно познакомиться в Таблице сопоставления продуктов.

Лицензия Postgres Pro Standard

Postgres Pro Standard распространяется по лицензии PostgreSQL с дополнениями Postgres Professional:

Portions Copyright (c) 2015-2019, Postgres Professional
Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
Portions Copyright (c) 1994 Regents of the University of California

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

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

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

Общество с ограниченной ответственностью "Постгрес Профессиональный" (Postgres Professional) не несет никакой ответственности за любые повреждения, включая потерю дохода, нанесенные прямым или непрямым, специальным или случайным использованием данного программного обеспечения или его документации, даже если общество с ограниченной ответственностью "Постгрес Профессиональный" было извещено о возможности таких повреждений.

Общество с ограниченной ответственностью "Постгрес Профессиональный" (Postgres Professional) специально отказывается предоставлять любые гарантии, включая, но не ограничиваясь только этими гарантиями: неявные гарантии пригодности товара или пригодности для отдельной цели. Данное программное обеспечение предоставляется на основе принципа "как есть" и общество с ограниченной ответственностью "Постгрес Профессиональный" не обязано предоставлять сопровождение, поддержку, обновления, расширения или изменения.

PostgreSQL — это кроссплатформенная объектно-реляционная СУБД с открытым исходным кодом. Из этой статьи вы узнаете, как установить PostgreSQL в Ubuntu Linux, подключиться к нему и выполнить пару простых SQL-запросов, а также о том, как настроить резервное копирование.

Чтобы установить PostgreSQL 9.2 в Ubuntu 12.10, выполните следующие команды:

sudo apt-add-repository ppa:pitti/ postgresql
sudo apt-get update
sudo apt-get install postgresql-9.2

Попробуем поработать с СУБД через оболочку:

sudo -u postgres psql

Создадим тестовую базу данных и тестового пользователя:

CREATE DATABASE test_database;
CREATE USER test_user WITH password "qwerty" ;
GRANT ALL ON DATABASE test_database TO test_user;

Для выхода из оболочки введите команду \q .

Теперь попробуем поработать с созданной базой данных от имени test_user:

psql -h localhost test_database test_user

Создадим новую таблицу:

CREATE SEQUENCE user_ids;
CREATE TABLE users (
id INTEGER PRIMARY KEY DEFAULT NEXTVAL ("user_ids" ) ,
login CHAR (64 ) ,
password CHAR (64 ) ) ;

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

SELECT NEXTVAL ("user_ids" ) ;

Прописав в качестве значения по умолчанию для поля id таблицы users значение NEXTVAL ("user_ids" ) , мы добились того же эффекта, что дает auto_increment. При добавлении новых записей в таблицу мы можем не указывать id, потому что уникальный id будет сгенерирован автоматически. Несколько таблиц могут использовать одну и ту же последовательность. Таким образом мы сможем гарантировать, что значения некоторых полей у этих таблиц не пересекаются. В этом смысле последовательности более гибки, чем auto_increment.

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

CREATE TABLE users2 (
id SERIAL PRIMARY KEY ,
login CHAR (64 ) ,
password CHAR (64 ) ) ;

В этом случае последовательность для поля id создается автоматически.

Теперь с помощью команды \d можно ознакомиться со списком всех доступных таблиц, а с помощью \d users — увидеть описание таблицы users. Если вы не получили интересующую вас информацию, попробуйте \d+ вместо \d . Список баз данных можно получить командой \l , а переключиться на конкретную БД — командой \c dbname . Для отображения справки по командам скажите \? .

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

CREATE TABLE "anotherTable" ("someValue" VARCHAR (64 ) ) ;

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

Создание схемы:

CREATE SCHEMA bookings;

Переключение на схему:

SET search_path TO bookings;

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

В остальном работа с PostgreSQL мало чем отличается от работы с любой другой реляционной СУБД:

INSERT INTO users (login, password)
VALUES ("afiskon" , "123456" ) ;
SELECT * FROM users;

Если сейчас вы попытаетесь подключиться к постгресу с другой машины, то потерпите неудачу:

psql -h 192.168.0.1 test_database test_user

Psql: could not connect to server: Connection refused
Is the server running on host "192.168.0.1" and accepting
TCP/IP connections on port 5432?

Чтобы исправить это, добавьте строку:

listen_addresses = "localhost,192.168.0.1"

… в файл /etc/postgresql/9.2/main/postgresql.conf, а также.

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

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

    К сегодняшнему дню вокруг полнофункциональной СУБД с открытым кодом 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 вокруг нее сформировалась экосистема, включающая разработчиков, аналитиков и пользователей, благодаря чему имеется возможность расширять функционал этой СУБД в зависимости от требований рынка.

    Литература

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

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



    • Перевод

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

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



    Понравилась статья? Поделиться с друзьями: