В экспериментальную ветку на базе которой будет формироваться релиз 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.me/opennews/art.shtml?num=43313
Отличная новость.
постгрес всё вкуснее и вккуснее
Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =), а не запросы параллелить.
Ну нормальный индекс для примера из шапки в студию.
Ну и чтоб вместо '%a%' - bind.
GIST TRGM?
Во-первых, читайте внимательней.
> Parallel query for PostgreSQL - for which this is the first stepВо-вторых, если соотношение insert и select 100500 к одному-раз-в-месяц-по-ночам, то отрывать надо за индексы.
По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.
какой-то спор безруких :D :D
> По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.молчал бы уже коли нихрена не разбираешься в сути вопроса.
BTREE плохо подходят для больших баз с write-only нагрузкой.
Cмысл писать такие коменты в теме с PostgreSQL? он же не умеет в LSM
> BTREE плохо подходят для больших баз с write-only нагрузкой.В случае B-tree всё намного больше определяется конкретной имплементацией чем кажется. Для начала можете посмотреть на LMDB.
> он же не умеет в LSM
Очень хорошо что не умеет. Не приходится ходить покурить пока у него compacting.
> Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =),
> а не запросы параллелить.OLTP vs DWH ;)
Глядишь, такими темпами лет через 5 и oracle 9 догонит
для этого нужно научиться пакеты поддерживать
А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?
У Oracle не только MySQL есть. И комментатор выше скорее всего имел в виду это: https://ru.wikipedia.org/wiki/Oracle_Database
Нет, именно так: "А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?"
Разговор про один уровень. БЕсплатное, доступное и оооочень даже Advanced. Если уж на то пошло то и Postgres изменяют и делают коммерческим, и функции этих систем, уж совсем недалеко от "крыши" технологий, тут вот с Оракл 9 и сравнивать уже можно.
"гнусите-то", позорище
"Гнусите-то", позорище.
Ты же понимашь, что пипл просто пишет как быстрее, чтоб не париться. Так делаешь и ты, но при этом всех оскорбляешь.
Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)
чтобы растратить казённые деньги, зачем же ещё )))
Именно. Где еще взять такую возможность освоить бюджет. Это даже лучше чем латать один любимый участок дороги каждую неделю, высыпая асфальт на снег и лужи.
Как показывает практика деньги пилятся вне зависимости от стоимости ПО, и в не меньших объемах. Просто с Ораклом обосновывать легче.
> Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)Основной заказчик ПО Оракл — государственный департамент США. Вряд ли за пять лет США кончатся, если вы понимаете о чём я. Но здравый смысл в ваших словах есть, конечно.
С нетерпением ждём расперпендикуляривания запросов.
> С нетерпением ждём расперпендикуляривания запросов.Вперпендикуляривания же. ...Возм., от-.
Только вот непонятно, почему degree общий на весь запрос, и почему нельзя было сделать хинтом как в Oracle, не думаю что там патенты мешают ...
Хинты много раз обсуждались разработчиками PostgreSQL.
Только из того "что-плохого" многое после реальной работы с большими и тяжёлыми запросами на серьёзном оборудовании кажется надуманным.Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение ( хотя Oracle иногда ведёт себя не так как ему указывают, но это в основном из-за недостатка ресурсов ).
Как настроить сложный запрос с помощью предварительных директив не очень понятно, как пример сложный запрос с объединением фильтрованных данных из нескольких таблиц, как ограничивать degree?
Что за degree? О чём Вы?
> Что за 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
> 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.
>> 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Тб работают по разному, но эти грабли всё-таки в головах.
Ещё раз напишу, хинты - удобный способ делать что-то быстро, в Оракл есть способы прибивать планы без них, но этим пользуются очень редко.
> эти грабли всё-таки в головахЭто значит что эти грабли - будут всегда, у подавляющего большинства пользователей, и с ними ничего не сделаешь.
> хинты - удобный способ делать что-то быстро
А потом, когда это временное "быстро" превратится в долгосрочное "медленно", все интернеты будут полны "ваш PostgreSQL - тормоз". Спасибо, не надо, цель разработчиков PostgreSQL не в том чтобы всех подсадить на платиновый саппорт.
>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведениехинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет, а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики, оракл плюёт на все хинты и начинает стоить декартово произведение таблиц с уходом времени выполнения в бесконечность.
>>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение
> хинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет,
> а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики,
> оракл плюёт на все хинты и начинает стоить декартово произведение таблиц
> с уходом времени выполнения в бесконечность.Статистика отключаема, и отключается именно по этой причине, план можно прибить гвоздями и в Oracle...
> Только вот непонятно, почему degree общий на весь запрос...вообще и его быть не должно, должна быть глобальная опция настройки сервера. Потом мб так и будет.
>> Только вот непонятно, почему degree общий на весь запрос...
> вообще и его быть не должно, должна быть глобальная опция настройки сервера.
> Потом мб так и будет.и что с конкуренцией запросов, кому сколько давать? ядер и 200 может быть...
Очевидно, это видно планировщику запроса исходя из оценочного объёма данных, расположению их по дискам и квотам пользователя если таковые имеются.> и что с конкуренцией запросов, кому сколько давать? ядер и 200 может быть...
их может быть и сотни тыс. (например, mapreduce кластер). Здесь почти типичная mr задача.
Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое. При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
Казалось бы причём тут мускуль.
> Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое.нет, это просто способ разбиения данных на куски для других целей. Настоящее распараллеливание работает на любой таблице.
> При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
Вроде ошибаешься, есть какие-то внешние костыли с помощью которых можно шардить запрос по партициям.
А какая цена по памяти всего этого счастья. в оракле параллельные запросы очень не прилично по памяти себя ведут к примеру.
> А какая цена по памяти всего этого счастьяДля full table scan это равнозначно нескольким параллельным запросам над 1/4-1/10 таблицы, другое дело, что процессоры это будет жрать как не в себя и тупить приложение будет не только у одного клиента, как без паралельного выполнения запросов, а у всех клиентов.
Особенно эротично это будет выглядеть на HDD-based базе объёмом больше, чем выделенная под буфер память.
Пример select * from pgbench_accounts where filler like '%a%' идиотский, full text search в каком-нидь sphinx будет бодрее чем новая реализация.Но, это хороший задел для распаралеливания full table scan'ов на несколько узлов с шардингом (которые обещают в следующие лет 5).
А при чём тут вообще full text? был дан пример неиндексируемого в обычных условиях запроса для демнстрации разницы производительности - не более того. А там - что угодно можно анализировать, хоть generate_series, главное, что это теперь МОЖЕТ параллелиться, а не цедится в один поток.
Как итог: транзакции быстрее завершаются, сокращается число потенциальных блокировок и все следующие из этого плюшки.
> Как итог ... сокращается число потенциальных блокировок ...обдолбался чтоли? Кол-во блокировок как раз растёт.
PgSQL уже можно использовать как серьезное решение?