Специальный выпуск POSTGRESSO, посвященный выходу официального релиза версии 11.
На улице PostgreSQL праздник. После четырех beta вышла PostgreSQL 11 General Availability, то есть официальная версия. В анонсе есть даже приветственное слово Брюса Момджана: «готовя этот релиз, сообщество особенно заботилось о добавлении функциональности, необходимой для работы с очень большими базами данных. Доказано, что PostgreSQL хорошо работает с транзакционными нагрузками, а теперь новая версия — PostgreSQL 11 — облегчит разработчикам еще и создание приложений для Big Data».
В release notes выделяют
- секционирование:
- добавлено секционирование по хешу;
- PRIMARY KEY, FOREIGN KEY, индексы (см. ниже на эту тему) и триггеры;
- секция по умолчанию для записей, вышедших за границы созданных секций;
- UPDATE по ключу секционирования теперь может автоматически перемещать запись в соответствующую секцию;
- PostgreSQL научился исключать ненужные секции
(partition pruning)во время исполнения запросов SELECT;
- распараллеливание:
- теперь можно параллельно создавать индекс в случае B-tree;
- при CREATE TABLE… AS, CREATE MATERIALIZED VIEW и в некоторых случаях запросов с UNION;
- улучшена производительность в параллельных HASH JOIN и SEQUENTIAL SCAN;
- появились хранимые процедуры, и в них возможно управление транзакциями;
- JIT-компиляция фрагментов запросов, выигрыш на вычислении выражений;
- оконные функции теперь поддерживают все фреймовые опции SQL:2011 стандарта, в том числе расстояния по RANGE у PRECEDING/FOLLOWING, режим GROUPS, возможность исключения строк из фрейма;
- появились покрывающие индексы [не покрывающие, а инклюзивные, строго говоря — прим. POSTGRESSO], использующие выражение INCLUDE при CREATE INDEX;
- из раздела «разное»: ALTER TABLE… ADD COLUMN c значениями NOT NULL по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.
Впечатляющий список, хотя и не сенсационный: по определению Feature freeze фиксирует функциональность, а было это еще в середине апреля.
Постгресисты из HPE регулярно публикуют детальную сводку функциональности. После апрельской Feature freeze она была такова (в этом PDF есть и краткая сводка новшеств, и детали, и примеры).
Не совсем понятны, все же, сверхбурные восторги (см. ниже реакцию Лукаса Фитла) по поводу этой версии. Сделано очень много полезного, но доделывать еще предстоит очень важные вещи, а есть направления по которым не то чтобы конь не валялся, но это лишь свет в начале тоннеля. Например, многое доделали в секционировании, спору нет, но до сих пор невозможно сослаться на секционированную таблицу при помощи FOREIGN KEY. Можно создать FOREIGN KEY, но в самой секционированной таблице. Глобальных индексов нет.
JIT/LLVM появился, но тут же исчез из дефолтной конфигурации: по умолчанию он выключен. И это неспроста, ведь в некоторых случаях он не ускоряет, а вносит ненужные оверхеды.Не вошли в новую версию большие патчи с функциями для работы с
JSON/JSONB.За подключаемыми движками хранения (
pluggable storage) и, в том числе, zheap (то есть Oracle-подобный UNDO, работающий без VACUUM) многие следят с замиранием сердца. Они в эмбриональном состоянии, не утрясли еще даже API. Обзор возможностей в этом направлении есть здесь.Но это было лишь напоминание о том, что еще предстоит. Работа над новым и недоделанным старым идёт вовсю, направление развития понятно.
Статьи
New in Postgres 11: Monitoring JIT performance, Auto Prewarm & Stored Procedures
Лукас Фитл (Lukas Fittl) не только перечисляет важнейшие новшества, но и приводит оценки производительности, листинги, планы. Лукас поясняет, что нового в расширении для предразогрева базы
(pg_prewarm), напоминает об особенностях хранимых процедур, тестирует JIT. Вывод ультраоптимистический: похоже, это будет лучший релиз PostgreSQL.Postgres 11 — a First Look
Крейг Кирстинс (Craig Kerstiens) обращает внимание в том числе на фичи, не расписанные выше, напоминает об изменениях в статистике, например. Или о… см. ниже.
Adding new table columns with default values in PostgreSQL 11
Статья о любопытном патче автора, Эндрю Данстэна (Andrew Dunstan) из 2ndQuadrant. Теперь, например, в столбце по умолчанию могут задаваться не только статические величины, но и CURRENT_TIMESTAMP или random().
На конференциях и на вебинарах на тему PostgreSQL 11
Питер Айзентраут (Peter Eisentraut) из 2ndQuadrant провёл вебинар по новшествам PostgreSQL 11. Запись дополнена ответами на вопросы, неотвеченные на вебинаре.
На PGCONF.EU в Лиссабоне (вот программа) запланирован, конечно, обзорный доклад: Магнуса Хагандера (Magnus Hagander)
What's new in PostgreSQL 11? и к нему парой
What is old in PostgreSQL 11? Деврима Гюндюза (Devrim Gunduz).
Towards more efficient query plans: PostgreSQL 11 and beyond Александра Кузьменкова (Postgres Professional), в котором будут упомянуты не только (и даже не столько) закоммиченные фичи, сколько то, что еще в работе.
Также в программе есть и доклады
PostgreSQL worst practices Ильи Космодемьянского (Data Egret)
Do you need a Full-Text Search in PostgreSQL ? Олега Бартунова (Postgres Professional),
Advanced PostgreSQL Backup and Recovery methods Анастасии Лубенниковой (Postgres Professional)
Подписывайтесь на канал postgresso!
Идеи и пожелания присылайте на почту: news_channel@postgrespro.ru
Предыдущие выпуски: #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Комментарии (27)
Tantrido
19.10.2018 20:22Интересно попробовать json(b)_to_tsvector.
Не вошли в новую версию большие патчи с функциями для работы с JSON/JSONB.
А что там будет? Где можно почитать? К 11.1 подтянут?Kirill_Dan
19.10.2018 20:52А что вы там собираетесь искать? Вы что, в JSONB храните тексты?
Tantrido
19.10.2018 21:40Как это соотносится с моим вопросом?! :) Статистические данные телеметрии, хранящиеся в сложном разнородном формате. Возможно json(b)_to_tsvector() упростит запросы к JSONB, а может и нет.
Kirill_Dan
19.10.2018 22:00Ну просто по конкретным ключам в jsonb и сейчас можно строить индексы и искать по ним, а to_tsvector() — это функции для полнотекстового поиска (просто много работал с этим) для построения лексем из текста. Вот я и удивился немного, что за данные вы храните в таком формате, где нужно строить лексемы.
Tantrido
19.10.2018 22:17Я понял. Значит это совсем мне не нужно, спасибо. Интересно, что это за функции для работы с jsonb добавят?
EvilFox
20.10.2018 15:58Kirill_Dan
20.10.2018 16:08Я думаю, что все же открыть документацию и почитать ее, гораздо проще и эффективнее: postgrespro.ru/docs/postgrespro/9.5/textsearch-controls#textsearch-parsing-documents
vsb
20.10.2018 14:50А что в этом плохого?
Kirill_Dan
20.10.2018 15:11Плохого? Это не то, чтобы плохо, а скорее узкое место. Если вы хотите хранить разные тексты в данном формате, то вы должны позаботится о том, что при полнотекстовом поиске у вас существуют нужные ключи с текстами. Иначе словите эксепшн. А значит вам придется делать какие-то проверки и валидаторы. А если так, то теряется основное назначение данного формата — хранение несогласованных и необязательных данных, утеря которых не приведет к падению приложения. Например, есть у вас текст «Описание к товару». Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так. И потерять в этом формате один из ключей с вашим текстом проще паренной репы на любом этапе сохранения данных в это поле.
Выбирать формат хранения данных нужно не по модности/новаторству и т.д., а с умом, предполагая все возможные последствия данного выбора.
Например, хранить дополнительные, но необязательные атрибуты к товару можно и нужно в jsonb. Хранить там обязательные атрибуты — это быть себе злобным буратино, так как всю ответственность с базы вы перенесете на себя и свое приложение. И при выводе на странице товара, где ожидается обязательный вывод какого-то атрибута произойдет падение сценария, так как в хранимом хэше его не окажется.
Плюс не забываем о том, что ваше приложение может легко и не принуждено изменить структуру сохраняемых данных в jsonb, которому плевать что в себе хранить, например, после рефакторинга какого-то куска кода. А другой, старый код, пытается получить данные со старой структурой, которых там уже нет. Вот вы и поимели геморрой.RPG18
20.10.2018 18:43Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так.
Лукавите. База будет заставлять в том случае, если задан constrain. Ничто не мешает завести ограничения для документа: Как использовать ограничения JSON при работе с PostgreSQL
vsb
20.10.2018 22:56Мне JSON интересен в случае, когда данные могут иметь разную структуру. Если поле одно, то это совсем не интересно и в JSON его действительно хранить смысла немного, хоть оно обязательное, хоть нет. А вот если у нас таблица с товарами, у которых есть характеристики, причём у разных типов товаров могут быть разный набор характеристик, например у процессоров это поколение, частота, размеры кешей, у жёстких дисков это размер, скорость вращения дисков и тд, да к тому же ещё и конфигурируемые пользователем но в то же время может быть желание иметь полнотекстовый поиск по определённым полям (пусть даже это будет конфигурироваться администратором БД, не суть), то хранение в JSON может быть привлекательным вариантом и полнотекстовый поиск по полям внутри этого JSON может быть нужной фичей.
Kirill_Dan
20.10.2018 23:22Да, jsonb отличная штука для хранения неопределенных данных. Но вот с полнотекстовым поиском по ним у меня большой вопрос. Как и из чего конкретно будут строиться лексемы? Из всех ключей в хэше? Если это так, то мы поимеем кучу лишнего мусора при поиске. Если у нас есть конкретные текстовые поля с постоянными ключами, то можно именно на них навесить поиск, но потеряется гибкость. Кстати сейчас делать полнотекстовый поиск по ключам в jsonb тоже ничего не мешает. Удобно построить отдельную таблицу с лексемами, куда при сохранении сущности сохранять текст переводя его в to_tsvector. И уже делать поиск по этим полям. Но опять таки, теряется гибкость. В итоге мы пытаемся использовать реляционный подход к noSQL базам, что в корне неверно.
Я с JSONb очень много работал на огромном портале недвижимости. Очень много чего мы туда позапихивали и радовались, ровно до тех пор, пока бизнес не стал ставить задачи по агрегациям и вычислениям, с кучей пересечений по другим json полям. Запросы тогда реально превращались в десятиэтажных монстров. В итоге, часть полей пришлось переписать в отдельные таблицы со своими строгими полями. Этот формат очень крут и удобен, но нужно осторожно с ним работать, так как в будущем может понадобиться что-то сложное делать с данными и тогда работа превратится в огромную проблему.vsb
21.10.2018 01:45Спасибо, я тут больше теоретик, сама идея JSON мне очень нравится, т.к. обычно люди тупо сериализуют Java-объект и кладут в базу какую-то байтовую кашу-малашу или придумывают свои доморощенные разделённые запятыми форматы, конечно же обрабатывая это всё в приложении или в километрах хранимок, но на практике пока применять не приходилось, всё жду. Вот недавно почти посоветовал, но там хипсторы на Mongo решили всё делать, сдалась им эта монга.
Kirill_Dan
21.10.2018 12:28+1Монга штука хорошая, но опасная. Завтра бизнес скажет, а я хочу иметь всю сводную статистику по запросам к странице, по закачке данных, по кликам на баннера и т.д. И прогеры почешут репу, и начнут разбегаться кто куда.
Поэтому постгрес очень подходящая база для разных смешанных типов данных. Я до сих пор вижу, как народ мучается с построением деревьев с помощью кучи библиотек и костылей, хотя у постгреса есть отличный фомат ltree. Народ до сих пор строит какие-то решения из говна и палок для работы с географией, хотя у постгреса мощный функционал для работы с локациями и.т. Да, постгес после mySQL кажется громадным и сложным монстром, но для энтерпрайз проектов он решает громадное количество задач на уровне самой базы, а не кода. А монга — это что-то хипстерское, на которую был в одно время огромный спрос, который стал сходить на нет, так как многие уже наобжигались с ней. Особенно, когда работали с заказчиком по agile. Сегодня одни требования (точно, при точно), а завтра все переигралось (бизнес платит деньги, поэтому поджали яйца, делаем, что вам говорят).
Igor_Le Автор
22.10.2018 15:44Вообще по JSON/JSONB давно написаны 3 больших патча:
SQL/JSON: jsonpath
SQL/JSON: functions
SQL/JSON: JSON_TABLE
но их никак не закоммитит сообщество. О них есть вот здесь: obartunov.livejournal.com/200076.html
GilevVyacheslav
19.10.2018 20:30а если можно будет передавать секцию от одной таблицы к другой то будет вообще замечательно
Andronas
20.10.2018 12:29А что там нового в области бэкапа и ресторе? Можно уже делать восстановление отдельных tablespace?
ZOXEXIVO
20.10.2018 15:36-2Релизы PostgreSQL все унылее и унылее, зато на конференциях любят сообщать, что скоро захватят мир и круче нас никого нет. На деле получаем что-то непонятное и это видимо то, с чем хотели поиграться разработчики сообщества больше всего.
Очень напомнило релиз Angular 7, где сообщество опять прокатили с нужными фичамиlinux_art
22.10.2018 10:01Не знаю как вы, а лично я ждал секционирования по хешу с возможностью смены секции для строки во время апдейта.
impwx
21.10.2018 12:39В инсталляторе 11 версии от BigSQL лежит pgAdmin 3, который, внезапно, не работает с 11 версией.
linux_art
22.10.2018 10:00Он и с 10ой какбы не работает, но работает.
impwx
22.10.2018 10:30Оригинальный, возможно, не работает. Ребята из BigSQL же делают свою LTS-версию, которая поставляется в комплекте и по определению работать должна. Но в этот раз что-то пошло не так…
linux_art
22.10.2018 11:05Оригинальный заявлено что не работает с 10кой, но при этом с небольшой руганью он работает. А в чем выражается что не работает с 11ой?
chemtech
22.10.2018 08:53Igor_Le В сообществе есть идеи по выводу в логи рекомендательных сообщений по оптимизации PostgreSQL?
Например:
PostgreSQL упирается в диск — нужно установить диск/хранилище побыстрее
PostgreSQL не хватает памяти work_mem — нужно увеличить work_mem
Структура вашей таблицы/бд неоптимальна — лучше примените другую структуру
и т.п. и т.д.Igor_Le Автор
22.10.2018 14:27Насколько мне известно, пока лишь робкие попытки поднять этот вопрос. В ближайшее время вряд ли что изменится.
6pirule
Сегодня уже обновился. Спасибо за websearch_to_tsquery!