LINUX.ORG.RU

Вышел PostgreSQL 9.5!

 


1

4

7 ЯНВАРЯ 2016: Всемирная группа разработки PostgreSQL объявляет о выходе PostgreSQL 9.5. В этом релизе представлены такие возможности как UPSERT, безопасность на уровне строк (Row Level Security) и ряд функций для работы с большими данными (Big Data) — всё это призвано увеличить число пользователей самой развитой системы управления базами данных (СУБД) с открытым исходным кодом. Новый PostgreSQL — отличный выбор для самого широкого круга стартапов, крупных корпораций и государственных организаций.

Анни Прево (Annie Prévot), ИТ-директор в CNAF (Национальная касса семейных пособий, государственная организация во Франции), рассказывает: «Организация CNAF предоставляет услуги 11 миллионам человек, распределяя 73 миллиарда евро ежегодно, обеспечивая 26 видов различных компенсаций. Такой сервис очень важен для населения и в основе его — информационная система, которая должна быть абсолютно эффективна и надёжна. ИТ-система организации CNAF успешно использует PostgreSQL в качестве системы управления базами данных.»

UPSERT

«UPSERT» — сокращение от «INSERT, ON CONFLICT UPDATE» (дословно «вставка, а в случае конфликта — обновление») — функциональность, вот уже несколько лет наиболее ожидаемая в среде разработчиков приложений. Эта возможность позволяет рассматривать новые и обновляемые строки таблицы как некую единую сущность. UPSERT упрощает разработку мобильных и веб-приложений, возлагая задачу разрешения конфликтов при конкурентных операциях на плечи самой СУБД. Эта функциональность также устраняет последний существенный барьер для миграции приложений с MySQL на PostgreSQL.

Разрабатываемая в течение двух лет программистом компании Heroku Питером Гейганом (Peter Geoghegan), реализация UPSERT в PostgreSQL является существенно более гибкой и мощной, чем те, что предлагаются другими реляционными СУБД. Новое предложение ON CONFLICT позвляет игнорировать новые данные или же обновлять другие столбцы или таблицы таким образом, который будет совместим с комплексными ETL-решениями (Extract, Transform, Load — дословно «извлечение, преобразование, загрузка») для массовой загрузки данных. И, как и всё в PostgreSQL, это решение абсолютно безопасно с точки зрения конкурентного доступа и может использоваться в совокупности с любыми другими возможностями системы, включая Логическую репликацию (Logical Replication).

Row Level Security

PostgreSQL продолжает расширять возможности по обеспечению безопасного доступа к данным, на этот раз за счёт безопасности на уровне строк (Row Level Security, RLS). RLS реализует полноценный контроль за доступом на уровне отдельных строк и столбцов, который также может быть интегрирован с внешними системами управления доступом, такими как SE Linux. PostgreSQL уже хорошо известна как «по умолчанию максимально защищённая» система. RLS закрепляет эту позицию, являясь отличной возможностью для приложений с высокими требованиями безопасности — например, когда требуется соблюдать нормы PCI (приложения, обрабатывающие данные кредитных карт), законов Евросоюза о защите персональных данных (European Data Protection Directive), а также стандартов защиты медицинских данных.

RLS — кульминация пятлетнего развития возможностей безопасности в PostgreSQL, включающего обширную работу, проделанную Кай-Гаем Кохей (KaiGai Kohei) из японской корпорации NEC, Стефеном Фростом (Stephen Frost) из Crunchy Data, и Дином Рашидом (Dean Rasheed). Теперь администраторы баз данных могут устанавливать «политики» безопасности (security «policies»), фильтрующие доступ для определенных пользователей к определённым строкам — как на обновление, так и на чтение. Реализованная таким образом модель безопасности предоставляет улучшенную защиту данных от SQL-инъекций и других проблем безопасности уровня приложений.

Работа с Big Data

PostgreSQL 9.5 содержит сразу несколько новых возможностей для больших баз данных и для интеграции с другими системами, известными как «Big Data». Это позволяет PostgreSQL и впредь занимать сильные позиции на стремительно растущем рынке открытых систем для Big Data. Среди новинок стоит выделить следующие.

BRIN-индексы. Этот новый тип индексов позволяет создавать крошечные, но эффективные индексы для очень больших таблиц, данные в которых «естественным образом упорядочены». Например, таблицы, содержащие данные системных журналов с миллиардами строк, могут быть проиндексированы и просканированы всего за 5% от времени, которое требуется для стандартных BTree-индексов.

Ускоренная сортировка. Теперь PostgreSQL сортирует текстовые данные и данные типа NUMERIC быстрее, используя алгоритм «сокращенных ключей». Это ускоряет некоторые запросы, требующие сортировки больших объёмов данных, от 2-х до 12-и раз и может ускорить создание индексов до 20-и раз.

CUBE, ROLLUP и GROUPING SETS. Эти новые предложения стандартного языка SQL позволяют пользователям создавать отчёты с несколькими уровнями подведения итогов в одном-единственном запросе. Предложение CUBE также позволяет тесно интегрировать PostgreSQL с бо́льшим числом инструментов создания OLAP-отчётов (Online Analytic Processing) — таких как Tableau.

Адаптеры внешних данных (Foreign Data Wrappers, FDW). Этот функционал и ранее позволял использовать PostgreSQL как среду для запросов к другим «Big Data»-системам — например, Hadoop и Cassandra. В версии 9.5 добавлены команда IMPORT FOREIGN SCHEMA и JOIN-вытеснение (JOIN pushdown), что делает запросы к внешним базам данных как более лёгкими в установке, так и более эффективными.

TABLESAMPLE. Это SQL-предложение позволяет быстро получить статистическую выборку для огромной таблицы без необходимости ресурсоёмкой сортировки.

«Новые BRIN-индексы в PostgreSQL 9.5 — это мощная новинка, позволяющая PostgreSQL индексировать такие объёмы данных, которые ранее было непрактично либо невозможно обрабатывать. Расширяемость данных и производительность выходят на такие уровни, которые ранее считались недостижимым для традиционных реляционных баз данных. Это делает PostgreSQL превосходным решением для аналитики в области Big Data», — рассказывает Бойан Ботев (Boyan Botev), ведущий администратор баз данных в Premier, Inc.

О проекте PostgreSQL

PostgreSQL является ведущей СУБД с открытыми исходными текстами с глобальным сообществом из тысяч пользователей и разработчиков, объединяющим множество компаний и организаций. Проект PostgreSQL создаётся на основе более чем 25-летнего опыта проектирования и разработки, начавшейся в Калифорнийском университете Беркли, и в настоящее время разрабатывается беспрецедентными темпами. Продуманный набор возможностей PostgreSQL не только не уступает ведущим коммерческим СУБД, но и зачастую превосходит их развитой функциональностью, расширяемостью, безопасностью и стабильностью. Вы можете получить дополнительную информацию о PostgreSQL и присоединиться к нашему сообществу по адресу http://www.postgresql.org.

Ссылки

Страница загрузки

Материалы для прессы

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

Обзор новых возможностей версии 9.5 (англ.)

Контакт для прессы: Николай Самохвалов, ru@postgresql.org

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



Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 4)

Поздравляю! Замечательная СУБД. Им бы еще веб-сайт обновить на современную морду с выходом версии 10.

FilosofeM ★★
()

Отличная новость, спасибо большое разработчикам! UPSERT очень давно хотелось.

Sectoid ★★★★★
()

Читаю заголовок «Вышел PostgreSQL 9.5». Сразу ловлю себя на мысли, куда он может выйти, он же памятник.

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

Им бы еще веб-сайт обновить на современную морду

Современную - это со свистоперделками и тормозами? Нет, спасибо, нынешняя просто работает.

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

Наверно хорошая новость для тех, кто юзает PostreSQL.

Новость просто фееричная, если я правильно понимаю...
Иначе зачем в заголовке ставить восклицательный знак?

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

Нет, спасибо, нынешняя просто работает.

Нынешнюю нужно под лупой читать. Хоть бы шрифт увеличили.

anonymous
()

Да. Давно ждал UPSERT. Сейчас немного перепишу бекэнд, и забуду о велосипедах с insert(id) , select (id), update (id).

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

Не знаю как оно здесь.

Но в MariaDB при INSERT ON DUPLICATE KEY UPDATE, если частые вставки и частые конфликты, то autoincrement растет как на дрожжах. Упереться в потолок как 2 байта переслать. Приходится делать через транзакции + select && update || insert.

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

А что мешало раньше делать через CTE?

AnDoR ★★★★★
()

Хорошая новость! Про грядущий UPSERT давно говорилось. Что же, будем апгрейдится... :)

gns ★★★★★
()

Шикарные фичи. Не понимаю, как можно пользоваться мускулем при наличии постгреса.

unC0Rr ★★★★★
()

ююхуу, upsert и BRIN-индексы!

val-amart ★★★★★
()
Ответ на: комментарий от surefire

Хм, любопытно, а как ты понял что оно переполнилось? Запросы возвращали ошибку или же счётчик обнулился и натворил дел? Хочется верить что первое.

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

Можно в двух словах, что такое UPSERT? Эта команда была в стандарте изначально или это расширение стандарта?

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

Таблица не очень большая всего чуть больше 100 000 строк. Давно было, точно не помню, но вроде бы я успел до часа икс произвести ALTER TABLE. Уникальных данных которые больно терять там почти нет, так актуальное за последние пару часов. Меня насторожило, что autoincrement дико несоразмерен количеству строк и перепрыгнул миллиардный рубеж. Начал разбираться и выяснил, что всему виной INSERT ON DUPLICATE KEY UPDATE. Поспрашивал гугла, и он вывел на статьи с похожими проблемами. Кстати INSERT IGNORE работает подобным образом. То есть всегда autoincrement увеличивается и для вставки выделяется новый id, а уже потом либо да, либо нет. Уже несколько лет работает и обновляется круглые сутки и id всего около 150 000. Если б не избавился от INSERT ON DUPLICATE KEY сколько бы сейчас было миллиардов. Ну и надо не забывать, что кроме СУБД на огромных числах может споткнуться и софт который обращается к базе.

surefire ★★★
()
Последнее исправление: surefire (всего исправлений: 1)

PostgreSQL 9.5

пожалуй забью на 9.5 и подожду десятую версию, а потом забью и на нее

gray ★★★★★
()

дуал-мастер репликацию версии к двадцатой можно ждать? а мульти-мастер к пятидесятой, наверное.

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

Казалось бы, для этого нужен всего лишь MS SQL.

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

Возможно, вы хотели сказать: «кортежей»

Ага, и «отношения» обозваны «таблицами». Какой безграмотный, вызывающий отвращение текст!

anonymous
()

О, отлично! Развивается в правильном направлении!

Сейчас я Постгресом уже не пользуюсь по работе, но раньше всегда старался его продвигать.

Кстати, там есть какие-то подвижки в сторону in-memory?

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

дуал-мастер репликацию версии к двадцатой можно ждать? а мульти-мастер к пятидесятой, наверное.

Угу, и чтоб задержки и консистентность были как на одной ноде.

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

Расскажи свой реальный юзкейс. А то тут из зала подсказывабт, что ты за кем-то повторяешь одну и ту же мантру, значение которой не понимаешь совсем.

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

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

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

Посмотрите на нынешнюю страницу gentoo.org, вот так и нужно обновлять дизайн.

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

дуал-мастер репликацию версии к двадцатой можно ждать? а мульти-мастер к пятидесятой, наверное.

дуал мастер - ХЗ. не требовалось.

а мульти-мастер уже сейчас продумывают. так что через год будет превью, через два выйдет релизом.

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

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

На каждый коммит еще фсинк по ФС пройти должен. Даже если сеть дает нулевую задержку, что не реально для Ethernet, и пропускную способность в потолок, все равно будут тормоза на консистентность.

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

Так вот запись/обновление этого файла это еще один фсинк. Затрат на запись данных - мало, а вот честные фсинки будут жрать кучу времени.

Итого хранилище заткнется на фсинках.

VoDA ★★
()

UPSERT это как Пифагор для фанбоев INSERT-а

anonymous
()

Бывает утекают телефонные базы, но интересно - а можно ли сделать так чтобы какой-то конечный терминал не мог получать больше сведений чем раз в N минут? И если лимит превышен чтобы админы обращали внимание. Мне кажется так базы не будут утекать через конечные терминалы сотрудников... Я не в курсе как на самом деле, может RLS это как-то похоже на то что я предположил...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от VoDA

Файловые операции неизбежны при любом количестве нод. С волшебной сетью скорость работы N нод будет приблизительно равна скорости работы самой медленной ноды. Суть моего посыла в том, что сказки про всесильность мультимастера существуют только в сферическом вакууме голов диванных аналитиков. На практике CAP-теорема продолжает ограничивать полёт фантазии.

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

Ну как же, вот выше там Антон про MS SQL что-то пытался вякнуть. Видишь, у кого-то ещё бывают чудеса.

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

C-+ пробовал? Говорят ваще бомба!

Ну да, CSS и искусство создания комфортных интерфейсов меркнут на фоне C-+ и не нужны.

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

По инерции, разве что. Или из-за наличия самописных встроенных функций.

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

анонимной процедурой же, на оракле это просто, а вот в постгресе нельзя параметры в процедуру втыкать, а рисовать полноценную процедуру - дно

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

ну лично мне достаточно модели «enventually consistent» (такая там сейчас и есть по отношению к слейву). а в идеале нужно поддерживать и синхронную репликацию, и асинхронную. синхронная много где нафиг не сдалась, не все используют постгрес в банках и на ядерных электростанциях.

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