форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В СУБД 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 | Индекс форумов | Темы | Пред. тема | След. тема