Позволяют ли партишены делать такое?

Question

[beduin01]

Почитал документацию. Но остались вопросы. У меня есть большая БД которую нужно ускорить т.к. есть тормоза при вставке новых данных (тестировал с индексами и без).

В документации показаны примеры. Когда создается базовая таблица table_base и дальше от нее создаются партишены, допустим по дате вида: table_base_2015, table_base_2016, table_base_2017, table_base_2018 и тд.

И дальше в момент Insert'a нужно указать правильную таблицу для данных (я же правильно понял?) INSERT INTO table_base_2018 ...

А в момент выборки можно будет выбирать из главное таблицы и она будет учитывать данные из своих паршитенов. Верно?

Вопрос в следующем. Можно ли создать партишен под названием
table_base_latest куда бы попадали данные только за последние 365 дней, а остальные а остальные складирвоались без в какой-нибудь table_base_tail который бы содержал все оставшиеся данные?

Answer 1

[rPman]

Вставка данных без индексов должна работать максимально быстро, у вас что, на чтение очень много запросов?
p.s. диск хоть ssd?

Чтобы partitioning ускоряло работу, нужно чтобы условие разделения данных по партициям делило нагрузку, в идеале развномерно, а так же сами файлы таблейспейс размещались на разных физических устройствах, чтобы нагрузка на одни секции не затрагивало скорость работы с другими

table_base_latest куда бы попадали данные только за последние 365 дней, а остальные а остальные складирвоались без в какой-нибудь table_base_tail который бы содержал все оставшиеся данные?

на сколько я знаю штатный инструмент это не умеет, ведь данные придется как то перемещать между партициями

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

Имхо 'овчинка не стоит выделки', точнее очень мало случаев когда геморой реализации даст адекватное повышение производительности.

Comments

[beduin01]

Я не могу вообще без индексов т.к. иногда могут прилететь новые данные со старом MyID. В итоге удаление занимает очень много. Поэтому использую hash индекс.
Да ssd

[Akina]

иногда могут прилететь новые данные со старом MyID. В итоге удаление занимает очень много. Поэтому использую hash индекс.

А какая связь между данными по старому периоду и hash-индексом? тут скорее hash-то как раз помеха.

[beduin01]

Akina, просто без индексов удаление старых данных очень долго занимает. btree как я почитал будут не быстрее.
У меня логика такая, что если что-то не закоммитилось и упало с исключением, то в БД есть дубликат который нужно удалить и повторить вставку.

[Akina]

Не, понятно, что без индексов надо сканить таблицу. Но с неподходящим индексом - надо сканить весь индекс, словно он - компактная версия таблицы. Ну и какая разница? Фуллскан по индексу, а не по таблице, не перестаёт быть фуллсканом.

Answer 2

[Akina]

Можно ли создать партишен ... куда бы попадали данные только за последние 365 дней

Нет, динамические границы раздела - такое в принципе невозможно.

В документации показаны примеры. Когда создается базовая таблица table_base и дальше от нее создаются партишены

Не лезьте в высокие материи, не зная основ. Начните с самого обычного RANGE PARTITIONING. Одна таблица - куча разделов, и никаких надтаблиц.

Comments

[beduin01]

"Нет, динамические границы раздела - такое в принципе невозможно."
Вообще нет способов?

[Akina]

beduin01, ни в одной современной СУБД нет партиционирования, при котором границы разделов зависят от текущего времени. Ибо будь такой - это привело бы к постоянной миграции записей из одной партиции в другую.

[beduin01]

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

А если по годам или кварталам, у меня в SQL менеджере получается десятки таблиц будут видны вида mytable_2001 mytable_2002 mytable_2003 и тд ?

[Akina]

beduin01, а вот статические константные границы - сколько угодно.

Но я всё равно не понимаю, на[censored] нужно представлять разделы как отдельные таблицы. Чтобы потом в них путаться? чтобы решать задачу выбора правильной субтаблицы, а при ошибке любоваться на [censored]? Оставь одну таблицу с разделами, сервер сам, без помощи, разберётся, что куда класть и когда где смотреть.

[beduin01]

Akina, а можно чуть более подробно. Типа сервер сам будет создавать необходимые партишены для данных по условию?

[Akina]

beduin01, не, разделы будете создавать Вы (но именно разделы, а не новые таблицы, присоединяемые к надтаблице как новые разделы), причём изрядно заранее. Даже можно это зашедулить в какую-нибудь сервисную процедуру. Скажем, в ежедневный бэкап - ну не проблема же проверить текущую дату и факт наличия партиции под данные следующего квартала, а? тем более когда это всего одна строка типа CALL check_partition_structure();

А вот когда разделы есть, и сервер чётко знает, в каком разделе какие данные лежат, он без проблем при выполнении запроса может (если условия отбора позволяют) обращаться только к тем разделам, в которых нужные данные присутствуют.

Answer 3

[galaxy]

И дальше в момент Insert'a нужно указать правильную таблицу для данных (я же правильно понял?) INSERT INTO table_base_2018

Неправильно понял. Вставлять можно (и нужно) в главную (можно и в партиции - но зачем?).

А в момент выборки можно будет выбирать из главное таблицы и она будет учитывать данные из своих паршитенов. Верно?

разумеется.

У меня есть большая БД которую нужно ускорить т.к. есть тормоза при вставке новых данных (тестировал с индексами и без).

Ускорить вставку партицирование не поможет, если партиции на одном физическом диске (замедлить вот может).
Партицирование может пригодиться в следующих случаях:
- выборка с условием по колонке партицирования (чтобы сканировать меньше данных)
- удаление данных большими блоками (например, исторических данных за прошлые годы).

Comments

[beduin01]

"выборка с условием по колонке партицирования (чтобы сканировать меньше данных)"

Тоесть я четко должен понимать обращаясь к партишену какие именно данные я оттуда хочу получить? Что типа в нем срез данных хранится ТОЛЬКО за 2015-2016 годы?

[galaxy]

beduin01, если хотите ускорения. Допустим, у вас партиии по месяцам, тогда, если вам нужны данные за май-июнь 2019, просканированы будут только две партиции независимо от плана запроса.