Оптимизация работы с большим объемом данных при помощи партиционирования в SQL

[Akina]

Угу... а ещё принято говорить "поля". Колонки - это в Экселе и иже с им.

[vadim_bv]

ага, а переводчики книги Тома Кайта в лохматом году использовали слово "фрагментация". И что? все говорят партицирование.

[Akina]

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

Что, правда? PostgreSQL неспособен самостоятельно определить, куда класть записи, и ему надо указывать дополнительно WHERE?

Локальные индексы создаются на отдельной партиции и применяются только к этой партиции.

Как работает (и работает ли вообще) локальный индекс, если условие отбора требует обращение к двум партициям, причём в первой есть подходящий локальный индекс, а во второй его нет?

Могут ли локальные (и глобальные) индексы быть уникальными?

Как насчёт поддержки внешних ключей?

Например, мы можем настроить таблицу «orders» с партиционированием по полю «order_date» таким образом, чтобы автоматически создавались новые партиции каждый месяц.

Добавьте, пожалуйста, соответствующий CREATE TABLE. А то не очень понятно, что имеется в виду.

[E_STRICT]

Существует два основных варианта партиционирования в SQL

А разве в SQL вообще есть такое понятие как партицирование? Я думал, это просто фича некоторых конкретных СУБД,

[EvgenyVilkov]

Тонко )

[JPEGEC]

PARTITION BY RANGE (YEAR(event_date))

(

PARTITION p2019 VALUES LESS THAN (2020),

PARTITION p2020 VALUES LESS THAN (2021),

PARTITION p2021 VALUES LESS THAN (2022)

);

Простите а куда в вашем примере попадут записи с event_date >= 2022 ?

[vadim_bv]

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

[savostin]

А не подскажите кто у нас умеет автопартицирование? Никогда не встречал. Бесит каждый год/месяц создавать новую партицию.

[vadim_bv]

Оракл умеет.
Постгрес из коробки — нет, но можно по крону настроить, например
https://www.cybertec-postgresql.com/en/automatic-partition-creation-in-postgresql/

[savostin]

Жжжжжесть... По крону на боевом сервере делать ALTER TABLE надо иметь железные нервы...

Хотя в MySQL не проще...

[vadim_bv]

Можно в сторону Hive посмотреть, с учетом того, что он не РСУБД :)

[RekGRpth]

Расширения pg_partman / pg_pathman умеют делать нативное автопартицирование

[EvgenyVilkov]

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

К нему прибегают когда СУБД накладывает ограничение на кол-во полей в таблице.

[Akina]

Ну это не совсем так. И даже порой совсем не так. Простейший пример - запись содержит сотню полей, 90 из которых нужны лишь раз в год, а остальные запрашиваются чуть ли не ежесекундно.

[EvgenyVilkov]

внезапно проблему у решают колоночное хранение или зонирование.

с другой стороны это неправильно называть вертикальным снкционированием тк это правильное моделирование ))

[HabraUser666]

А в чем отличие этого партицирования от статического VIEW по какому-то году?