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)

А pgAdmin-то для 9.5 недоточили. Unsupported, говорят... :(

Ну догнут, будем надеяться.

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

Можно и закат солнца вручную устроить, только зачем? Придется еще учитывать прецессию орбиты Юпитера... :)

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

Вот на бете может и работает. А на релизе — нет.

20:37:55: Ошибка: Column not found in pgSet: rolcatupdate

И дальше падает с грохотом на каком-то ассерте с длинной простыней диагностики. Похоже, системные таблицы поменяли.

Надо как-то добавить служебные таблицы pgadmin'a, но до этого дело не доходит.

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

Это был не Антон. Имелся в виду, собственно, дуал-мастер, который, по моему мнению - изобретение MS SQL, сделанное «чтобы было» и в реале нужен он только MS-фанбоям (опять-таки IMHO))

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

А можно ли сделать сеть вообще без админов (людей с полными правами)? Вот в Штатах после Сноудена об этом позадумались всерьез. Пока будут люди с полным доступом к данным (неважно, админ это или DBA), проблема утечек данных не будет решена. Можно ведь и бекап базы скопировать - не обязательно с клиента ее тягать. Проблема, как обычно, в головах (людей), а не в технике - если можно что-то, имеющее коммерческую ценность, скопировать и продать - это будет продано. Здесь не немцы, которые сначала посчитают сумму своего заработка за 30 лет+льготы и за меньшие деньги даже думать о копировании и продаже не станут...

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

Версия 1.22.0 уже есть, скачиваем исходники, устанавливаем зависимости для сборки и собираем

И нет проблем )))

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

можно - end-point шифрование называется или шифрование на стороне клиента (client side encryption)

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

Собрал. Проблем, похоже, действительно нет... :)

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

JetBrains же недавно релизнули свой велик. Но он платный

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

вообще без людей с полными правами

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

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

А можно ли сделать сеть вообще без админов (людей с полными правами)?

Потенциально можно.

Это как СУБД где все данные шифрованы и никто, включая админа, не может получить доступ к данным без ключа. В бэкапе данные тоже шифрованы.

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

VoDA ★★
()

О, класс! Как раз думала что выбрать для проекта.

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

Мультимастер репликация работала в 90х на Sybase Anywhere - Sybase SQL server в любой конфигурации (связи между БД должны были быть графом без циклов, т.е. можно было сделать иерархию в виде дерева). А репликация работала как онлайн так и по е-мейлу и через файлы на дискетах. Эта возможность в бОльшей степени зависит от структуры БД, чем от встроенных в сервер Бд функций. Например, чтоб справочник клиентов можно было реплицировать на десяток ноутбуков, а потом введенных в 10 разных база новых клиентов загрузить без коллизий в общую БД, нужно сделать первичный ключ составным - из уникального идентификатора отдельной копии БД и локального (для экземпляра БД) автоинкрементного ключа. В Sybase AnyWhere были специальные типы триггеров для разрешения коллизий при репликации (чтобы не было рекурсивной вставки/обновления записей), но это можно обойти ценой добавления дополнительных служебных полей и таблиц.

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

Меня удивляет, почему все носятся с master-slave репликацией или dual-master как с писанной торбой. Можно практически на любом sql-сервере реализовать любую схему репликации, только нужно изначально проектировать бд под репликацию. Очевидно что никакой репликатор не сможет нормально сделать 2-стороннюю репликацию с 1с или любой бд созданной через ОРМ. Просто в них это изначально не закладывалось проектировщиками.

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

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

А причины можешь назвать?

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

Причины чего? Что не пользуюсь --- занялся кровавым Ънтерпрайзом, где Oracle и HANA. Что продвигал --- нормальный SQL, в отличие от.

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

сам гайдай

юморист, это Серый, а не Гайдай

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

Причины чего? Что не пользуюсь --- занялся кровавым Ънтерпрайзом

угу, этого.

где Oracle и HANA.
продвигал --- нормальный SQL, в отличие от.

А здесь подробнее, пожалуйста. Есть технологические причины, сильно большее удобство для пользователей или это продиктовано скорей политикой и популярностью oracle, hana? Есть какие-нибудь аргументы для узколобого менеджера, у которого слюна изо рта капает от показателей, которые рекламируются производителями этих БД и который норовит назвать тебя фанатиком за «нормальный sql»?

ps не флейма ради. интересно услышать мнение вовлеченного человека.

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

Очевидно что никакой репликатор не сможет нормально сделать 2-стороннюю репликацию с 1с или любой бд созданной через ОРМ.

А вот multi-master cluster вполне может работать. И даже для 1С или любого ORM. Теоретический профит: 1. масштабируемость из коробки - все мастеры параллельно обслуживают и писателей и читателей. Читатели легко скалируются. 2. поддержка любого софта из коробки - бизнесу нет нужды переписывать кривой софт. Поднял кластер СУБД и поехал. 3. отказоустойчивость из коробки - пока жива хотя бы одна нода (при соответствующем протоколе деградации кластера) система продолжает обслуживать пользователей.

На практике есть куча ограничений и нюансов, которые нужно учесть на уровне СУБД. Что затягивает появление адекватного решения.

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