LINUX.ORG.RU

PostgreSQL 9.6

 


2

3

29 сентября был представлен новый выпуск реляционной СУБД PostgreSQL.

Данный релиз предоставляет пользователям широкие возможности как для вертикального, так и для горизонтального масштабирования нагрузок на базы данных.

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

Добавленная поддержка параллелизации некоторых операций позволяет одновременно использовать несколько или даже все доступные ядра процессора для ускорения ответа на запрос. На данный момент имеется возможность параллелизации последовательного чтения (таблиц), операций соединения и агрегирования, что, в зависимости от конкретной ситуации и доступности ядер, делает возможным ускорение обработки запросов вплоть до 32 раз при работе с Big Data.

В механизм синхронной репликации были добавлены две новые опции, с помощью которых можно обеспечить согласование операций чтения в масштабе всего кластера баз данных. Во-первых, теперь стало возможным конфигурировать группы реплик, работающих с синхронной репликацией. Во-вторых, режим remote_apply позволяет получить согласованное представление данных на масштабе нескольких узлов. Всё это работает на основе встроенного механизма репликации и предназначено для получения массива «идентичных» узлов серверов баз данных для балансировки нагрузки, содержащей операции чтения.

Также системой полнотекстового поиска в PostgreSQL теперь поддерживается так называемый «фразовый поиск». С его помощью пользователи, используя GIN-индексы, могут находить точные совпадения по фразам, а также документы, где слова встречаются на заданном удалении друг от друга. Получив также новые возможности тонкой настройки полнотекстового поиска, PostgreSQL становится высококачественной системой «гибридного поиска», что подразумевает возможность одновременного использования различных типов данных и операций поиска по ним: реляционного, JSON и полнотекстового.

Благодаря обратной связи и тестированию на базах данных большого объёма проекту успешно удалось улучшить производительность и юзабилити. Репликация, операции агрегирования, индексирования, сортировки и хранимые процедуры стали эффективнее, а сам PostgreSQL теперь более продуктивно использует ресурсы при работе с новыми версиями Linux. Накладные расходы при администрировании больших таблиц и работе с нагрузками сложного профиля также уменьшились — в частности, за счёт улучшений механизма VACUUM.

Стоит также упомянуть, что 4 октября состоится очередная встреча российского сообщества #RuPostgres (#PostgreSQLRussia) в офисе Яндекса в Москве. Планируется онлайн-трансляция. Участие бесплатное, необходима предварительная регистрация.

Более подробную информацию о новых возможностях PostgreSQL (на английском языке) можно найти по ссылкам ниже.

Информация об изменениях

Что нового в PostgreSQL 9.6

Матрица возможностей

Основные возможности (слайды)

«Заглянем слону под хобот: 9.6» (видео)

Производительность PostgreSQL 9.6 (видео)

Вебинар с обзором новинок от Брюса Момджана

>>> Официальный пресс-релиз



Проверено: Klymedy ()
Последнее исправление: cetjs2 (всего исправлений: 14)

Ответ на: комментарий от menangen

PgTune

Для небольших нагрузок вам с лихвой хватит PgTune: http://pgtune.leopard.in.ua/ — вбиваете, сколько у вас RAM и он вам выдаёт оптимальные настройки.

Помните, что Postgres полагается на кэши ОС, поэтому сразу всю RAM жрать не будет, но при работе активно заиспользует кэш ФС.

Envek
()
Ответ на: комментарий от AlexM

Нет, конечно. Так как он делает можно делать только на проектах уровня localhost.

На данный момент единственное возможное решение без downtime, это логическая репликация от стороннего проекта - ее нет в ваниле. (статью только написали, только увидел :-) http://blog.2ndquadrant.com/untangling-the-postgresql-upgrade/)

pg_dump никогда не используйте!

uspen ★★★★★
()
Ответ на: комментарий от uspen

Так как он делает можно делать только на проектах уровня localhost.

Да ладно, зависит от размера базы и допустимого downtime.

На данный момент единственное возможное решение без downtime, это логическая репликация от стороннего проекта - ее нет в ваниле.

Проще всего, наверное, от того же проекта: https://2ndquadrant.com/en/resources/pglogical/

anonymous
()
Ответ на: комментарий от anonymous

Да ладно, зависит от размера базы и допустимого downtime.

Ну, кажется, что вопрос был как раз про продвинутые случаи и продвинутых граждан. Давеча нам в требованиях озвучили необходимость функционирования 24x7 (365/366). А в остальное время, дескать, можно регламентные работы проводить.

За ссылки, кстати, большое спасибо. Правда, нужно ещё будет понимать, что там с поддержкой расширений типа postgis'а.

AlexM ★★★★★
()

Подскажите кто юзает в продакшене. Раньше была проблема с VACUUM на более менее больших базах от 50-100 гигабайт, сейчас как с этим?

Sn0WLi9ht
()
Ответ на: комментарий от uspen

Так downtime нет, другое дело что dump снимает базу на момент дампа, транзакции которые не завершились на момент дампа, туда просто не попадут. А делать репликацию просто в другой контейнер, а не на географически расположенный в другом месте физический сервер, я смысла не вижу, потому-что если что случится с физическим сервером, то все равно все умрет. За время pd_dump все равно там ничего существенно не меняется, еще не знаю кто бы так данные потерял. Заморачиваться сильней актуально только если эти транзакции за несколько секунд pg_dump реально нужны. Ну или если база в несколько Тб. Или там процессинг какой-нибудь или обменник.

anonymous_sama ★★★★★
()
Ответ на: комментарий от Sn0WLi9ht

Раньше была проблема с VACUUM на более менее больших базах от 50-100 гигабайт, сейчас как с этим?

Это на каких версиях?

EuGeneus ★★
()
Ответ на: комментарий от uspen

Смотря для чего. Для полного регулярного backup точно нет

Для продуманного частичного ежедневного - точно да

EuGeneus ★★
()
Ответ на: комментарий от TurboPascal55

Оракл может и постгрес продавать.

Deleted
()
Ответ на: комментарий от EuGeneus

Не умеют. Не более, чем остальные. Просто слезать трудно, вот и тащим за собой этого мамонта.

TurboPascal55
()
Ответ на: комментарий от anonymous_sama

После того как версия становится стабильной

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

autonomous ★★★★★
()
Ответ на: комментарий от dmxrand

А потом этот далёкий Ракель печеньками угощает и сеет демократию по всему миру.. Думаю не стоит ему скидываться на печеньки.

asm64kmr
()
Ответ на: комментарий от autonomous

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

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

anonymous_sama ★★★★★
()
Ответ на: комментарий от targitaj

Физический тип резервного копирования - basebackup. Его реализует штатная утилита pg_basebackup (всегда используйте ключ --xlog-method=stream).

Удобный менеджер, который превосходит по возможностям менеджера barman, называется pgBackRest, правда он пока не умеет pg_receivexlog, но другие его фичи с лихвой перекрывают этот недостаток.

uspen ★★★★★
()
Ответ на: комментарий от anonymous_sama

проходят без моего участия, автоматически

зря-зря

autonomous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.