LINUX.ORG.RU

PostgreSQL 10 вышел

 , , ,


1

3

5 октября 2017 Всемирная группа разработки PostgreSQL объявила о выпуске PostgreSQL 10, новой версии реляционной системы управления базами данных с открытым исходным кодом.

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

«Наше сообщество разработчиков сфокусировано на развитии таких свойств системы, которые позволяют наиболее полно использовать возможности современных инфраструктур с распределённым характером нагрузки», — говорит Магнус Хагандер (Magnus Hagander), член основной команды Всемирной группы разработки PostgreSQL. — «Такие функции как логическая репликация и улучшенный параллелизм исполнения запросов отражают годы работы и демонстрируют постоянный фокус сообщества на обеспечении лидирующей роли PostgreSQL в условиях растущих технологических требований».

С появлением данного релиза меняется схема версий PostgreSQL, новый формат — «x.y». Это означает, что следующее минорная версия будет 10.1, а следующий мажорный релиз — 11.

Логическая репликация — фреймворк для распространения данных по модели «публикация/подписка»

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

«Мы активно используем PostgreSQL, начиная с версии 9.3, и очень рады появлению версии 10, так как она содержит долгожданные возможности партиционирования и встроенной логической репликации. Это позволит нам использовать PostgreSQL в ещё большем количестве сервисов», — заявил Владимир Бородин, компания «Яндекс».

Декларативное партиционирование таблиц

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

Улучшенный параллелизм выполнения запросов

PostgreSQL 10 содержит улучшенную поддержку параллелизации выполнения запросов — ещё больше частей плана выполнения запроса теперь могут исполняться параллельно. Улучшения заключаются в том, что ещё больше типов операций сканирования данных поддаются параллелизации, а также в том, что в некоторых случаях (например, когда данные уже отсортированы) проводится дополнительная оптимизация. В итоге, пользователь получает данные намного быстрее.

Кворум-коммит для синхронной репликации

В PostgreSQL 10 появился кворум-коммит для синхронной репликации, обеспечивающий гибкость процесса оповещения основной БД о том, что изменения успешно записаны на удалённые реплики. Администратор может теперь указывать, что если определённое число реплик получило информацию об изменении, данное изменение можно рассматривать как надёжно зафиксированное.

«Кворум-коммит для синхронной репликации в PostgreSQL 10 даёт нам больше вариантов расширять нашу инфраструктуру баз данных с временем простоя работы приложений, стремящимся к нулю. Это позволяет нам непрерывно выкатывать изменения и обновлять нашу инфраструктуру без необходимости объявления длительных периодов обслуживания», — сказал Курт Микол (Curt Micol), инженер инфраструктуры в компании Simple Finance.

Аутентификация SCRAM-SHA-256

SCRAM (The Salted Challenge Response Authentication Mechanism), описанный в RFC5802, определяет протокол безопасного хранения и передачи паролей за счёт использования специального фреймворка для более строгого сопоставления паролей. В PostgreSQL 10 представлена поддержка метода SCRAM-SHA-256, описанного в RFC7677. Данный подход является намного более безопасным, чем существующий метод аутентификации с использованием MD5.

>>> Подробности



Проверено: leave ()

захватите власть над данными

На русский это лучше вообще не переводить, просто выкидывать. Пусть это остается в английском. Как идея?

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

мастер-мастера нет

касательно перевода: [парралельность] - суть улучшений не в том, что написано, а в том что 9.6 парралелил только скан данных, а 10 парралелит ещё и скан индексов (но походу только в 4 потока).

RC1 уже был вполне юзабелен, пара недель уже у меня в нагрузке в 70% от номинала (резервная система на нём живёт)

EuGeneus ★★ ()
Последнее исправление: EuGeneus (всего исправлений: 1)
Ответ на: комментарий от ashot

Для этого надо быть в теме.

Да и офф страничка для лайков больше, а не для технарей. Типа теперь на 16.87% круче и на 8.23% зеленее

P.S. Сам продукт клёвый. Но обидно, что я только-только почти всё до 9.6 вытянул, а тут 10 ;)

EuGeneus ★★ ()
Последнее исправление: EuGeneus (всего исправлений: 1)
Ответ на: комментарий от ashot

Кроме маркетологического булшита перевести нечего было?

Удваиваю.

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

anonymous ()

Это.... пусть меня не возьмут в Янденс, но!

«Мы активно используем PostgreSQL, начиная с версии 9.3, и очень рады появлению версии 10, так как она содержит долгожданные возможности партиционирования и встроенной логической репликации. Это позволит нам использовать PostgreSQL в ещё большем количестве сервисов», — заявил Владимир Бородин, компания «Яндекс».

Партиционирование у нас юзается года 3 как, ещё с 9.3. Ну правда оно на триггерах, но пашет же.

EuGeneus ★★ ()

Улучшенный параллелизм выполнения запросов: захватите власть над данными

PostgreSQL 10 содержит улучшенную поддержку параллелизации выполнения запросов — ещё больше частей плана выполнения запроса теперь могут исполняться параллельно. Улучшения заключаются в том, что ещё больше типов операций сканирования данных поддаются параллелизации, а также в том, что в некоторых случаях (например, когда данные уже отсортированы) проводится дополнительная оптимизация. В итоге, пользователь получает данные намного быстрее.

Это наверное здорово, но как оно сочетается с параллельным выполнением _разных_ запросов? Как и чем балансируется по ядрам? Трупут или латенси? Есть где внятное описание (кроме самого кода, конечно)

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

нет. я предлагаю это на русском вообще не писать.

Отлично, только за! Пусть этой БД, которой за всё время её существования никогда не было удобно пользоваться, не будет на российском рынке. Пусть остаётся уделом наивных «глобалистов».

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

Так вроде бы вся 1С на ней сидит же?

И? Это должно выглядеть как оправдание чрезмерного усложнения РСУБД? К тому же, 1С чаще сидит на MSSQL, чем на PgSQL. Иногда такая конфигурация имеет место быть даже в GNU/Linux среде, хотя это уже форменное извращение...

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

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

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

ну зачем так категорично?

На категоричное решение — категоричный ответ. Просто я из тех, кто принципиально не признаёт первичность английского языка. А так, кто бы против Open Source проекта?

удобство пользования - вещь не просто субьективная

Есть такое. Но тут ключевым моментом является количество телодвижений, необходимых, чтобы добиться от PgSQL того же результата, что и, скажем, от MySQL. C последним всё намного проще. Прямо говоря, PgSQL не масштабируема под задачу. Но это компенсируется наличием альтернатив.

синдроме утенка

Ну не скажи!) САБЖ весьма бородат)

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

Увы, она не всегда работает. Приходится сталкиваться с ТЗ, в котором PgSQL железобетонно прописана из-за личных предпочтений разработчиков смежного проекта, который (проект) успел занять выгодную позицию. Приходится писать прослойку под PgSQL, реализующую весьма упрощённый интерфейс. Это сколько времени приходится грохать из-за РСУБД избыточного функционала, применённого явно не к месту. А протаскивают его повсюду товарищи с куда большим проявлением «утёнка». И каждый раз, когда звучит название «Postgree SQL», это становится предвестником геморроя.

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

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

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

Если реально сильно надо мастер-мастер, почему не PostgresXL?

Ну просто реально, почти всегда анализ потребности в master-master показывает реальное отсутствие данной потребности.

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

Чоу какой упрощенный интерфейс я думал мы с базами данных на sql разговариваем. А насчет простоты mysql, так эта простоту в чем-нибудь серьезнее сайта, использующего десяток-другой сущностей, использовать становится нереально. Вообще странная очень претензия насчет сложности.

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

Если реально сильно надо мастер-мастер, почему не PostgresXL?

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

Ну просто реально, почти всегда анализ потребности в master-master показывает реальное отсутствие данной потребности.

Есть проект к которому выдвинуты очень жесткие требования к стабильности работы. Уже много лет трудится кластер на galera состоящий из 4-х и более нод. На всех этих нодах крутятся апликухи которые в основном читают с локальной MariaDB+galera, пишут туда редко. На фронтах железячные балансеры балансируют коннекты к апликухе на основании SNMP данных о загрузке проца + липкие сессии + данных о консистентности ноды. В итоге можно добавлять сколь угодно нод + выключать любые ноды на мейтененс, благополучно переживать почти любые железячные проблемы. Все это при условии что осталось минимум 2 живые ноды. При возникновении каких либо внештатных ситуаций, нода выбрасывается из кластера. При включении ноды после мейтененса, galera подтягивает diff базы, синхронизирует и включает ноду в кластер. Балансер видит что нода консистентна и включает ее в работу.

Возможно такое ТЗ можно было реализовать как-то иначе, но с подобной реализацией все счастливы долгие годы.

iron ★★★★★ ()