LINUX.ORG.RU

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

 


6

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 (англ.)

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

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

Т.е., сорри, я пукнул. Операционная система. (Файловая система - не СУБД, а система хранения.)

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

bullshit article

Я с автором полностью согласен

по ссылке - статья, полная bullshit (типичный кг/ам) сопсно, там в комментах всё сказано. что не отменяет картинки анонимуса, бгг.

mumpster ★★★★★ ()

SELECT COUNT(*) на табличках в каких-то 100 миллионов записей всё ещё считается по 10 минут? Тогда не нужно.

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

SELECT COUNT(*) на табличках в каких-то 100 миллионов записей всё ещё считается по 10 минут? Тогда не нужно.

486DX 33MHz не нужен.

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

Удивлению нет предела, правда? :-) Ведь ты и не догадывался, что СУБД является частным случаем ОС, а ОС - является, в частности, СУБД.

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

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

Забавно в этом то, что т.н. «фанбои» постгреса могут обоснованно сказать, чем именно плох mysql. А наоборот - нет.

AnDoR ★★★★★ ()

Foreign key constraint в массивах так и не сделали, скуки. Еще в 9.4 обещали.

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

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

SELECT reltuples FROM pg_class WHERE oid = 'schemaname.tablename'::regclass;


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

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

кстати, такое в природе раньше часто встречалось, например, DSM-11.Pick. Adabas. IMS.

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

для начинающего MySQL должна быть проще

Разве что большим количеством туториалов с кодом уровня

mysql_query("SELECT * FROM user WHERE name=$_POST['name']");
PolarFox ★★★★★ ()
Последнее исправление: PolarFox (всего исправлений: 1)
Ответ на: комментарий от AnDoR

Если запросы с WHERE, то постгрес умеет использовать для них индексы.

Это если эстиматор скажет, что результатов не очень много, а иначе SeqScan и все дела.

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

Можно ему принудительно хинтом сказать, чтобы использовал индекс.

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

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

Даже с учётом изоляции транзакций?

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

Можно ему принудительно хинтом сказать, чтобы использовал индекс.

можно конечно, но обычно не смысла, планировщик не просто так секскан выбирает, с индексом будет хуже.

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

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

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

Точный счётчик это вообще-то блокировка, либо он не будет точным :)

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

то будет более «реляционно»: создавать кортеж размером 100500 или сделать отдельные поля для индексов

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

no-dashi ★★★★★ ()

Репликации пусть пилят!!! Долбанулись уже в край со своим JSONB. Он вообще в рамках SQL-модели никуда не упирался.

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

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

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

Даже с учётом изоляции транзакций?

Какое принципиальное отличие данных о количестве записей в таблице от данных в самой таблицы? Вторые ведь как-то нормально работают с изоляцией транзакций.

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

Пожалуйста. Знакомство с базой данных

man hier

Первичное описание систем хранения данных

man filesystems

Начало работы с данными базы

man 2 open

Ну дальше ты понял :-)

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

Какое принципиальное отличие данных о количестве записей в таблице от данных в самой таблицы?

Отличие от записи в одном столбце или от всех записей в таблице? count(*) это агрегат по всей таблице. Он зависит от всех записей в таблице. Разные транзакции как правило работают с разными записями и нет проблем проводить их одновременно. Если одна транзакция захочет работать со всей таблицей (а это как раз случай count(*)), то проблемы с параллельностью других транзакций будут.

Вторые ведь как-то нормально работают с изоляцией транзакций.

Ну и count(*) нормально работает в Postgres. Претензия была к тому, что эта операция не работает достаточно быстро. sum(field) тоже не будет работать достаточно быстро, если на то пошло. Честно говоря у меня вообще сомнения в том, что в постгресе с этим есть какие-то проблемы. План такой:

  ->  Index Only Scan using table_pkey on table

Куда уж быстрей, чем посмотреть на индекс?

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

Какое принципиальное отличие данных о количестве записей в таблице от данных в самой таблицы?

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

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

Претензии к кроизводительности к count(*) предъявляют некомпетентные «специалисты», т.к. они не понимают, что с учётом MVCC, СУБД обязана выполнить подсчёт фактического количества строк, т.е. скорость подсчёта будет упираться банально в скорость чтения с системы хранения. Ни монга, ни жанга, ни панга, ни редиска, ни какая другая супер-пупер «база данных»-панацея для развесивших уши чайников это ограничение не обойдёт.

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

Репликации пусть пилят!!! Долбанулись уже в край со своим JSONB. Он вообще в рамках SQL-модели никуда не упирался.

Ты не туда командуешь. Логичнее скомандовать в pgsql-hackers@: «а ну ка, быстро пилите репликации!!1» Что касается JSON, то ему несказанно рады фонаты всяких этих ваших АнгуларДжэйЭс или НодэДжэйЭс, ибо «круто же прямо из базы данных получать в джэйсоне, а потом рЭнДэРиТь интэрфейс!!1» :-)

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

Ведь ты и не догадывался, что СУБД является частным случаем ОС, а ОС - является, в частности, СУБД.

Отберите у анонимуса крэк, а то у него упоротость критический порог в 1 Поттеринг перешла уже.

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

Забавно в этом то, что т.н. «фанбои» постгреса могут обоснованно сказать, чем именно плох mysql.

Да пофиг. Аргументированный фанбой и хейтер ничем в общении не отличается от неаргументированного фанбоя и хейтера :)

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

А ветер дует, потому что деревья ветками машут. :-)

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

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

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

А ветер дует, потому что деревья ветками машут. :-)

Нет. Но у меня под боком прямо сейчас ветер получается потому что лопастями крутит вентилятор.

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

А ты попробуй, обоснуй. Ты же, видимо, думаешь, что если нельзя волшебным образом доставать данные в табличном представлении с помощью select * from table where id = $1, то это уже не СУБД. Тебе, вероятно, сложно представить иерархию подкаталогов в файловой системе и файлы в них как базу данных. И ты, скорее всего, и не догадываешься, что тот же git работает именно с такой базой данных. К твоему сведению, не всем нужен скомпиленный бинарник, реализующий тьму-тьмущую функционала из, местами, бредового стандарта SQL. Некоторые в силах написать простенькую, специализированную СУБД и хранить данные в файлах, индексированных подкаталогами. Это для тех, кто, например, не считает MVCC или SQL или полнотекстовый поиск на основе snowball и GiST/GIN идеальными технологиями. Некоторые, как например, RethinkDB считают, что могут сделать гораздо более быструю СУБД, оптимизированную для SSD. Конечно, чтобы делать свои СУБД нужно иметь высокую квалификацию, но ты считаешь, что это не квалификация, а «упоротость, перешедшая критический порог». Ну что же, продолжай и дальше считать ПостгреЭсКуЭль верхом совершенства. :-)

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

Забористая у тебя трава, однако. Сравнивать ОС с СУБД - это что-то на уровне Птаага или даже выше.

cherry-pick ()
Ответ на: комментарий от Macil

Кроме того, где ты в моём примере увидел отход от реляционной модели?

Строго говоря, его нет, конечно. Вот тебе данные, вот отношения, реляционной. Это с одной стороны, а с другой, у тебя даже 1нф не выполняется. Ты можешь за уши притягивать сколько угодно, но это - денормализованные данные, нормальное инженерное решение с применением идей из реляционной модели. Но говорить о применимости реляционной модели в данном случае я бы не стал.

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

Забористая у тебя трава, однако. Сравнивать ОС с СУБД - это что-то на уровне Птаага или даже выше.

Не трынди. Я сказал, что «СУБД является частным случаем ОС». Это так, потому что согласно Википедии

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

Если ты посмотришь на функционал того же Постгреса, то ты обнаружишь для себя, что он подпадает под это определение. Если ты посмотришь на btrfs, то ты обнаружишь, что файловая система уже является, как это у вас принято говорить, «движком» для хранения данных с поддержкой btree-индексации, как у вас принято говорить, «искаропки». Так что я имею дерзость сравнить ОС с СУБД.

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

p.s. я не хейтер ;)

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

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

«фанбои» постгреса могут обоснованно сказать, чем именно плох mysql. А наоборот - нет.

Не являюсь фанбоем постгреса, но мне кажется тут вопрос поставлен не корректно. Тут не столько mysql плох, сколько постгрес выглядит лучше. Те же «хранимые процедуры» в постгресе это «first class citizen» в отличии от. Для меня по работе работать с процедурами на несколько тысяч строк - это естественное дело. Но в mysql процедуры выглядят как с боку бантик. По этому миграцию приложений на постгрес я себе представляю, а на mysql нет. Далеко не все и не всегда хранят логику в приложении. Да вообще постгрес выглядит куда серьезнее в разных мелочах. Но наверно если использовать минимум возможностей БД, то можно обойтись и mysql.

У постгреса есть большая проблема на мой взгляд - бесплатные средства для работы с ней еще та галиматья. То есть интерфейс с потенциальным пользователем налажен хреново. Думаю многие потыкавшись в баги pgadmin забивают на эту базу данных даже не добравшись толком до неё.

d9d9 ★★★ ()

ожидаемы следующие фичи

как в оракле tablespace, packages например

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

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

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

Чёрт! Через 7 лет использования постгреса я узнал, что кроме psql бывает ещё и вебморда! Собсна, нафига она была бы мне нужна...

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

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

Если серьёзно, то это появилось только в 11-м оракле, некоторые подвижки были ещё в 10-ке, но в 9-ке было очень мало чего в плане автотюнинга. Сколько потребовалось ораклу лет?

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

Нет. Но у меня под боком прямо сейчас ветер получается потому что лопастями крутит вентилятор.

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

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

Не трынди. Я сказал, что «СУБД является частным случаем ОС». Это так, потому что согласно Википедии

ФС можно рассматривать как некоторую СУБД, спору нет. и что? иерархическая база данных неструктурированной информации. при чём тут постгрес?

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

«Более реляционно» будет сделать таблицы «атрибуты» и «атрибуты документа»

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

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

SELECT COUNT(*) на табличках в каких-то 100 миллионов записей всё ещё считается по 10 минут?

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

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

мне кажется после девятки ничего нового там не привнесли, а весь тюнинг это подкрутка конфигов ядра по read.me при установке, впрочем у слона практически весь тюнинг это манипуляции с fsync

но автотюнинг актуален все-же

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