The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Бета-выпуск СУБД PostgreSQL 9.6 с поддержкой распараллеливания запросов

12.05.2016 23:26

Представлен первый бета-выпуск СУБД PostgreSQL 9.6, ключевым новшеством в котором является поддержка распараллеливания операций последовательного сканирования записей (Sequential Scan), слияния запросов (join) и агрегирования данных. При распараллеливании операция разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются, что позволяет существенно увеличить скорость обработки запроса на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям.

Другие улучшения:

  • Возможность создания кластерных конфигураций, включающих несколько запасных узлов, реплицируемых в синхронном режиме.
  • Новый режим синхронной репликации "synchronous_commit = remote_apply", при котором основной узел перед закрытием транзакции ожидает подтверждения применения данных на standby-узле;
  • В модуль postgres_fdw, позволяющий логически объединить содержимое БД с нескольких серверов, добавлена поддержка операций слияния (join) и сортировки запросов, а также выполнения операций UPDATE и DELETE на внешнем сервере;
  • Новый API для создания горячих бэкапов, в котором метка резервной копии не записывается в директорию с данными, а возвращается как результат выполнения функции pg_stop_backup(), что позволяет защититься от проблем в случае краха во время бэкапа;
  • Снижено негативное влияние на работу больших таблиц операции "autovacuum", благодаря исключению операций повторной заморозки ("refreezing") старых данных;
  • Реализована подсистема для отображения прогресса выполнения операций, например, организовано информирование о времени до завершения VACUUM;
  • В систему полнотекстового поиска добавлен новый оператор <-> или <DISTANCE>, определяющий расстояние между словами (например, можно осуществить выборку фраз, в которых слово "А" отделено от "B" заданным числом слов);
  • Добавлен модуль pg_visibility;
  • Возможность создавать GIN-индексы с любым значением maintenance_work_mem.


  1. Главная ссылка к новости (http://www.postgresql.org/abou...)
  2. OpenNews: Релиз СУБД PostgreSQL 9.5
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/44414-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (41) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:48, 12/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Это очень круто. Один из тех продуктов, который стабильно из года в год вызывает уважение.
     
     
  • 2.4, Анончег (?), 00:32, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вот ещё ссылка на клуб любителей PostgreSQL

    http://www.meetup.com/postgresqlrussia/about/comments/?op=all

    Там даже есть наш Мишаня

    http://www.meetup.com/postgresqlrussia/members/183070635/

    Вообщем клуб солидный, без подвохов.

    Мишаня подойдёт, может поделиться с нами инфой поэтому клубу.

     

  • 1.2, Аноним (-), 23:54, 12/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Раньше они вначале альфы выпускали, а потом бету. А сейчас сразу бета-версия вышла и на пару месяцев раньше. Какие-то изменения в подготовке релизов?
     
     
  • 2.6, Аноним (-), 07:33, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    и релиз из беты за полгода выкатывают, стрёмно чото
     

  • 1.3, Онаним (?), 23:54, 12/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Будет интересно посмотреть, как 1С на нем крутится будет...
     
     
  • 2.7, Аноним (-), 07:51, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать со спецсборками, и сборки эти очень даже не 9.6 версии.
     
     
  • 3.8, Аноним (-), 08:36, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
    > со спецсборками, и сборки эти очень даже не 9.6 версии.

    ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4 уже, при том, что в шестой шапке 8.4, а в седьмой 9.2

     
     
  • 4.15, none_first (ok), 13:21, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
    >> со спецсборками, и сборки эти очень даже не 9.6 версии.
    > ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4
    > уже, при том, что в шестой шапке 8.4, а в седьмой
    > 9.2

    "там" http://1c.postgrespro.ru/rpm/ уже и 9.5

     
     
  • 5.41, Аноним (-), 19:02, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я на users.v8.1c.ru смотрел, а 9.5 ещё рано, на мой взгляд, в продакшин тянуть
     
  • 3.12, grec (?), 10:55, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Школьнику на заметку

    http://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-osobennosti-patcha

     
     
  • 4.56, Tihon (??), 21:59, 29/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ок. А что в этом патче может понравится, если вместо реализации платформы для версионных БД ребята попытались сделать из Postgres - блокировочник? Видимо мне никогда не понять почему массивы, иерархия и текст имеет всегда один тип - 'bytea'... Почему 1с (по-умолчанию, без возможности от их отказаться) создает мне индексы размером с таблицу и использует их чуть реже чем никогда?

    Про возможность поставить более эффективный GIN/GiST-индекс вместо B-tree для многопользовательского отчета с огромным количеством зависимостей - умолчу...

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

     
  • 3.13, Онаним (?), 11:04, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А вот как патчи сделают да к 1С прикрутят - тогда и посмотрим.
    9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS SQL куда шустрее работает.
    Интересно будет 9.6 сравнить с MS SQL.
     
     
  • 4.16, none_first (ok), 13:23, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А вот как патчи сделают да к 1С прикрутят - тогда и
    > посмотрим.
    > 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
    > SQL куда шустрее работает.

    куда шустрее? нука побалуйте бенчмарками

    > Интересно будет 9.6 сравнить с MS SQL.

    не интересно

     
     
  • 5.42, Аноним (-), 19:04, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> А вот как патчи сделают да к 1С прикрутят - тогда и
    >> посмотрим.
    >> 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
    >> SQL куда шустрее работает.
    > куда шустрее? нука побалуйте бенчмарками
    >> Интересно будет 9.6 сравнить с MS SQL.
    > не интересно

    у него в торгашиной методичке написано, что надо старательно игнорировать настройки постгреса, а то мсскуль соснёт нечаянно

     
  • 4.19, Клыкастый (ok), 13:54, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    оказывается проблема не в невменяемых портянках запросов, а в том, что они на одном ядре пашут.
     
     
  • 5.25, Онаним (?), 15:03, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
    Некоторые - в 5-10 раз быстрее (данные из логов 1С, Постгре и MS SQL).

    На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
    Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...

     
     
  • 6.26, Клыкастый (ok), 15:13, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.

    Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.

    > На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.

    Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.


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

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

    Будет лучше, но это слабое утешение.


     
     
  • 7.27, 123 (??), 15:22, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.

    Там патчи в основном на сравнение данных без учета регистра.

    >>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.

    Там два косяка - медленная работа при соединении живых таблиц с виртуальными (срез последних надо пихать в отдельную таблицу и тд) и работа с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана.

     
     
  • 8.53, Вареник (?), 19:59, 15/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Почему-то в OpenERP Odoo, изначально заточенной под Постгрес - этих проблем нет ... текст свёрнут, показать
     
  • 8.54, Anonymous1 (?), 07:41, 18/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там еще главнее косяки есть У меня, например, при закрытии месяца MS SQL наклад... текст свёрнут, показать
     
  • 7.43, _ (??), 19:10, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > у кровавого энтерпрайза никогда нет денег делать как положено

    Клыкастый, это шедевр!!! (С)Сергей Светлаков

     
     
  • 8.52, Вареник (?), 19:55, 15/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Супер ... текст свёрнут, показать
     
  • 7.49, none_first (ok), 13:58, 14/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
    > Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.
    >> На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
    > Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё
    > будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы
    > 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.

    причина описана здесь http://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-osobennosti-patcha
    и патчи ничего вредного не несут, тем более что делаются в плотном сотрудничестве 1С и профессиональной команды PostgreSql

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

    а бенчи есть здесь http://efsol.ru/articles/performance-1s-postgre-ms-sql.html
    там нет никаких 3-4 раза, есть полтора, но кривость рук разработчиков может может сотворить чудо ;)
    и это "без распараллеливания" как тут выразились

     
  • 6.51, Вареник (?), 19:53, 15/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если долго-долго (десятилетие+) затачивать продукт под целевую базу - то ничего удивительного, что на ней будет выигрыш в скорости.

    Oracle для типичной установки 1C, среднеторговой фирмочки - слишком дорого. Требуемый DBA отдельный - тем более.

    Предлагать опенсорс - непонтово. Нет "синэргетики бизнеса", т.е. взаимного проталкивания продаж. Не на кого потом переводить стрелки, "это не мы, это XXX глючит"...

    Что можно еще впарить, если Oracle дорого? Вывод очевиден и иднозначен. MS SQL. Не Линтер же :)

     
  • 4.55, Alexey Lustin (?), 18:15, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не давайте эту ссылку - она стартоватая

    Сейчас лучше вот:

    https://pgconf.ru/media/2016/05/20/Ласкин Лев.pdf
    https://pgconf.ru/2016/90069
    https://github.com/VanessaDockers/pgsteroids

     
  • 2.11, Нанобот (ok), 09:34, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    без доработки напильником - никак не будет
     

  • 1.9, Аноним (-), 08:50, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А аналог MS-SQL BACKUP LOG имеется в слонике? Или там надо как и раньше плясать с бубнами и настраивать резервного слона, что бы можно было восстановить архив на произвольный момент времени?
     
     
  • 2.10, Andrew (??), 09:17, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А аналог MS-SQL BACKUP LOG имеется в слонике? Или там надо как и раньше плясать с бубнами и настраивать резервного слона, что бы можно было восстановить архив на произвольный момент времени?

    Есть, правда реализация больше похожа на Oracle, нежели на M$ SQL.
    Детали в официальной документации: http://www.postgresql.org/docs/9.5/static/continuous-archiving.html

     

  • 1.14, Stax (ok), 11:55, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ай-яй-яй, ну как так можно, *самое* замечательное, что ждем в этом релизе, и не упомянуть! Теперь GIN-индексы можно создавать с любым maintenance_work_mem. Сейчас постоянно для пересоздания каких-то индексов приходится его до гига урезать, а для одного уже до 500 мегабайт, иначе создание падает с нехваткой памяти (а так как GIN загаживаются быстро, пересоздавать приходится регулярно). Из-за чего pg_repack автоматом не запустить и прочие радости...
     
     
  • 2.17, Аноним (-), 13:23, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Распараллеливание, ИМХО, более фундаментальное и ожидаемое улучшение
     

  • 1.24, Аноним (-), 15:00, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    подскажите пожалуйста я правильно понимаю что в синхронном режиме пришедший update сначала идет на slave сервер, записывается, делается fsync (если разрешен), далее master записывает себе, делает fsync (если разрешен) и только затем говорит клиенту что update прошел?

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

    а как сюда вяжется "synchronous_commit = remote_apply"?

    объясните пожалуйста если знаете как это работает, заранее большое спасибо!

     
     
  • 2.29, Аноним (-), 15:47, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пришедший апдейт сначала пишется в журнал WAL и оттуда отправляется на слейв, на слейве он применяется, об этом уведомляется мастер, и только тогда мастер завершает исполнение запроса, пока уведомление не придет мастер тупо ждет. Да, при падении мастера можно сразу переключится на слейв, он синхронен. Это и есть remote_apply. Как происходит обработка если от слейва ответ не пришел не знаю, могу предположить что запись в журнале "остается непримененной"
     
     
  • 3.30, Аноним (-), 16:25, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    а в чем тогда разница между режимами remote_apply и on?
     
     
  • 4.34, Аноним (-), 16:42, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если on то мастер считает что изменение прошло не когда оно было применено слейвом, а когда оно было только принято им
     
     
  • 5.36, Аноним (-), 17:20, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    выходит remote_apply наиболее синхронный и безопасный к падению и переключению режим. спасибо!
     

  • 1.31, Аноним (-), 16:26, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет в официальном postgres?
     
     
  • 2.33, Andrey Mitrofanov (?), 16:38, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет
    > в официальном postgres?

    Никогда потому, что это не SQL.

     
     
  • 3.37, Аноним (-), 17:23, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Никогда потому, что это не SQL.

    Что за бред? я тестировал летом связку из трех серверов в BDR - создавал таблицы, делал в них insert, добавлял поля, менял типы полей - все менялось на всех трех серверах с какого бы я это не делал. в продакшене не использовали, просто поигрались и убедились что изменения синхронизируются без всяких триггеров.

     
     
  • 4.39, 123 (??), 18:06, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>Никогда потому, что это не SQL.
    > Что за бред? я тестировал летом связку из трех серверов в BDR
    > - создавал таблицы, делал в них insert, добавлял поля, менял типы
    > полей - все менялось на всех трех серверах с какого бы
    > я это не делал. в продакшене не использовали, просто поигрались и
    > убедились что изменения синхронизируются без всяких триггеров.

    Попробуй поменять на 100 гиговой базе с внешними ключами. Просто интересно сколько это займет.

     
  • 2.35, Аноним (-), 16:51, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество не чешется) Также слышал о том что BDR не поддерживает некоторые базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен бы еще с BDR, вот это бы хотябы - http://www.postgresql.org/about/news/1666/ ))
     
     
  • 3.44, Andrey Mitrofanov (?), 21:00, 13/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество
    > не чешется) Также слышал о том что BDR не поддерживает некоторые
    > базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен

    UDR уже "завбросили". И кому оно впилось?

    Ты внимательно читал мануал того BDR?  В части "у нас БЫСТРО* и многомастерно! <small>просто скажите вашим программерам переписать эти с-ные приложения</small>  *без блокировок, прогремссивно!"

    > бы еще с BDR, вот это бы хотябы -

    Табе вот уже подавай каких-то "новых" блестящек.

    Про ужасы блестяшек [или примерно]
    http://bonesmoses.org/2016/05/06/pg-phriday-big-data-is-hard/

     
     
  • 4.47, Роман (??), 00:43, 14/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да одна вещь по большому счету нужна, чтобы не весь кластер реплицировался, а только схема по выбору..
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру