ванильный postgresql что это
Олег Бартунов: Про «Postgres Pro»
Завтра рано утром я улетаю в Луклу навстречу треку, который я ждал целый год. Мы планируем пройти 5 высокогорных перевалов и 4 долины, увидеть еще раз высочайшие горы мира, ну и померзнуть в палатках, куда уж без этого. Моя голова уже почти отключилась от забот «того мира», но я попытаюсь объяснить зачем мы начали свои форки постгреса. Я уже наталкивался в сети на мифы вокруг наших сборок, что с одной стороны хорошо, ибо это означает, что дистрибутивами стали интересоваться и пользоваться, но это также означает, что мы недостаточно ясно пояснили наши мотивы. Поэтому я попробую это сделать сейчас, перед тем, как сдам ноутбук в камеру хранения.
Мне понравился этот монах, который стоически несколько часов стоял неподвижно, чем-то он был похож на отважного Щелкунчика. Я пожертвовал один раз, а потом не выдержал и положил денег еше раз.
Postgres Pro (он же Postgres Pro Standard), доступен с исходными текстами, включает некоторые наши патчи, которые уже попали в девелоперскую версию ванильного Постгреса, обычно отслеживает версии ванильного Постгреса, с которым сохраняет совместимость. Этим мы даем возможность пользователям быстрее попробовать новые фичи ванильного Постгреса.
Этот форк включает патчи для очистки памяти, проверки контрольных сумм бинарников и другие. Очевидно, что такие патчи сообществу совсем не нужны. Отмечу, что ванильный Постгрес недавно прошел сертификацию на Common Criteria, но на самый низший уровень, для которого не требовались дополнительные работы. Я надеюсь, что со временем ванильный Постгрес будет сертифицироваться на более высокие уровни и тогда мы сможем пропихнуть (отдадим) наши патчи безопасности и поддержка нашего форка станет легче.
(Примечание: это внутренняя условная нумерация, эти версии будут доступны пользователям под номерами, соответствующими актуальным релизам Postgres Pro)
История этого форка началась с совещания разработчиков Постгреса весной этого года (2016), на котором Саша Коротков представил план разработок Postgres Professional, который мы подготовили перед конференцией исходя из запросов наших клиентов. Наши планы вызвали большой интерес, другие компании тоже откликнулись своими планами, но мы не увидели желания сообщества что-то коренным образом менять. Много шумихи было вокруг версии 10.0, но ничего кардинального в ней не предполагается.
Где-то в июле 2016 года мы окончательно поняли (есть точная дата), что у сообщества другие интересы, а наши клиенты хотят новых фич уже сейчас, и нам надо самим начинать продвигать наши разработки в нашем собственном форке без оглядки на совместимость.
На этом разработки Postgres Pro Enterprise не заканчиваются, и мы обязательно напишем о них подробно. Мы также рассматриваем возможность включения поддержки 1С в энтерпрайз версию. Я надеюсь, что теперь понятна необходимость Postgres Pro Enterprise, которая в первую очередь предназначена для крупных клиентов.
На все эти продукты, а также на ванильный Постгрес, мы предоставляем техническую поддержку.
Мне кажется, что сейчас все должно быть кристально чистым.
Теперь про мифы. Чтобы написать про них, у меня не осталось времени и сил, так что просто дам ссылку на короткую презентацию «Russians in PostgreSQL» (видео), где я очень кратко показал 20-лет развития Постгреса и отметил российский вклад (красненьким цветом).
Пора мне паковаться, сдавать ноутбук в storage room, и немного поспать перед полетом в Луклу на маленьком самолетике, чтобы начать свой трек и окончательно раствориться в Гималаях. А вам всем желаю не ссориться, а просто принять тот факт, что мы создали нашу компанию Postgres Professional во благо всех, в том числе и ванильного Постгреса. Почитайте внимательно, если что-то непонятно, то проще прийти к нам в компанию и поговорить с нами, мы очень открыты, у нас проходят семинары, можно выступить, высказаться. На крайний случай, я доступен в ЖЖ, ФБ, ко мне обращаются сотни(!) людей, и я стараюсь со всеми быть откровенен и оказываю помощь. Этот месяц меня почти не будет в сети, я буду изредка что-то постить, чтобы показать прогресс нашего похода, но у меня не будет возможности оказывать профессиональную помощь, для этого вы можете воспользоваться контактами на нашем сайте.
База данных Postgres Pro: когда она лучше PostgreSQL
Есть в интернете такой сайт с индексом популярности СУБД — DB Engine. Открыв его, мы увидим в топе бесплатную опенсорсную базу PostgreSQL, которая сопоставима по возможностям и функциям с популярными коммерческими решениями. А есть еще и российская СУБД Postgres Pro, сделанная из исходников PostgreSQL.
Как и зачем в России сделали свою версию этой СУБД и кому она может понадобиться? Разбираемся в вопросе.
Postgres Pro и PostgreSQL: экскурс в мир популярного бэкенда
Еще лет 10-15 назад разработчики повально ставили на свои бэкенд-проекты популярную СУБД MySQL. У нее в те времена было огромное количество косяков — разваливались кластеры и реплики, тормозили индексы, тексты в таблицах превращались в кракозябры. Разработчики плакали, кололись, но продолжали есть кактус MySQL — несмотря на отвратительное качество работы, это было самое популярное, документированное и простое в установке решение на рынке.
PostgreSQL в то время уже существовала и по качеству работы рвала MySQL. Но меньшая популярность в сообществе программистов и необходимость вдумчиво читать документацию делала эту СУБД не столь популярной.
Как появилась российская СУБД Postgres Pro
Дикая популярность PostgreSQL привела к тому, что в России одна умная и успешная компания сделала свою версию этой СУБД — Postgres Pro. Ну а что? Код оригинальной БД открыт — при условии соблюдения определенных требований со стороны лицензии на свободное ПО можно делать свои продукты на основе публичного кода.
Комьюнити вокруг опенсорс-продуктов часто весьма инертное, некоторые правки и предложения вносятся в ядро кода годами — куда быстрее сделать свою копию кода и внести туда все, что считаешь нужным.
А еще у разных стран разные юридические требования к использованию программного обеспечения в системах. У России они тоже есть, и с ними нужно считаться. Так что вполне хватает причин создать свой, местный, вариант СУБД, использовав открытый код.
Так что предпосылки для создания таких проектов есть и они уже подтверждены рынком. Проекты российской компании Postgres Pro построены на этих же принципах.
Давайте разбираться, что нам предлагают.
Сравнение Postgres Pro и PostgreSQL: что добавилось в российской версии
Нам предлагают полнофункциональную версию PostgreSQL с кучей мощных доработок и сертификацией под Россию.
Postgres Pro является полным преемником традиционного PostgreSQL. А это значит, что мы держим в руках систему, ориентированную на максимальную функциональность и надежность хранимых данных. Она — идеальное решение для систем, где нельзя терять или случайно искажать данные. Основные сферы применения Postgres Pro: финансовый сектор, транспорт, складские поставки, системы управления бизнесом и так далее.
Надежность здесь не означает простоту и примитивность — Postgres Pro прекрасно справляется с добавлением специализированных процедур в свой встроенный язык запросов, хранением бинарных данных, географических точек, работой с JSON-документами. Все фичи крутой современной СУБД на месте! И они нисколько не замедляют работы этой системы — всё работает шустро и стабильно.
Postgres Pro (как и родительская PostgreSQL) хорошо масштабируется, и, как следствие, легко переносит выход из строя пары серверов БД, не теряя при этом данные и не переставая обслуживать клиентов.
Есть и кое-какие фичи, которых у родительской СУБД нет, например:
В целом — список доработок огромный, хватит на отдельную статью.
Различия Postgres Pro Enterprise и PostgreSQL
1. Кластер multimaster
Расширение multimaster и его поддержка в ядре, которые есть только в версии Postgres Pro Enterprise, дают возможность строить кластеры серверов высокой доступности (High Availability). После каждой транзакции гарантируется глобальная целостность (целостность данных в масштабах кластера), т.е. на каждом его узле данные будут идентичны. При этом легко можно добиться, чтобы производительность по чтению масштабировалась линейно с ростом количества узлов.
В ванильном PostgreSQL есть возможность строить высокодоступные кластеры с помощью потоковой репликации, но для определения вышедших из строя узлов и восстановления узла после сбоя требуются сторонние утилиты, и хитроумные скрипты. multimaster справляется с этим сам, работает из коробки без использования внешних утилит или сервисов.
Масштабирование по чтению в ванильном PostgreSQL возможно при репликации в режиме горячего резерва ( Hot-standby ), но с существенной оговоркой: приложение должно уметь разделять read-only и read-write запросы. То есть для работы на ванильном кластере приложение, возможно, придется переписать: по возможности использовать отдельные соединения с базой для read-only транзакций, и распределять эти соединения по всем узлам. Для кластера с multimaster писать можно на любой узел, поэтому проблемы с разделением соединений с БД на пишущие и только читающие нет. В большинстве случаев переписывать приложение не надо.
С помощью логической репликации в ванильном PostgreSQL можно реализовать асинхронную двунаправленную репликацию (например BDR от 2ndQuadrant), но при этом не обеспечивается глобальная целостность и возникает необходимость разрешения конфликтов, а это можно сделать только на уровне приложения, исходя из его внутренней логики. То есть эти проблемы перекладываются на прикладных программистов. Наш multimaster сам обеспечивает изоляцию транзакций (сейчас реализованы уровни изоляции транзакций «повторяемое чтение» ( Repeatable Read ) и «чтение фиксированных данных» ( Read Committed ). В процессе фиксации транзакции все реплики будут согласованы, и пользовательское приложение будет видеть одно и то же состояние базы; ему не надо знать, на какой машине выполняется запрос. Чтобы этого добиться и получить предсказуемое время отклика в случае отказа узла, инициировавшего транзакцию, мы реализовали механизм 3-фазной фиксации транзакций (3-phase commit protocol ). Этот механизм сложнее, чем более известный 2-фазный, поэтому поясним его схемой. Для простоты изобразим два узла, имея в виду, что на самом деле аналогично узлу 2 обычно работает четное число узлов.
Рис. 1. Схема работы multimaster
Запрос на фиксацию транзакции приходит на узел 1 и записывается в WAL узла. Остальные узлы кластера (узел 2 на схеме) получают по протоколу логической репликации информацию об изменениях данных и, получив запрос подготовить фиксацию транзакции ( prepare transaction ) применяют изменения (без фиксации). После этого они сообщают узлу, инициировавшему транзакцию, о своей готовности зафиксировать транзакцию ( transaction prepared ). В случае, когда хотя хотя бы один узел не отвечает, транзакция откатывается. При положительном ответе всех узлов, узел 1 посылает на узлы сообщение, что транзакцию можно зафиксировать ( precommit transaction).
Здесь проявляется отличие от 2-фазной транзакции. Это действие на первый взгляд может показаться лишним, но на самом деле это важная фаза. В случае 2-фазной транзакции узлы зафиксировали бы транзакцию и сообщили об этом 1-му, инициировавшему транзакцию узлу. Если бы в этот момент оборвалась связь, то узел 1, не зная ничего об успехе/неуспехе транзакции на узле 2, вынужден был бы ждать ответа, пока не станет понятно, что он должен сделать для сохранения целостности: откатить или зафиксировать транзакцию (или фиксировать, рискуя целостностью). Итак, в 3-фазной схеме во время 2-ой фазы все узлы голосуют: фиксировать ли транзакцию. Если большинство узлов готово зафиксировать ее, то арбитр объявляет всем узлам, что транзакция зафиксирована. Узел 1 фиксирует транзакцию, отправляет commit по логической репликации и сообщает метку времени фиксации транзакции (она необходима всем узлам для соблюдения изоляции транзакций для читающих запросов. В будущем метка времени будет заменена на CSN — идентификатор фиксации транзакции, Commit Sequence Number ). Если узлы оказались в меньшинстве, то они не смогут ни записывать, ни читать. Нарушения целостности не произойдет даже в случае обрыва соединения.
2. 64-разрядные счетчики транзакций
Проблема переполнения счетчика носит название ( transaction ID wraparound ), поскольку пространство номеров транзакций закольцовано (это наглядно объясняется в статье Дмитрия Васильева). При переполнении счетчик обнуляется и идет на следующий круг.
Рисунок 2. Как действует заморозка транзакций, отставших больше, чем на полкруга.
Замена 32-разрядных счетчиков на 64-разрядные отодвигает переполнение практически в бесконечность. Необходимость в VACUUM FREEZE практически отпадает (в текущей версии заморозка все еще используется для обработки pg_clog и pg_multixact и в экстренном случае, о котором ниже). Но в лоб задача не решается. Если у таблицы мало полей, и особенно если эти поля целочисленные, ее объем может существенно увеличиться (ведь в каждой записи хранятся номера транзакции, породивших запись и той, что эту версию записи удалила, а каждый номер теперь состоит из 8 байтов вместо 4). Наши разработчики не просто добавили 32 разряда. В Postgres Pro Enterprise верхние 4 байта не входят в запись, они представляют собой «эпоху» — смещение (offset) на уровне страницы данных. Эпоха добавляется к обычному 32-разрядному номеру транзакции в записях таблицы. И таблицы не распухают.
Другая проблема 32-разрядных счетчиков в том, что обработка переполнений очень сложный процесс. Вплоть до версии 9.5 в соответствующем коде находили и исправляли весьма критичные баги, и нет гарантий, что баги не проявятся в следующих версиях. В нашей реализации 64-разрядного счетчика транзакций заложена простая и ясная логика, поэтому работать с нею и дальше ее развивать будет проще, чем бороться с переполнением.
Файлы данных систем с 64-разрядными счетчиками бинарно несовместимы с 32-разрядными, но у нас есть удобные утилиты для конвертации данных.
3. Постраничное сжатие
В нашей реализации страницы хранятся сжатыми на диске, но при чтении в буфер распаковываются, поэтому работа с ними в оперативной памяти происходит точно так же, как обычно. Разворачивание сжатых данных и их сжатие происходит быстро и практически не увеличивает загрузку процессора.
Поскольку объем измененных данных при сжатии страницы может увеличиться, мы не всегда можем вернуть ее на исходное место. Мы записываем сжатую страницу в конец файла. При последовательной записи сбрасываемых на диск страниц может значительно возрасти общая производительность системы. Это требует файла отображения логических адресов в физические, но этот файл невелик и издержки незаметны.
Для сжатия мы выбрали современный алгоритм zstd (его разработали в Facebook). Мы опробовали различные алгоритмы сжатия, и остановились на zstd : это лучший компромисс между качеством и скоростью сжатия, как видно из таблицы.
4. Автономные транзакции
Технически суть автономной транзакции в том, что эта транзакция, выполненная из основной, родительской транзакции, может фиксироваться или откатываться независимо от фиксирования/отката родительской. Автономная транзакция выполняется в собственном контексте. Если определить не автономную, а обычную транзакцию внутри другой (вложенная транзакция) то внутренняя всегда откатится, если откатится родительская. Такое поведение не всегда устраивает разработчиков приложений.
Автономные транзакции часто используются там, где нужны логирование действий или аудит. Например, необходима запись о попытке некоторого действия в журнал в ситуации, когда транзакция откатывается. Автономная транзакция позволяет сделать так, чтобы «чувствительные» действия сотрудников (просмотр или внесение изменений в счета клиентов) всегда оставляли следы, по которым можно будет в экстренной ситуации восстановить картину (пример на эту тему будет ниже).
В таких СУБД как Oracle и DB2 (но не MS SQL ) автономные транзакции формально задаются не как транзакции, а как автономные блоки внутри процедур, функций, триггеров и неименованных блоков. В SAP HANA тоже есть автономные транзакции, но их как раз можно определять и как транзакции, а не только блоки функций.
Во вложенных автономных транзакциях можно определять все доступные PostgreSQL уровни изоляции — Read Committed, Repeatable Read и Serializable — независимо от уровня родительской транзакции. Например:
BEGIN TRANSACTION
BEGIN AUTONOMOUS TRANSACTION ISOLATION LEVEL REPEATABLE READ
END ;
END ;
Все возможные комбинации работают и дают разработчику необходимую гибкость. Автономная транзакция никогда не видит результатов действий родительской, ведь та еще не зафиксирована. Обратное зависит от уровня изоляции основной. Но в отношениях их с транзакцией, стартовавшей независимо, будут действовать обычные правила изоляции.
В функциях синтаксис немного отличается: ключевое слово TRANSACTION выдаст ошибку. Автономный блок в функции определяется всего лишь вот так:
CREATE FUNCTION AS
BEGIN ;
BEGIN AUTONOMOUS
END ;
END ;
Соответственно уровень изоляции задать нельзя, он определяется уровнем родительской транзакции, а если он явно не задан, то уровнем по умолчанию.
Приведем пример, который считается одним из классических в мире коммерческих СУБД. В некотором банке в таблице customer_info хранятся данные клиентов, их долги
Пусть эта таблица будет недоступна напрямую сотруднику банка. Однако они имеют возможность проверить долги клиентов с помощью доступной им функции:
Перед тем, как подсмотреть данные клиента, функция записывает имя пользователя СУБД, номер эккаунта клиента и время операции в в таблицу лог:
Мы хотим, чтобы сотрудник имел возможность осведомиться о долгах клиента, но, дабы не поощрять праздное или злонамеренное любопытство, хотим всегда видеть в логе следы его деятельности.
Любопытный сотрудник выполнит команды:
BEGIN ;
SELECT get_debt (1);
ROLLBACK ;
В этом случае сведения о его деятельности откатятся вместе с откатом всей транзакции. Поскольку нас это не устраивает, мы модифицируем функцию логирования:
Теперь, как бы не старался сотрудник замести следы, все его просмотры данных клиентов будут протоколироваться.
Автономные транзакции удобнейшее средство отладки. Сомнительный участок кода успеет записать отладочное сообщение перед тем, как неудачная транзакция откатится:
BEGIN AUTONOMOUS
INSERT INTO test (msg) VALUES ( ‘STILL in DO cycle. after pg_background call: ‘ ||clock_timestamp():: text );
END ;
PERFORM * FROM pg_background_result(pg_background_launch (query))
AS (result text );
PS. Продолжение следует!
PPS. Мы будем рады узнать ваше мнение об актуальности и возможных применениях этих новшеств!
СУБД Postgres Pro Standard
Российская система управления базами данных
на основе PostgreSQL
Почему выбирают СУБД Postgres Pro Standard?
СУБД Postgres Pro Standard разработана специально для российского рынка на основе открытой СУБД PostgreSQL.
Новые возможности
Популярная платформа
Техподдержка
Российское законодательство
Отличия Postgres Pro Standard от PostgreSQL
Улучшения производительности на многоядерных системах
Усовершенствования полнотекстового поиска
Переносимость
Доступ к внутреннему представлению данных
Сохранение планов выполнения запросов
Сохранение информации о статистике
Нечеткий поиск подстрок
Покрывающие индексы
Запросы к полям типа JSONB
Совместимость с Microsoft SQL Server
Предотвращение разрастание каталога pg_class
Обновление статистики
Управление индексами при выполнении запроса
Текущая версия
Последняя версия Postgres Pro Standard 14.1.1 выпущена
1 декабря
Обзор
Этот выпуск основан на PostgreSQL 14.1 и включает все новые возможности, появившиеся в PostgreSQL 14, а также исправления ошибок, вошедшие в PostgreSQL 14.1. Подробное их описание вы можете найти в Замечаниях к выпуску PostgreSQL 14 и в Замечаниях к выпуску PostgreSQL 14.1, соответственно. Ниже перечислены другие основные изменения и усовершенствования:
Добавлены расширенные механизмы обеспечения безопасности в Postgres Pro Standard :
Расширенные политики аутентификации, обеспечивающие эффективное управление паролями и контроль доступа. (См. CREATE PROFILE и ALTER ROLE ).
Встроенные проверки целостности исполняемых файлов, файлов конфигурации и системных таблиц. (Только сертифицированная редакция.)
Встроенные механизмы защиты данных, которые позволяют стерилизовать объекты, перед удалением заполняя их нулями. Обнуление объектов может производиться перед удалением файлов на диске и перед удалением устаревших версий строк (очисткой страниц), освобождением ОЗУ и удалением или перезаписью файлов WAL. (Только сертифицированная редакция.)
В отчёт добавлен раздел «Load distribution» (Распределение нагрузки), в котором показывается, как распределена нагрузка по сильно загруженным объектам, таким как базы данных, приложения, узлы или пользователи, в разрезе ресурсов (общее время или количество записанных общих блоков и т. п.), в виде линейчатых диаграмм.
Добавлены таблицы отчётов «Session statistics by database» (Статистика сеансов по базам данных) и «WAL statistics» (Статистика WAL) на основании новых представлений и полей, появившихся в Postgres Pro 14.
Миграция на версию 14
Помимо этого, учтите описанные ниже особенности обновления, связанные с изменениями в использовании правил сортировки.
В Windows инсталляции Postgres Pro Standard могли содержать базы данных с правилами сортировки по умолчанию, использующими ICU, в которых имя правила имело синтаксически правильный формат языка BCP 47, но неправильный код языка или другие параметры, в результате чего это правило сортировки оказывалось недействительным для ICU.
Если эта проблема затрагивает другие базы данных, вы получите то же сообщение об ошибке, что и при попытке создания в Postgres Pro нового кластера с некорректным правилом сортировки. Вы можете попытаться решить эту проблему следующим образом:
Восстановите изменённое содержимое базы в psql для завершения обновления. Эта операция может прерваться ошибкой, если окажутся нарушенными какие-либо ограничения, зависящие от правил сортировки в базе данных. В этом случае вы можете попытаться разрешить эти проблемы вручную.
При обновлении с Postgres Pro Standard версии 10 кластеров, в которых нет информации о версии библиотеки ICU, состояние актуальности индексов и ограничений определяется по версиям правил сортировки. Однако для кластеров, в которых содержатся базы данных с системными правилами сортировки ICU, но отсутствует информация о версии библиотеки ICU и/или версиях правил сортировки, нет никакой возможности удостовериться в том, что в текущей версии Postgres Pro используется та же версия библиотеки ICU.
Примечание
Олег Бартунов, Postgres Professional — о независимости от импортного ПО и российском вкладе в самую популярную СУБД в мире
Созданные человеком программы берут данные и манипулируют ими, чтобы создавать новые, более ценные данные. Именно базы данных (СУБД) являются ядром любой информационной системы, хранящим как данные, которыми нужно манипулировать, так и полученную новую информацию. Из-за теоремы CAP не существует однозначного выбора между базой данных NoSQL или SQL. А растущая популярность БД NoSQL приводит к новым проблемам и моделям данных, которые традиционные реляционные базы не могут должным образом обработать. Основатель компании Postgres Professional Олег Бартунов рассказал «Хайтеку» об истории и перспективах одной из самых популярных СУБД в мире — PostgreSQL.
Читайте «Хайтек» в
Postgres как исконно российская СУБД
— Вы отстаиваете идею использования PostgreSQL в качестве национальной СУБД по программе импортозамещения. Это как многочисленные «национальные операционные системы» на базе Linux? Насколько вообще корректно называть продукт, созданный мировым сообществом, национальным?
— Да, действительно, в реестр отечественного ПО входят более 40 ОС на базе Linux различных российских производителей. Все эти операционные системы неравнозначны. К сожалению, в некоторых случаях мы имеем дело с простым переклеиванием ярлыков, порой даже грубым и неаккуратным. Но многие российские производители по-настоящему работают и делают патчи для ядра Linux, развивают и создают свои пакетные репозитории, участвуют в жизни международного сообщества и занимаются просветительской деятельностью.
СУБД — система управления базами данных.
PostgreSQL — свободная объектно-реляционная система управления базами данных. Существует в реализациях для множества UNIX-подобных платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows.
В случае с Postgres ситуация обстоит несколько иначе. С самого начала существования данной системы в ней было заметное российское участие. Когда Postgres стал open-source-проектом, в нем сразу принял участие программист из Красноярска Вадим Михеев, который написал несколько весьма значимых составляющих Postgres, актуальных и по сей день. Вскоре к проекту присоединился и я. Первым моим вкладом стала функциональность интернационализации, в том числе поддержка русского языка, которая позволила работать с алфавитами, отличными от латинского. И Postgres стал по-настоящему международным.
C годами отечественный вклад в Postgres только увеличивался. Появились Федор Сигаев и Александр Коротков, ставшие ведущими разработчиками. Вместе мы улучшили расширяемость Postgres: создали возможность эффективной и быстрой работы со слабоструктурированными данными (JSONB), разработали специализированные индексы для поиска по ним и по пространственным данным, создали полнотекстовый поиск. Этот вклад признан во всем мире.
JSONB — оптимизированный способ хранения данных в формате JSON, позволяющий извлекать данные без полного синтаксического разбора.
JSON (JavaScript Object Notation) — простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка программирования JavaScript, определенного в стандарте ECMA-262 3rd Edition — December 1999. JSON — текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других.
Есть и другой показатель вклада в СУБД — по количеству патчей, которые ежегодно поступают от участников из разных стран. Например, в release notes (замечания к версии программного продукта — «Хайтек») к 11-й версии упоминается около 25 человек с русскими фамилиями, из них 15 — сотрудники Postgres Professional. Это говорит о том, что российский вклад в Postgres больше, чем, например, вклад в население Земли или в мировой ВВП.
В условиях усиливающейся экономической глобализации единственный способ сделать свой национальный продукт (если не изобретать что-то кардинально новое) — это присоединиться к хорошему международному проекту с открытым кодом, внести в него свой вклад и достичь мирового признания.
Хочу обратить внимание, что в реестр отечественного ПО включен не open-source-продукт, а Postgres Pro — российская СУБД, права на которую принадлежат нашей компании. Она создана на базе Postgres с открытым кодом, но содержит существенные доработки, сделанные Postgres Professional по запросам наших клиентов — российских предприятий и организаций.
— Крупнейшие мировые производители СУБД предупредили российские компании, попавшие в санкционный список, о прекращении сотрудничества по всем проектам, начавшимся после 29 января 2018 года. К вам уже стоит очередь из сбербанков, газпромов и лукойлов?
— Для многих российских организаций остро встала проблема санкционной устойчивости. Поэтому они, даже не находясь под санкциями, задумываются о возможных последствиях в случае, если все-таки попадут под них. Вполне логично подстраховаться, поскольку впадать в полную зависимость от зарубежного ПО — неприемлемый риск для многих организаций. В связи с этим мы активно работаем со многими, хотя и не всеми, крупными российскими компаниями и государственными структурами, в том числе с Минфином России и Сбербанком.
— Чем принципиально отличаются свободно распространяемые и коммерческие версии PostgreSQL? Какой рост продаж у коммерческих версий?
В настоящее время мы наблюдаем усиление интереса к реальному импортозамещению в сфере ПО, которое в самые первые годы несколько буксовало. В связи с этим ожидается рост продаж Postgres Pro и положительная динамика.
— Есть ли «обратная связь» между ними, когда решения из коммерческого продукта переходят в свободно-распространяемый?
— В мире есть множество компаний, которые создают решения на базе открытого Postgres. Если говорить о крупных компаниях, то это американская EnterpriseDB, английская 2ndQuadrant, японская Fujitsu и российская Postgres Professional. Под разными названиями эти компании выпускают на базе Postgres свои продукты, рассчитанные на энтерпрайзный рынок. При этом все компании активно участвуют в разработке открытой СУБД и существенную часть своих разработок отдают мировому сообществу. Так устроена экосистема Postgres. Коммерческие разработки ориентированы на рынок, и потому ведутся более интенсивно, чем open-source-проект. В результате чего «ванильный» Postgres в условиях свободной лицензии получает от коммерческих продуктов больше, чем если бы его лицензия накладывала ограничения и не позволяла создавать коммерческие продукты.
Целые продукты из коммерческой сферы перешли в open-source — CitusDB или Greenplum, например. Именно свободной лицензии Postgres обязан нынешним бурным ростом в мировом масштабе. В то же время есть компании, которые ведут разработки на его базе и не делятся ими с мировым сообществом. Например, Amazon Web Services (AWS).
Развитие Postgres
— PostgreSQL уже можно смело называть PostgreNoSQL?
— При желании можно, но и это будет не совсем точно. Есть другой термин — Not Only SQL (с англ. «не только SQL» — «Хайтек»), который означает, что современные реляционные СУБД приняли вызов со стороны NoSQL и сейчас прекрасно работают со слабоструктурированными данными. Движение Postgres в этом направлении началось в 2004 году: тогда мы разработали модуль Hstore, благодаря чему PostgreSQL стал первой реляционной системы с поддержкой слабоструктурированных данных.
Следующий скачок был сделан через 10 лет, в 2014 году, когда мы реализовали поддержку формата JSONB. Этот формат представления данных позволяет не просто работать со слабоструктурированными данными, а делать это эффективно и быстро. Так что за этим сразу последовал рост популярности PostgreSQL во всем мире. И я связываю это с приходом NoSQL-ных пользователей. Сейчас JSON есть даже в стандарте SQL, и другие системы управления вслед за Postgres начали его поддерживать, но не столь эффективно.
Кстати, мы предпочитаем говорить не PostgreSQL, а Postgres — такое название проще произносится по-русски и признается сообществом. Именно так СУБД называлась до получения приставки SQL: изначально Майкл Стоунбрейкер разработал Postgres, потом она стала называться Postgres95 и, наконец, PostgreSQL.
SQL — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.
NoSQL — термин, обозначающий ряд подходов, направленных на реализацию систем управления базами данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL.
Майкл Стоунбрейкер — американский ученый в области информатики, PhD, исследователь проблематики построения систем управления базами данных, профессор Калифорнийского университета в Беркли, с 2001 года — профессор Массачусетского технологического института. Разработчик СУБД, основатель Ingres и VoltDB.
— В 2016 году широко обсуждалась новость об отказе Uber от PostgreSQL в пользу другого продукта. В качестве причин назывались проблемы с репликацией, особенно при смене версии продукта, повреждения данных при невинных операциях и ряда других. Что изменилось с тех пор?
— Как и у любого продукта, у Postgres имеются свои недостатки, но есть и способы их обойти. В свое время Uber решил не заниматься недостатками, а перейти на другую СУБД, с которой, вероятно, компания умела лучше обращаться. В то же время есть ничуть не менее нагруженные проекты, которые прекрасно работают на Postgres. Кроме того, в системе появилась логическая репликация, которой еще не было в 2016 году. Она обеспечивает бесшовную смену версий продукта. Также логическая репликация полностью пригодна для нагрузки «только на чтение». Ведется работа над исправлением ряда других проблем. В частности, в 12-й версии уже появился механизм подключаемых хранилищ, который в 13-й версии позволит создать подключаемое колоночное хранилище ZedStore и хранилище с UNDO-логом (ZHeap) (методы хранения и обработки данных в Postgres — «Хайтек»). И это сократит объем записи на диск.
— Когда мы увидим PostgreSQL не как продукт, а как облачный сервис?
— Облачные сервисы на базе Postgres уже есть. За рубежом подобными сервисами занимается множество компаний, в том числе Amazon, Google, Alibaba и Microsoft. В России такой сервис предоставляют Яндекс и Mail.Ru. При этом количество облачных сервисов будет расти как в нашей стране, так и за рубежом.
Но чтобы Postgres полноценно использовал преимущества облачной среды, в него необходимо вносить ряд существенных изменений. Тогда производительность в облачной среде будет почти такой же высокой, как и в обычном режиме. Мы занимаемся такими разработками.
Postgres как наука
— Помимо прекрасного продукта, который вот уже более 20 лет использует весь интернет, вы развиваете и само СУБД-строение. Существуют ли какие-то русскоязычные курсы по технологиям построения, чтобы по ним можно было изучать предмет в вузах?
— Да, мы мечтаем о том, чтобы отрасль СУБД-строения динамично развивалась в нашей стране. Безусловно, для этого необходимо готовить специалистов, знающих архитектуру и внутреннее устройство. Для содействия развитию этого направления мы пригласили профессора из Санкт-Петербургского государственного университета — Бориса Асеновича Новикова. Это научный деятель мировой величины в сфере систем управления. При нашей поддержке он написал учебник «Технологии баз данных». Первый том уже вышел. Сейчас идет работа над вторым. Борис Асенович по нашему приглашению также прочитал свой курс в МГУ в качестве межфакультетского факультатива. Видеозаписи постепенно выкладываются на сайте Postgres Professional, и с тремя лекциями этого курса уже можно ознакомиться.
Также при нашей поддержке доцент СибГУ имени М. Ф. Решетнева Евгений Павлович Моргунов разработал спецкурс «Язык SQL», позволяющий обрести фундаментальные знания в области систем управления базами данных. Второй год подряд этот курс с успехом читается в стенах ВШЭ. В качестве дополнения при поддержке компании Postgres Professional выпущен учебник «PostgreSQL. Основы языка SQL».
Весной этого года впервые в России мы запустили программу сертификации специалистов по PostgreSQL. Поскольку специалисты по Postgres становятся все более востребованными на российском рынке, необходимы единые стандарты и критерии для оценки уровня знаний. Во многом наша программа сертификации стала ответом на запросы заказчиков и партнеров.
— Каким вы видите будущее СУБД через 10–20 лет? Объектно-реляционные системы еще будут находить применение?
— Да, они еще будут находить применение. Эти СУБД базируются на строгой математической теории, и она еще долго будет актуальной. Мы не видим никаких причин, чтобы те прикладные задачи, для решения которых нужна классическая система, куда-то исчезли.
Но вопрос не только в том, что данных становится очень много. Если раньше операционные и аналитические системы, то есть базы данных и вычисления были разнесены между собой, то сейчас вычисления приближаются к данным и в идеале должны совершаться одновременно с их поступлением. Так что уже недостаточно одной технологии OLTP — обработки транзакций в режиме реального времени. И недостаточно онлайн аналитики данных, то есть OLAP. На передний план выходит гибридная транзакционно-аналитическая обработка данных (HTAP), способная в режиме реального времени и стриминга совершать обработку данных и транзакций. При этом достигается высокое быстродействие, так как данные не нужно переносить из базы для вычислений, данные транзакций сразу доступны для аналитики с момента их создания. Так что технология HTAP наряду с облаками будет задавать тон в плане долгосрочного развития СУБД.