Pull to refresh

Comments 43

Не надо калькировать английские термины. Особенно, этот: очень сильно режет слух. Используйте русские устоявшиеся аналоги или пишите на английском.
можно, наверное, применить термин разбиение
Зачем, когда есть устоявшийся термин, использующийся в литературе.
Вы про секционирование? В литературе встречаются оба подхода. Эх, с русским конечно тяжело), во второй части буду чаще partitioning употреблять.
Я пока до комментариев не дошел, все думал: причем тут патриции?
я не знаком с постгре, но разве не должна она уметь делать все автоматически без триггеров и тп? чтобы можно было задать условия как делить таблицу, а база уже сама разобралась что куда складывать и это все было прозрачно для запросов?
ну это и так прозрачно: все пишется в мастер-таблицу.

проблема в том, что партицировать можно по разному: на основании любой хэш функции (операторов больше-меньше для сравнимых типов; или, например, юзеров делим на две часть — мальчиков направо, девочек налево), еще как угодно. так что как ни крути, придется писать свою хэш-функцию и делать под нее свой синтаксис в create table. а зачем, если все уже есть?

плюс еще, что не бд не знает, что пора делать новую партицию — может быть куча вариантов: по времени, по количеству данных.
Получается, что именно секционирование как таковое в PostgreSQL отсутствует, но есть функционал для того, чтобы эмулировать его работу?

А можно, например, «вывести из строя» одну из секций таблицы, не повредив работе запросов над остальными секциями (как в оракле ALTER TABLESPACE… OFFLINE)?
У вас по tablespace на partition?
Вообще вы можете спокойно дропнуть хоть половину всех секций, работе с остальными это не повредит.

И я бы не сказал, что это эмуляция секционирования. Это оно самое и есть, просто реализация отличается от Oracle, но Oracle и не является эталоном (что прискорбно).
UFO landed and left these words here
Ага, только не ставить, а покупать. Я так прикинул на shop.oracle.com, при самом дешевом раскладе (25 лицензий Named User Plus на 1 год и без поддержки) выходит 5900 долларов США (я не уверен, включены ли налоги). При этом надо понимать, что нет особого смысла покупать лиценизии на 1 год.

А тут дешево и сердито. А, может, и не так уж сердито, почитаем продолжение.
UFO landed and left these words here
Ой как дешево, а если покупать в РФ у официальных дилеров, то от 12к$.
Это за 25x Named User Plus (NUP) Enterprise Edition 1 year + 25x NUP Partitioning без поддержки?
Хотя, я, конечно, понимаю, что это бредовый вариант, и нечто нормальное действительно может начинаться с 20К.
Ой, сейчас пересчитал, Oracle EE, 25xNUP +25xNUP Partitioning:

ИТОГО 38066.56 $

Вот во всем Oracle хорош, но цена…
Ну… Зато если вы принимаете решение о покупке, то официальный дилер поделится лично с вами сладким секретом своей наценки ;)
Маловато будет! Скорее всего ведь процессорные лицензии потребуются, а это 8500 на каждый сокет. Не считая, опять же, поддержки и самой СУБД.

Но по опыту — когда при использовании БД на Oracle встает вопрос секционирования, то речь идет о реально огромной БД, сотни Гб. А значит и железо серьезное, и система ценная. Приходится раскошеливаться.
Недавно облажались на работе, предполагая что цена считается по процессорам. Оказалось по ядрам =( в итоге система оказалась в два раза дороже =\
Да, там нужно внимательно всё читать. Standard — по сокетам, Enterprise — по ядрам с таблицей коэфициентов, муть…
Ну не скажите, административный ovehead добавляется и в oracle. Точно также нужно во время создавать/архивировать партиции. Разве что с триггером и CHECK constraints возиться не нужно. Вообще по сути в oracle каждая партиция неявно для пользователя является отдельной таблицей.
Отдельным сегментом, но не таблицей. Все-таки, нельзя сделать alter секции и изменить список столбцов в ней, например. Или навесить ограничение целостности только на одну секцию.
Поэтому и говорю — неявно для пользователя. Сама база работает с секцией как с отдельной таблицей, Кайт когда-то писал об этом.

Ну а чтобы не начать ненароком спора об этом, сформулирую так: секции имеют очень много общего с обычными таблицами:).
А уж какой overhead добавляется при разработке приложения! Нужно по всем запросам к секционированным таблицам 3-жды проверять планы, условия поиска, думать о том, разрешать ли Ораклу распараллеливать их, и т.д.
ну что вы наговариваете:) будто планы запросов к обычным таблицам проверять не нужно, да и параллелятся они тоже на раз.
Я не наговариваю, я реалист :) Параллелится всё на раз, в каких-то ситуациях становится лучше в разы. В каких-то — хуже в разы, из-за большого оверхеда на создание параллельных потоков обработки и синхронизацию между ними.

Приходится где-то разрешать параллельную обработку, где-то запрещать, где-то переписывать запросы.

В общем, появляется много новой интересной работы :)
есть замечание, что неплохо было-бы написать про управление партициями не через триггер, а через rule, и когда какой метод предпочтительней использовать
Да я хотел, но очень уж много материала получается, так что это во второй части.
краем глаза замечаю «вечер/день/утро» — секунду не могу понять, что за странный путь такой.
надо больше спать!
А умеет ли PostgreSQL распараллеливать выполнение запросов, затрагивающих несколько секций?
Нет, не умеет. Вообще у postgresql есть один большой минус, он выполняет запрос в одном потоке, и совсем не умеет параллелить, так что каждый раз приходится изобретать велосипед. Ходит слух, что enterpriseDB параллелит выполнение запросов.

В защиту постгре скажу, что распараллеливание запросов в Oracle не всегда приносит тот результат, который от него ждешь.
Угу, я как раз выше об этом же вам и ответил :)
Параллелизм вообще штука противоречивая. Как хорошо заметил Кайт, распараллеливание — это способ максимизировать использование ресурсов системы. Получается, что оно нужно далеко не везде, а может, и наоборот навредить. Хотя для административных задач оно подходит хорошо.

Возвращаясь к теме, мне кажется, что если в штатном порядке работы приложения возникает необходимость производить параллельные запросы к секциям таблиц, то, возможно, что-то не так в архитектуре БД, или же таблица секционирована как-то неоптимально. Мало приходит в голову случаев, когда это было бы необходимо.
Да, не везде, но как опция совсем не повредит. Надо сказать, что в базах, заточенных под анализ данных, распараллеливание какого-нибудь SELECT FROM GROUP BY по секциям очень полезно.
UFO landed and left these words here
Незачто:) Дождитесь только второй части, будет проще)
update1 — зря
update2 — нет правда никто документацию не читает?
аа, вы сведете меня с ума:) но писать топик на английском не выход:)

Спасибо за статью, жду вторую… Когда хотел сделать нормальное секционирование в одном из проектов, напугался описанных вами сложностей и написал скрипт, который каждый месяц создает новую таблицу, а старую переименовывает, добавляя номер месяца и года. Решение рабочее, правда приходится модифицировать запрос на выборку, учитывая желаемый пользователем диапазон дат.
Only those users with full accounts are able to leave comments. Log in, please.