The OpenNET Project / Index page

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

В СУБД PostgreSQL добавлена поддержка распараллеливания запросов

12.11.2015 11:31

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

Например, выполнение тестового запроса "select * from pgbench_accounts where filler like '%a%'" в обычных условиях занимает 743 мс, в то время как при распараллеливании в четыре потока - 213 мс. При распараллеливании операция сканирования разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Началось альфа-тестирование СУБД PostgreSQL 9.5
  3. OpenNews: Для PostgreSQL представлена реализация условных индексов
  4. OpenNews: В СУБД PostgreSQL включена реализация UPSERT
  5. OpenNews: Представлена инфраструктура по организации параллельных вычислений в PostgreSQL
  6. OpenNews: Для PostgreSQL подготовлен инструмент ресинхронизации pg_rewind
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (48) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, anonymous (??), 11:55, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +21 +/
    Отличная новость.
    постгрес всё вкуснее и вккуснее
     
     
  • 2.14, rshadow (ok), 15:13, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =), а не запросы параллелить.
     
     
  • 3.17, КО (?), 16:40, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну нормальный индекс для примера из шапки в студию.
    Ну и чтоб вместо '%a%' - bind.
     
     
  • 4.20, Joes (?), 17:55, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    GIST TRGM?
     
  • 3.22, rob pike (?), 18:29, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Во-первых, читайте внимательней.
    > Parallel query for PostgreSQL - for which this is the first step

    Во-вторых, если соотношение insert и select 100500 к одному-раз-в-месяц-по-ночам, то отрывать надо за индексы.

     
     
  • 4.23, rshadow (ok), 18:54, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.
     
     
  • 5.28, АнониМ (ok), 23:01, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +11 +/
    какой-то спор безруких :D :D
     
  • 5.31, all_glory_to_the_hypnotoad (ok), 00:14, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.

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

     
  • 4.34, anonymous (??), 07:36, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    BTREE плохо подходят для больших баз с write-only нагрузкой.
    Cмысл писать такие коменты в теме с PostgreSQL? он же не умеет в LSM
     
     
  • 5.37, rob pike (?), 08:26, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > BTREE плохо подходят для больших баз с write-only нагрузкой.

    В случае B-tree всё намного больше определяется конкретной имплементацией чем кажется. Для начала можете посмотреть на LMDB.

    > он же не умеет в LSM

    Очень хорошо что не умеет. Не приходится ходить покурить пока у него compacting.

     
  • 3.43, Аноним (-), 10:35, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =),
    > а не запросы параллелить.

    OLTP vs DWH ;)

     
  • 1.3, Аноним (-), 12:19, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Глядишь, такими темпами лет через 5 и oracle 9 догонит
     
     
  • 2.7, Штунц (?), 12:51, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    для этого нужно научиться пакеты поддерживать
     
  • 2.8, Александр (??), 13:29, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?
     
     
  • 3.9, Sluggard (ok), 13:44, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У Oracle не только MySQL есть. И комментатор выше скорее всего имел в виду это: https://ru.wikipedia.org/wiki/Oracle_Database
     
     
  • 4.52, Аноним (-), 21:48, 14/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, именно так: "А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?"
    Разговор про один уровень. БЕсплатное, доступное и оооочень даже Advanced. Если уж на то пошло то и Postgres изменяют и делают коммерческим, и функции этих систем, уж совсем недалеко от "крыши" технологий, тут вот с Оракл 9 и сравнивать уже можно.
     
  • 3.18, GrammarNarziss (?), 16:41, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "гнусите-то", позорище
     
     
  • 4.24, Аноним (-), 20:11, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "Гнусите-то", позорище.
    Ты же понимашь, что пипл просто пишет как быстрее, чтоб не париться. Так делаешь и ты, но при этом всех оскорбляешь.
     
  • 2.15, rshadow (ok), 15:15, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)
     
     
  • 3.19, Аноним (-), 17:03, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чтобы растратить казённые деньги, зачем же ещё )))
     
     
  • 4.26, Вареник (?), 21:20, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Именно. Где еще взять такую возможность освоить бюджет. Это даже лучше чем латать один любимый участок дороги каждую неделю, высыпая асфальт на снег и лужи.
     
  • 4.44, rshadow (ok), 11:47, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как показывает практика деньги пилятся вне зависимости от стоимости ПО, и в не меньших объемах. Просто с Ораклом обосновывать легче.
     
  • 3.46, Танцпольный наймит Госдепа (?), 17:07, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)

    Основной заказчик ПО Оракл — государственный департамент США. Вряд ли за пять лет США кончатся, если вы понимаете о чём я. Но здравый смысл в ваших словах есть, конечно.

     
  • 1.6, Аноним (-), 12:28, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С нетерпением ждём расперпендикуляривания запросов.
     
     
  • 2.10, Andrey Mitrofanov (?), 13:48, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > С нетерпением ждём расперпендикуляривания запросов.

    Вперпендикуляривания же. ...Возм., от-.

     
  • 1.11, Аноним (-), 13:50, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Только вот непонятно, почему degree общий на весь запрос, и почему нельзя было сделать хинтом как в Oracle, не думаю что там патенты мешают ...
     
     
  • 2.12, rob pike (?), 14:49, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хинты много раз обсуждались разработчиками PostgreSQL.

    https://wiki.postgresql.org/wiki/OptimizerHintsDiscussion

     
     
  • 3.13, Аноним (-), 15:02, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Только из того "что-плохого" многое после реальной работы с большими и тяжёлыми запросами на серьёзном оборудовании кажется надуманным.

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

     
     
  • 4.16, Аноним (-), 16:31, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Что за degree? О чём Вы?
     
     
  • 5.41, Аноним (-), 10:20, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за degree? О чём Вы?

    rhaas=# set max_parallel_degree = 4;
    SET
    Time: 0.270 ms
    rhaas=# select * from pgbench_accounts where filler like '%a%';
    aid | bid | abalance | filler
    -----+-----+----------+--------
    (0 rows)

    Time: 213.412 ms

     
  • 4.21, rob pike (?), 18:25, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > There is a philosophical difference between PostgreSQL’s approach and that of many other systems. In PostgreSQL, it is encouraged to specify costs and selectivities more than exact plans. There are good reasons for that, such as sheer number of possible plans for even moderately complex queries. Additionally, specifying exact plans tends to lead you into exactly the type of trouble you are trying to avoid by specifying hints in the first place — after input cardinalities change, the previous plan may now be a very poor one.
     
     
  • 5.40, Аноним (-), 10:18, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> There is a philosophical difference between PostgreSQL’s approach and that of many other systems. In PostgreSQL, it is encouraged to specify costs and selectivities more than exact plans. There are good reasons for that, such as sheer number of possible plans for even moderately complex queries. Additionally, specifying exact plans tends to lead you into exactly the type of trouble you are trying to avoid by specifying hints in the first place — after input cardinalities change, the previous plan may now be a very poor one.

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

     
     
  • 6.45, rob pike (?), 17:06, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > эти грабли всё-таки в головах

    Это значит что эти грабли - будут всегда, у подавляющего большинства пользователей, и с ними ничего не сделаешь.

    > хинты - удобный способ делать что-то быстро

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

     
  • 4.29, АнониМ (ok), 23:05, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение

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

     
     
  • 5.39, Аноним (-), 10:15, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение
    > хинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет,
    > а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики,
    > оракл плюёт на все хинты и начинает стоить декартово произведение таблиц
    > с уходом времени выполнения в бесконечность.

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

     
  • 2.32, all_glory_to_the_hypnotoad (ok), 00:18, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Только вот непонятно, почему degree общий на весь запрос...

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

     
     
  • 3.42, Аноним (-), 10:21, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Только вот непонятно, почему degree общий на весь запрос...
    > вообще и его быть не должно, должна быть глобальная опция настройки сервера.
    > Потом мб так и будет.

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

     
     
  • 4.47, all_glory_to_the_hypnotoad (ok), 22:06, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, это видно планировщику запроса исходя из оценочного объёма данных, расположению их по дискам и квотам пользователя если таковые имеются.

    > и что с конкуренцией запросов, кому сколько давать? ядер и 200 может быть...

    их может быть и сотни тыс. (например, mapreduce кластер). Здесь почти  типичная mr задача.

     
  • 1.25, Аноним (-), 20:42, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое. При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
     
     
  • 2.27, Аноним (-), 21:53, 12/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Казалось бы причём тут мускуль.
     
  • 2.33, all_glory_to_the_hypnotoad (ok), 00:27, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое.

    нет, это просто способ разбиения данных на куски для других целей. Настоящее распараллеливание работает на любой таблице.

    >  При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?

    Вроде ошибаешься, есть какие-то внешние костыли с помощью которых можно шардить запрос по партициям.

     
  • 1.30, АнониМ (ok), 23:07, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А какая цена по памяти всего этого счастья. в оракле параллельные запросы очень не прилично по памяти себя ведут к примеру.
     
     
  • 2.36, anonymous (??), 07:44, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А какая цена по памяти всего этого счастья

    Для full table scan это равнозначно нескольким параллельным запросам над 1/4-1/10 таблицы, другое дело, что процессоры это будет жрать как не в себя и тупить приложение будет не только у одного клиента, как без паралельного выполнения запросов, а у всех клиентов.

     
     
  • 3.38, Alex (??), 09:38, 13/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Особенно эротично это будет выглядеть на HDD-based базе объёмом больше, чем выделенная под буфер память.
     
  • 1.35, anonymous (??), 07:39, 13/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пример select * from pgbench_accounts where filler like '%a%'  идиотский, full text search в каком-нидь sphinx будет бодрее чем новая реализация.

    Но, это хороший задел для распаралеливания full table scan'ов на несколько узлов с шардингом (которые обещают в следующие лет 5).

     
     
  • 2.50, Aleks Revo (ok), 15:54, 14/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А при чём тут вообще full text? был дан пример неиндексируемого в обычных условиях запроса для демнстрации разницы производительности - не более того. А там - что угодно можно анализировать, хоть generate_series, главное, что это теперь МОЖЕТ параллелиться, а не цедится в один поток.
    Как итог: транзакции быстрее завершаются, сокращается число потенциальных блокировок и все следующие из этого плюшки.
     
     
  • 3.51, all_glory_to_the_hypnotoad (ok), 16:28, 14/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Как итог ... сокращается число потенциальных блокировок ...

    обдолбался чтоли? Кол-во блокировок как раз растёт.

     
  • 1.48, Аноним (-), 00:36, 14/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    PgSQL уже можно использовать как серьезное решение?
     

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



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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