Комментарии 43
НЛО прилетело и опубликовало эту надпись здесь
я не знаком с постгре, но разве не должна она уметь делать все автоматически без триггеров и тп? чтобы можно было задать условия как делить таблицу, а база уже сама разобралась что куда складывать и это все было прозрачно для запросов?
ну это и так прозрачно: все пишется в мастер-таблицу.
проблема в том, что партицировать можно по разному: на основании любой хэш функции (операторов больше-меньше для сравнимых типов; или, например, юзеров делим на две часть — мальчиков направо, девочек налево), еще как угодно. так что как ни крути, придется писать свою хэш-функцию и делать под нее свой синтаксис в create table. а зачем, если все уже есть?
плюс еще, что не бд не знает, что пора делать новую партицию — может быть куча вариантов: по времени, по количеству данных.
проблема в том, что партицировать можно по разному: на основании любой хэш функции (операторов больше-меньше для сравнимых типов; или, например, юзеров делим на две часть — мальчиков направо, девочек налево), еще как угодно. так что как ни крути, придется писать свою хэш-функцию и делать под нее свой синтаксис в create table. а зачем, если все уже есть?
плюс еще, что не бд не знает, что пора делать новую партицию — может быть куча вариантов: по времени, по количеству данных.
Получается, что именно секционирование как таковое в PostgreSQL отсутствует, но есть функционал для того, чтобы эмулировать его работу?
А можно, например, «вывести из строя» одну из секций таблицы, не повредив работе запросов над остальными секциями (как в оракле ALTER TABLESPACE… OFFLINE)?
А можно, например, «вывести из строя» одну из секций таблицы, не повредив работе запросов над остальными секциями (как в оракле ALTER TABLESPACE… OFFLINE)?
alter table… no inherits
alter table… inherits
alter table… inherits
У вас по tablespace на partition?
Вообще вы можете спокойно дропнуть хоть половину всех секций, работе с остальными это не повредит.
И я бы не сказал, что это эмуляция секционирования. Это оно самое и есть, просто реализация отличается от Oracle, но Oracle и не является эталоном (что прискорбно).
Вообще вы можете спокойно дропнуть хоть половину всех секций, работе с остальными это не повредит.
И я бы не сказал, что это эмуляция секционирования. Это оно самое и есть, просто реализация отличается от Oracle, но Oracle и не является эталоном (что прискорбно).
НЛО прилетело и опубликовало эту надпись здесь
Ага, только не ставить, а покупать. Я так прикинул на shop.oracle.com, при самом дешевом раскладе (25 лицензий Named User Plus на 1 год и без поддержки) выходит 5900 долларов США (я не уверен, включены ли налоги). При этом надо понимать, что нет особого смысла покупать лиценизии на 1 год.
А тут дешево и сердито. А, может, и не так уж сердито, почитаем продолжение.
А тут дешево и сердито. А, может, и не так уж сердито, почитаем продолжение.
НЛО прилетело и опубликовало эту надпись здесь
Ой как дешево, а если покупать в РФ у официальных дилеров, то от 12к$.
Это за 25x Named User Plus (NUP) Enterprise Edition 1 year + 25x NUP Partitioning без поддержки?
Хотя, я, конечно, понимаю, что это бредовый вариант, и нечто нормальное действительно может начинаться с 20К.
Хотя, я, конечно, понимаю, что это бредовый вариант, и нечто нормальное действительно может начинаться с 20К.
Ну… Зато если вы принимаете решение о покупке, то официальный дилер поделится лично с вами сладким секретом своей наценки ;)
Маловато будет! Скорее всего ведь процессорные лицензии потребуются, а это 8500 на каждый сокет. Не считая, опять же, поддержки и самой СУБД.
Но по опыту — когда при использовании БД на Oracle встает вопрос секционирования, то речь идет о реально огромной БД, сотни Гб. А значит и железо серьезное, и система ценная. Приходится раскошеливаться.
Но по опыту — когда при использовании БД на Oracle встает вопрос секционирования, то речь идет о реально огромной БД, сотни Гб. А значит и железо серьезное, и система ценная. Приходится раскошеливаться.
Ну не скажите, административный ovehead добавляется и в oracle. Точно также нужно во время создавать/архивировать партиции. Разве что с триггером и CHECK constraints возиться не нужно. Вообще по сути в oracle каждая партиция неявно для пользователя является отдельной таблицей.
Отдельным сегментом, но не таблицей. Все-таки, нельзя сделать alter секции и изменить список столбцов в ней, например. Или навесить ограничение целостности только на одну секцию.
А уж какой overhead добавляется при разработке приложения! Нужно по всем запросам к секционированным таблицам 3-жды проверять планы, условия поиска, думать о том, разрешать ли Ораклу распараллеливать их, и т.д.
ну что вы наговариваете:) будто планы запросов к обычным таблицам проверять не нужно, да и параллелятся они тоже на раз.
Я не наговариваю, я реалист :) Параллелится всё на раз, в каких-то ситуациях становится лучше в разы. В каких-то — хуже в разы, из-за большого оверхеда на создание параллельных потоков обработки и синхронизацию между ними.
Приходится где-то разрешать параллельную обработку, где-то запрещать, где-то переписывать запросы.
В общем, появляется много новой интересной работы :)
Приходится где-то разрешать параллельную обработку, где-то запрещать, где-то переписывать запросы.
В общем, появляется много новой интересной работы :)
есть замечание, что неплохо было-бы написать про управление партициями не через триггер, а через rule, и когда какой метод предпочтительней использовать
краем глаза замечаю «вечер/день/утро» — секунду не могу понять, что за странный путь такой.
надо больше спать!
надо больше спать!
А умеет ли PostgreSQL распараллеливать выполнение запросов, затрагивающих несколько секций?
Нет, не умеет. Вообще у postgresql есть один большой минус, он выполняет запрос в одном потоке, и совсем не умеет параллелить, так что каждый раз приходится изобретать велосипед. Ходит слух, что enterpriseDB параллелит выполнение запросов.
В защиту постгре скажу, что распараллеливание запросов в Oracle не всегда приносит тот результат, который от него ждешь.
В защиту постгре скажу, что распараллеливание запросов в Oracle не всегда приносит тот результат, который от него ждешь.
Угу, я как раз выше об этом же вам и ответил :)
Параллелизм вообще штука противоречивая. Как хорошо заметил Кайт, распараллеливание — это способ максимизировать использование ресурсов системы. Получается, что оно нужно далеко не везде, а может, и наоборот навредить. Хотя для административных задач оно подходит хорошо.
Возвращаясь к теме, мне кажется, что если в штатном порядке работы приложения возникает необходимость производить параллельные запросы к секциям таблиц, то, возможно, что-то не так в архитектуре БД, или же таблица секционирована как-то неоптимально. Мало приходит в голову случаев, когда это было бы необходимо.
Возвращаясь к теме, мне кажется, что если в штатном порядке работы приложения возникает необходимость производить параллельные запросы к секциям таблиц, то, возможно, что-то не так в архитектуре БД, или же таблица секционирована как-то неоптимально. Мало приходит в голову случаев, когда это было бы необходимо.
НЛО прилетело и опубликовало эту надпись здесь
update1 — зря
update2 — нет правда никто документацию не читает?
update2 — нет правда никто документацию не читает?
Спасибо за статью, жду вторую… Когда хотел сделать нормальное секционирование в одном из проектов, напугался описанных вами сложностей и написал скрипт, который каждый месяц создает новую таблицу, а старую переименовывает, добавляя номер месяца и года. Решение рабочее, правда приходится модифицировать запрос на выборку, учитывая желаемый пользователем диапазон дат.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Все что нужно знать о секционировании (Часть 1)