LINUX.ORG.RU

UPSERT и не только. Что ждать от PostgreSQL 9.5?

 


5

6

2 июля вышла PostgreSQL 9.5 alpha. Среди основных улучшений можно отметить:

  • BRIN-индексы («индексы блоковых зон»), позволяющие сверхкомпактно индексировать очень большие таблицы.
  • Существенные оптимизации скорости сортировки и хэширования в памяти.
  • Автоматизированное управление размером лога транзакций.
  • INSERT ... ON CONFLICT UPDATE, также известный как «UPSERT».
  • Аналитические функции CUBE и ROLLUP.
  • Безопасность строкового уровня (Row-Level Security, RLS).
  • Новые манипуляционные возможности (функции и операторы) для типа данных JSONB.
  • Инструмент pg_rewind и другие улучшения репликации и средств повышения отказоустойчивости.
  • Множественные улучшения в механизм Foreign Data Wrappers, включая IMPORT FOREIGN SCHEMA.
  • Существенные улучшения масштабирования на системах с большим количеством процессорных ядер и оперативной памяти.

Статья «UPSERT и не только. Что ждать от PostgreSQL 9.5?» расскажет о некоторых новинках подробнее.

Скачиваем

What's New (англ.)

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



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

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

Кстати, судя по тому, что они там наворотили и каких изменений наделали, крайне не рекомендую применять в бою версию 9.5 и дождаться следующего мажора + с несколькими обновлениями. Один WAL чего стоит, не говоря про кучу других мест.

В 9.6 ещё больше будет.

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

Мы как раз от Оракла отказываемся в пользу LevelDB.

Отказываться от полноценной реляционной СУБД в пользу key-value store? И задачи вполне это терпят? Вашего проджект-менеджера тогда на мыло, который под эти задачи ажно целый Оракл в своё время выбрал.

Wizard_ ★★★★★
()

Надеюсь в 9.6 примут мой патч и будем всем любителям тегов радость. https://commitfest.postgresql.org/5/253/

anime-pictures.net уже перевёл на query_int правда пока на 9.4.

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

а вот Крон, ЕМНИП, как-то тестировал производительность мускуля и пострге при дефолтных установках(без тюна), и мускуль выигрывал.

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

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

Я часто встречал «не умею декомпозировать, нормализовывать» = «не поддаётся декомпозиции и нормализации». Я не был бы уверен, что если бы другой специалист взялся бы за задачу, то он не смог бы её решить.

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

От человеческой глупости, возможно.

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

Интересно, отчего у фанатов Postgre такой лютый баттхёрт? :)

У фонатов от всего батхёрт, когда чуть пахнет критикой. Например, у фонатов C++ батхёрт когда они где-то внутри себя понимают, что C++ - это «C + доп. проблемы», у фонатов Postgre бомбит при умопинании слова «VACUUM», у Mysql-щиков батхёрт от «СУБД для похапешников» и т.д. Фонатизм - это дело такое :-)

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

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

Поделитесь внятным руководством по подстройке, пожалуйста.

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

не надо банить человека только за то, что он идиот. надо переводить его в рид-онли.

SevikL ★★★★★
()

Ну и молодцы! Подождем релиза и проапгрейдимся.

UPSERT — хорошо, про RLS — интересно, но что-то из практики, я что-то не припомню, что бы в базу все ходили «от себя». Обычно, в базу идет какое-нибудь приложение, типа CGI-сценария или сервера приложений. Но возможность полезная.

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

отчего у фанатов Postgre такой лютый баттхёрт

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

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

в базу идет какое-нибудь приложение, типа CGI-сценария

Звонили девяностые, просили свои CGI-скрипты обратно.

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

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

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

но что-то из практики, я что-то не припомню, что бы в базу все ходили «от себя»

Это потому что почти все так делают, но так делать неправильно.

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

Поделитесь внятным руководством по подстройке, пожалуйста.

Книжка Алексея Борзова, например.

...По умолчанию PostgreSQL сконфигурирован таким образом, чтобы он мог быть запущен практически на любом компьютере и не слишком мешал при этом работе других приложений. Это особенно касается используемой памяти. Настройки по умолчанию подходят только для следующего использования: с ними вы сможете проверить, работает ли установка PostgreSQL, создать тестовую базу уровня записной книжки и потренироваться писать к ней запросы. Если вы собираетесь разрабатывать (а тем более запускать в работу) реальные приложения, то настройки придётся радикально изменить...

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

Спасибо, дружище. Сейчас вроде и так работает, но мысли о тюнинге приходили. Видимо, нагрузка позволяет )))

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

Ну а кто сказал, что база там же, куда приходят пользователи?

Синхронизация пользовательских аккаунтов на многих хостах — тема долгая, обсуждению почти не поддается :)

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

Даже в случае толстого клиента, наверняка у него в пузе в конфиге прописан dbuser=имярек. :)

Не обязательно. Управление пользователями вполне может быть встроено в БД.

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

Долгая дискуссия получиться может. И не по теме.

АеслиещеиВындовз + удаленные пользователи с мобильных телефонов? :)

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

Может. А может и не быть. Вот тут коллеги предложили LDAP. Авторизация клиента может происходить раньше обращения в базу.

Тут, наверное, стоит согласиться с тем, что если каждый пользователь ходит в базу «под собой» ,то оно и хорошо. Правда, этот подход добавляет геморроя по раздаче ролей для DBA.

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

Ну вот будем с Вами систему проектировать, тогда и обсудим :)

Обращайтесь.

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

АеслиещеиВындовз + удаленные пользователи с мобильных телефонов? :)

LDAP!

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

где ты это увидел?

По всей теме, с самых первых сообщений :)

Шлак наподобе MySQL и рядом с ней не стоял [при чём без всякого повода, сразу видно, что баттхёрт]
Без этой картинки новость не полна
mysql - полное УГ
Лошару найти проще, а не специалиста. Специалист по БД будет хорошо разбираться в теории БД
В таком случае может быть есть смысл взять SQLite3
эта перделка научилась выдавать 500k tp/s на одной машине? этой перделке уже доверяют расчет зарплаты?
Какой дурак будет доверять свои данные дырявой базе, у которой даже SQL-парсер реализован с багами?

и т.д.

народ верно заметил, что дефолтные настройки потребления памяти у постгреса крайне консервативные

А, я до этого даже не дочитал :)

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

По всей теме, с самых первых сообщений :)

то были не фанбои постгреса, а хэйтеры майскла :) и, надо сказать, многие претензии к майсклу справедливы. но это тема иного разговора, а я не уверен, что ты будешь толковым собеседником.

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

то были не фанбои постгреса, а хэйтеры майскла :)

Доля пересечения оных, как показывает практика, болезненно высока :)

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

Я не был бы уверен, что если бы другой специалист взялся бы за задачу, то он не смог бы её решить.

Поддается, и еще как. Но вот выхлопа от декомпозиции там больше чем вреда.

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

Решается такая проблема элементарно.

Но не реляционной моделью. Речь не была о преимуществах монги перед РСУБД. Речь шла о том, что реляционная модель не всегда применима в чистом виде.

RedPossum ★★★★★
()
Ответ на: комментарий от X-Pilot

Это еще почему?

Потому, что веб-сервер должен в ХТТП-заголовке кодировку сообщать, а в сам контент её вшивать не стоит.

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

Потому, что веб-сервер должен в ХТТП-заголовке кодировку сообщать, а в сам контент её вшивать не стоит.

WEB - это такая каличная технология, что «совершенно правильно» что-либо надо делать всеми возможными способами. Так, на всякий пожарный. Так что «совершенно правильно» включать как meta, так и выставлять Content-Type.

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

Ну да, пришли всякие визги, Томкаты, руби с рельсами и прочий FastCGI. Суть не меняется.

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

anonymous
()

Oracle packages?

Тут в треде кто-то искал замены pl/sql packages, так практически без потерь можно просто использовать обычные нормальные схемы (которые к слову говоря есть почти у всех нормальных БД, кроме Oracle - у этих использование схем это будет такой ад из синонимов и постоянно отваливающихся прав). Схемы это группировка не только таблиц, но и функций ('хранимых процедур'). Более того это гораздо более логично группировать вместе таблицы и функции, а не держать таблицы в базе, а рядом pl/SQL packages.

akira_ag
()

С хабры

А в PostgreSQL нет сжатого формата для баз данных? В современных версиях MySQL есть, InnoDB row format = compressed

makoven ★★★★★
()

Прогресс

Молодцы, что наконец-то до MYSQL «insert .. on duplicate key update ..» додумались. Я даже не догадывался, что в PostgreSQL такого нет.

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

Но не реляционной моделью.

Ну-ну. К реляционной модели, также как, например, к модели OSI, нельзя подходить буквально.

Кроме того, где ты в моём примере увидел отход от реляционной модели? Всё в высшей степени нормальненько... А то что композитный тип используется, дык, строка — композитный тип.

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

Или еще пример, у нас есть документ со 100500 полями, который никогда не меняется, а для его визуализации нужна львиная доля данных. Что будет более «реляционно»: создавать кортеж размером 100500 или сделать отдельные поля для индексов, а остальное засунуть в блоб/композитный тип/JSON?

И примеров таких — масса. Я уже писал здесь, самые большие проблемы реляционной модели — реализация квази 1-1 связей, из-за чего база резко обрастает триггерами/констрейнтами/хранимками, а аналитические запросы очень быстро превращаются в полнейший ад.

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

Кодировка должна быть одна — UTF-8. И её стоит вшивать везде, где только можно. И в контент и в заголовок.

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

Доля пересечения оных, как показывает практика, болезненно высока :)

По-моему, это немного разные причины и следствия.

Я, помню, возненавидел mysql 3.xx, когда попытался в него логи апача завернуть. mysql крякнул.

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

php

в следующей мажорной версии PHP ...ввести строгую типизацию

вангую, что тут-то ему полярный лис и придёт! :-)

mumpster ★★★★★
()

Слон гораздо круче мускуля :-)

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

default HW

Дефолтные настройки postgresql...на любом оборудовании

именно так!

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