The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В СУБД PostreSQL добавлена поддержка распараллеливания запросов"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В СУБД PostreSQL добавлена поддержка распараллеливания запросов"  +/
Сообщение от opennews (??) on 12-Ноя-15, 11:55 
В экспериментальную ветку на базе которой будет формироваться релиз PostreSQL 9.6 приняты (http://rhaas.blogspot.ru/2015/11/parallel-sequential-scan-is...) изменения с реализацией распараллеливания операций последовательного сканирования записей (Sequential Scan), используемых для перебора значений в случае выборки по непроиндексированным полям или при манипуляциях с содержимым полей. Перебор в несколько параллельных потоков позволит существенно увеличить скорость перебора данных на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям.


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


URL: https://news.ycombinator.com/item?id=10549732
Новость: http://www.opennet.dev/opennews/art.shtml?num=43313

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +21 +/
Сообщение от anonymous (??) on 12-Ноя-15, 11:55 
Отличная новость.
постгрес всё вкуснее и вккуснее
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +3 +/
Сообщение от rshadow (ok) on 12-Ноя-15, 15:13 
Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =), а не запросы параллелить.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

17. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +1 +/
Сообщение от КО on 12-Ноя-15, 16:40 
Ну нормальный индекс для примера из шапки в студию.
Ну и чтоб вместо '%a%' - bind.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

20. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +1 +/
Сообщение от Joes on 12-Ноя-15, 17:55 
GIST TRGM?
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –3 +/
Сообщение от rob pike on 12-Ноя-15, 18:29 
Во-первых, читайте внимательней.
> Parallel query for PostgreSQL - for which this is the first step

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –2 +/
Сообщение от rshadow (ok) on 12-Ноя-15, 18:54 
По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

28. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +11 +/
Сообщение от АнониМ (ok) on 12-Ноя-15, 23:01 
какой-то спор безруких :D :D
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

31. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 13-Ноя-15, 00:14 
> По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

34. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от anonymous (??) on 13-Ноя-15, 07:36 
BTREE плохо подходят для больших баз с write-only нагрузкой.
Cмысл писать такие коменты в теме с PostgreSQL? он же не умеет в LSM
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

37. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от rob pike on 13-Ноя-15, 08:26 
> BTREE плохо подходят для больших баз с write-only нагрузкой.

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

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

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –1 +/
Сообщение от Аноним (??) on 13-Ноя-15, 10:35 
> Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =),
> а не запросы параллелить.

OLTP vs DWH ;)

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

3. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –10 +/
Сообщение от Аноним (??) on 12-Ноя-15, 12:19 
Глядишь, такими темпами лет через 5 и oracle 9 догонит
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +1 +/
Сообщение от Штунц on 12-Ноя-15, 12:51 
для этого нужно научиться пакеты поддерживать
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –2 +/
Сообщение от Александр (??) on 12-Ноя-15, 13:29 
А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +1 +/
Сообщение от Sluggard (ok) on 12-Ноя-15, 13:44 
У Oracle не только MySQL есть. И комментатор выше скорее всего имел в виду это: https://ru.wikipedia.org/wiki/Oracle_Database
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

52. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от Аноним (??) on 14-Ноя-15, 21:48 
Нет, именно так: "А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?"
Разговор про один уровень. БЕсплатное, доступное и оооочень даже Advanced. Если уж на то пошло то и Postgres изменяют и делают коммерческим, и функции этих систем, уж совсем недалеко от "крыши" технологий, тут вот с Оракл 9 и сравнивать уже можно.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –1 +/
Сообщение от GrammarNarziss on 12-Ноя-15, 16:41 
"гнусите-то", позорище
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

24. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –1 +/
Сообщение от Аноним (??) on 12-Ноя-15, 20:11 
"Гнусите-то", позорище.
Ты же понимашь, что пипл просто пишет как быстрее, чтоб не париться. Так делаешь и ты, но при этом всех оскорбляешь.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

15. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +4 +/
Сообщение от rshadow (ok) on 12-Ноя-15, 15:15 
Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

19. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +1 +/
Сообщение от Аноним (??) on 12-Ноя-15, 17:03 
чтобы растратить казённые деньги, зачем же ещё )))
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от Вареник on 12-Ноя-15, 21:20 
Именно. Где еще взять такую возможность освоить бюджет. Это даже лучше чем латать один любимый участок дороги каждую неделю, высыпая асфальт на снег и лужи.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

44. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  –1 +/
Сообщение от rshadow (ok) on 13-Ноя-15, 11:47 
Как показывает практика деньги пилятся вне зависимости от стоимости ПО, и в не меньших объемах. Просто с Ораклом обосновывать легче.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

46. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от Танцпольный наймит Госдепа on 13-Ноя-15, 17:07 
> Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

6. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +/
Сообщение от Аноним (??) on 12-Ноя-15, 12:28 
С нетерпением ждём расперпендикуляривания запросов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "В СУБД PostreSQL добавлена поддержка распараллеливания запро..."  +4 +/
Сообщение от Andrey Mitrofanov on 12-Ноя-15, 13:48 
> С нетерпением ждём расперпендикуляривания запросов.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  –1 +/
Сообщение от Аноним (??) on 12-Ноя-15, 13:50 
Только вот непонятно, почему degree общий на весь запрос, и почему нельзя было сделать хинтом как в Oracle, не думаю что там патенты мешают ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +1 +/
Сообщение от rob pike on 12-Ноя-15, 14:49 
Хинты много раз обсуждались разработчиками PostgreSQL.

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 12-Ноя-15, 15:02 
Только из того "что-плохого" многое после реальной работы с большими и тяжёлыми запросами на серьёзном оборудовании кажется надуманным.

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 12-Ноя-15, 16:31 
Что за degree? О чём Вы?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

41. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 13-Ноя-15, 10:20 
> Что за 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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  –1 +/
Сообщение от rob pike on 12-Ноя-15, 18:25 
> 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.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

40. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 13-Ноя-15, 10:18 
>> 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Тб работают по разному, но эти грабли всё-таки в головах.
Ещё раз напишу, хинты - удобный способ делать что-то быстро, в Оракл есть способы прибивать планы без них, но этим пользуются очень редко.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

45. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +4 +/
Сообщение от rob pike on 13-Ноя-15, 17:06 
> эти грабли всё-таки в головах

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

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

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

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

29. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от АнониМ (ok) on 12-Ноя-15, 23:05 
>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

39. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 13-Ноя-15, 10:15 
>>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение
> хинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет,
> а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики,
> оракл плюёт на все хинты и начинает стоить декартово произведение таблиц
> с уходом времени выполнения в бесконечность.

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

32. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 13-Ноя-15, 00:18 
> Только вот непонятно, почему degree общий на весь запрос...

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

42. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 13-Ноя-15, 10:21 
>> Только вот непонятно, почему degree общий на весь запрос...
> вообще и его быть не должно, должна быть глобальная опция настройки сервера.
> Потом мб так и будет.

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

47. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 13-Ноя-15, 22:06 
Очевидно, это видно планировщику запроса исходя из оценочного объёма данных, расположению их по дискам и квотам пользователя если таковые имеются.

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

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

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

25. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  –3 +/
Сообщение от Аноним (??) on 12-Ноя-15, 20:42 
Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое. При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +1 +/
Сообщение от Аноним (??) on 12-Ноя-15, 21:53 
Казалось бы причём тут мускуль.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

33. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 13-Ноя-15, 00:27 
> Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое.

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

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

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "В СУБД PostreSQL добавлена поддержка распараллеливания запросов"  –1 +/
Сообщение от АнониМ (ok) on 12-Ноя-15, 23:07 
А какая цена по памяти всего этого счастья. в оракле параллельные запросы очень не прилично по памяти себя ведут к примеру.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "В СУБД PostreSQL добавлена поддержка распараллеливания запросов"  +/
Сообщение от anonymous (??) on 13-Ноя-15, 07:44 
> А какая цена по памяти всего этого счастья

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

38. "В СУБД PostreSQL добавлена поддержка распараллеливания запросов"  +/
Сообщение от Alex (??) on 13-Ноя-15, 09:38 
Особенно эротично это будет выглядеть на HDD-based базе объёмом больше, чем выделенная под буфер память.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

35. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от anonymous (??) on 13-Ноя-15, 07:39 
Пример select * from pgbench_accounts where filler like '%a%'  идиотский, full text search в каком-нидь sphinx будет бодрее чем новая реализация.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Aleks Revo (ok) on 14-Ноя-15, 15:54 
А при чём тут вообще full text? был дан пример неиндексируемого в обычных условиях запроса для демнстрации разницы производительности - не более того. А там - что угодно можно анализировать, хоть generate_series, главное, что это теперь МОЖЕТ параллелиться, а не цедится в один поток.
Как итог: транзакции быстрее завершаются, сокращается число потенциальных блокировок и все следующие из этого плюшки.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

51. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 14-Ноя-15, 16:28 
> Как итог ... сокращается число потенциальных блокировок ...

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

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

48. "В СУБД PostgreSQL добавлена поддержка распараллеливания запр..."  +/
Сообщение от Аноним (??) on 14-Ноя-15, 00:36 
PgSQL уже можно использовать как серьезное решение?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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